connectivity – Dev-Doc-Ops

Go step-by-step accross the network. Ubuntu 20.

This is some real “bread and butter” for IT professionals.

The job of communication (i.e. payload data transmission) over a network-of-networks is a pretty complex problem. To solve this problem, network communications are broken out/down into protocol stacks; each protocol in the stack incrementally solving a part of the larger problem. The TCP/IP stack has emerged as the winner of the protocol wars, beating out the likes of SPX/IPX, AppleTalk, NetBIOS, etc. The situation is very much like VHS winning over Betamax in the videotape format war, and Blu-ray beating HD DVD in the optical disc war.

Each layer of the TCP/IP protocol stack solves a discrete part, or sub-dividision, of the communication problem, and represents an abstraction layer. Each distinct layer has its own job in getting data payload, from a running source process, one more step closer to the receiving destination process. As a helpful reminder, here are most of the the key ingredients for the internet protocol stack:

Protocol	Job
Application protocol (http(s), smtp, ssh, etc.)	The job of the application protocol is to facilitate the actual payload data from running process on source host, to running process on destination. And thus, finally solving the communication problem.
Transmissiont Control Protocol (TCP) / User Datagram Protocol (UDP)	The job of TCP/UDP is to get you to the correct running process “post box” or “pigeon hole” inside of the destination host.
Internet Protocol (IP) / Internet Control Messaging Protocol (ICMP)	The job of IP is to get you from source host, on source network, over to destination host, on destination network.
Ethernet / Wi-Fi	The job of Ethernet (physical + data-link) is to get you from one side of a single network / broadcast domain to the other side (usually a gateway).

TCP/IP protocols are open, collaborative, and progressive in nature. Individual standards documentation for each protocol are maintained by the Internet Engineering Task Force (IEFT) in the form of RFCs.

Local IP Config / Protocol Stack

Check you have IP address, subnet mask, gateway, and DNS servers.

# Your filename may be different
sudo vi /etc/neplan/00-installer-config.yaml

----

# This is the network config written by 'subiquity' 

network: 
  ethernets: 
    eth0: 
      addresses: 
      - 10.1.2.3/24 
      gateway4: 10.1.2.1 
      nameservers: 
        addresses: 
        - 10.2.2.41 
        - 10.2.3.41 
        search: 
        - example.com 
    eth1: 
      addresses: 
      - 10.2.3.12/24 
  version: 2 

----

sudo netplan apply

Check your network interface is “UP” and the IP config running against each interface looks correct.

ip a
hostname -I
ifconfig
ifup <ethx>
ifdown <ethx>

Check routing table information.

route -n
ip route
netstat -rn

Check your own public IP address.

curl ifconfig.co

Local Firewall

Ubuntu’s Uncomplicated Firewall command is a useful front for manipulating iptables.

sudo systemctl status ufw
sudo ufw status
sudo ufw status verbose
sudo ufw show raw
sudo ufw logging on [off]
cat /etc/ufw/*.rules

Ubuntu has a community wiki page for ufw.

DNS

Ultimately the destination host is reached by its IP address, but if DNS names are used then we should check they resolve to the correct IP address.

Check the DNS client’s configured name resolver servers.

nmcli device show <interfacename> | grep IP4.DNS
systemd-resolve --status | grep Current
cat /run/systemd/resolve/resolv.conf

Ensure your DNS name resolves to the correct IP address.

nslookup example.com

# To check against Google public DNS servers

nslookup example.com 8.8.8.8 [4.4.4.4]

ICMP / IP

Check the destination host IP interface is reachable, and also the route taken.

ping -c 3 1.2.3.4
ping -c www.example.com

tracert 1.2.3.4
tracert www.example.com

Transport

Check connection establishment to the receiving process.

# TCP
nc -z -v www.example.com 80
telnet www.example.com 22

# UDP
nc -u www.example.com 443

Inspect the state of network connections and related processes.

netstat -a
netstat --listening --numeric-ports --programs --tcp
netstat --numeric-ports --programs | grep 443
netstat -altp
netstat -tupan | grep -i http
netstat -ano | findstr "10389" | findstr "["

Securtiy Layer

Check TLS settings and certificate information.

openssl s_client -connect example.com:443

Application Process

Check service status.

systemctl status <service_name>
systemctl is-enabled <service_name>
systemctl list-unit-files --state=enabled
systemctl list-unit-files --state=disabled
systemctl list-units --type=service [--state=running]
systemctl list-units --type=service --all

Check running process status.

sudo ps -ef | grep <string>

And there you have it! Hopefully the above steps will help you travel end-to-end on the communication journey to isolate / check many of the problems that you may encounter surrounding TCP/IP networking.

If you have any thoughts or suggestions please feel free to add into the comments below or contact Andrew using details on this site’s About page – we can always update this article to include anything that has been missed.

Tag: connectivity

Connectivity Testing TCP/IP