Networking Models¶

Overview¶

Networking models provide a structured framework for understanding how data travels between systems across a network. The two most important models are the OSI (Open Systems Interconnection) 7-layer model and the TCP/IP 4-layer model. These models define how protocols at different layers interact — from physical transmission of bits to application-level communication.

Understanding these models is essential for system administrators because troubleshooting network issues requires knowing at which layer a problem occurs. Whether it is a physical cable issue (Layer 1), a routing problem (Layer 3), or an application misconfiguration (Layer 7), the networking model helps you narrow down the cause.

How It Works¶

The OSI Model¶

The OSI (Open Systems Interconnection) model divides network communication into seven layers, each responsible for a specific aspect of data transmission:

Layer	Name	Function	Example Protocols/Devices
7	Application	End-user services and interfaces	HTTP, DNS, SMTP, SSH
6	Presentation	Data formatting, encryption, compression	TLS/SSL, JPEG, ASCII
5	Session	Managing connections between applications	NetBIOS, RPC
4	Transport	Reliable data delivery, flow control	TCP, UDP
3	Network	Logical addressing and routing	IP, ICMP, routers
2	Data Link	Physical addressing and frame delivery	Ethernet, MAC addresses, switches
1	Physical	Raw bit transmission over media	Cables, radio signals, hubs

HTTP, for example, operates at Layer 7 (Application). When a browser requests a web page, the request travels down through each layer on the client side — being encapsulated with headers at each step — crosses the physical network, and then travels back up through the layers on the server side.

The TCP/IP Model¶

The TCP/IP model is a more practical, four-layer simplification used in real-world networking:

TCP/IP Layer	Corresponding OSI Layers	Function
Application	5, 6, 7	Protocols the user interacts with (HTTP, SSH, DNS)
Transport	4	End-to-end communication (TCP, UDP)
Internet	3	Logical addressing and routing (IP)
Network Access	1, 2	Physical transmission and local delivery (Ethernet)

The TCP/IP model reflects how protocols are actually implemented in operating systems. Most troubleshooting maps naturally to these four layers.

Network Address Translation (NAT)¶

NAT allows multiple devices on a private network to share a single public IP address. A router performing Source NAT rewrites the source address of outgoing packets to its own external address, then translates responses back to the original internal address.

This means:

Devices behind NAT can initiate connections to the outside world and receive responses.
External hosts cannot initiate connections to devices behind NAT without additional configuration (port forwarding or an external/floating IP).

In cloud environments like ETAIS, a virtual router performs this function. VMs with only an internal IP operate behind Source NAT. Assigning an external (floating) IP makes the VM directly reachable from outside the private network.

Private vs. Public Address Spaces¶

RFC 1918 defines private IP ranges that are not routable on the public internet:

10.0.0.0/8
172.16.0.0/12
192.168.0.0/16

Cloud projects typically assign VMs addresses from these ranges internally. External/public IPs are drawn from the provider's routable address pool and are required for inbound access from outside the private network.

VPN (Virtual Private Network)¶

A VPN extends a private network across a public network, allowing users to send and receive data as if their devices were directly connected to the private network. VPNs encrypt traffic between the client and the VPN endpoint, providing secure remote access to internal resources that are not exposed to the public internet.

Key Terminology¶

OSI Model: A seven-layer reference model standardised by ISO for understanding and designing network communication.
TCP/IP Model: A four-layer practical networking model that maps to real protocol implementations.
Encapsulation: The process of wrapping data with protocol headers as it moves down the network stack.
NAT (Network Address Translation): A technique that maps private IP addresses to a public address, allowing multiple devices to share one external IP.
Source NAT (SNAT): NAT applied to outgoing traffic, rewriting the source address to the router's external IP.
Floating IP / External IP: A publicly routable IP address assigned to a cloud VM, making it directly reachable from outside the private network.
VPN (Virtual Private Network): An encrypted tunnel that extends a private network across a public one for secure remote access.
Subnet: A logical subdivision of an IP network, defined by a network address and a subnet mask (e.g. 192.168.42.0/24).
Default Gateway: The router address that a host uses to reach networks outside its own subnet.

Why It Matters¶

Troubleshooting: Knowing which layer a problem lives at dramatically narrows the debugging search space. A DNS resolution failure (Layer 7) requires a completely different approach than a cable fault (Layer 1) or a routing issue (Layer 3).
Security: Firewalls, WAFs, and ACLs each operate at different layers. Understanding the model helps you choose the right tool — firewalld filters at Layers 3–4, while ModSecurity inspects Layer 7 content.
Cloud networking: Correctly configuring NAT, floating IPs, security groups, and VPN access requires understanding how traffic flows between layers and across network boundaries.

Common Pitfalls¶

Confusing NAT reachability: A VM with only an internal IP can reach the internet but cannot be reached from outside. Forgetting to assign an external IP (or configure port forwarding) is a common cause of "connection refused" when trying to SSH into a new VM.
Ignoring security groups: Even with a correct external IP, cloud-level firewall rules (security groups) must explicitly allow inbound traffic on the required ports. This is a separate layer from the OS-level firewall.
DNS vs. connectivity: If ping <hostname> fails but ping <ip> works, the problem is at the application layer (DNS resolution), not the network layer. Always test both to isolate the issue.
Forgetting VPN: Resources on a university or corporate internal network are only reachable when connected to the appropriate VPN. Failing to connect before troubleshooting leads to false conclusions.