Networking basics

ip, ss, ports, and sockets.

A server’s job is usually to talk to the network, so knowing which programs are listening, on which ports, and who they are talking to is essential — both operationally and for security, since every open port is a door. The modern toolkit is iproute2: ip for addresses and routes, and ss for sockets and ports (ss replaces the old netstat, ip replaces ifconfig). Two commands answer most questions about a host’s network state.

$ ip addr                    # this host’s IP addresses and interfaces
$ ip route                   # the routing table (where does traffic go?)
$ ss -tlnp                   # TCP, listening, numeric, with the owning program
State   Local Address:Port   Process
LISTEN  0.0.0.0:22           users:(("sshd",pid=701))
LISTEN  127.0.0.1:5432       users:(("postgres",pid=812))

Ports, and the crucial 0.0.0.0 vs 127.0.0.1

A listening program binds to an address and port. The address is a security decision: 127.0.0.1 (localhost) means "only this machine can reach me," while 0.0.0.0 means "any interface, including the public network." In the output above, SSH is exposed to the world (0.0.0.0:22) but Postgres is correctly local-only (127.0.0.1:5432). Reading ss -tlnp and asking "should this really be reachable from outside?" is one of the highest-value habits in server security.

Testing connectivity

When something cannot connect, a few tools isolate the problem: ping checks basic reachability, and curl or nc (netcat) test whether a specific port actually answers. Working from the outside in — can I reach the host at all, is the port open, does the service respond — turns "it does not work" into a specific failing step. These are the same moves you used for container networking, applied to a bare host.

$ ping -c3 10.0.1.10                 # is the host reachable at all?
$ nc -zv 10.0.1.10 22                # is port 22 open?
Connection to 10.0.1.10 22 port [tcp/ssh] succeeded!
$ curl -sS http://10.0.1.10/healthz  # does the web service actually answer?