Introduction
Network troubleshooting is easier when you check one layer at a time. Start with the host's identity, then confirm its interfaces and addresses, route selection, basic reachability, name resolution, listening sockets, application response, and finally local firewall policy.
In this lab, you will follow that sequence on an Ubuntu host. A prepared HTTP service listens only on loopback port 8088, giving you a safe target for ss, curl, and UFW rule practice. You will not change the host's interface configuration, default route, DNS settings, or SSH service. Before enabling UFW, you will explicitly preserve SSH access.
Identify the Host
In this step, you will inspect the host name and the local name records that help programs identify this machine.
Enter the lab workspace:
cd /home/labex/project/network-lab
Print the current host name:
hostname
Display the static, transient, and operating-system identity known to systemd:
hostnamectl
Static hostname is the configured name. In cloud training machines, the transient name may be assigned during boot.
Inspect local host mappings:
cat /etc/hosts
The loopback names localhost, 127.0.0.1, and ::1 identify this same host without external networking. Show the host's assigned IP addresses in compact form:
hostname -I
Save the host name and address list:
printf 'hostname=%s\naddresses=%s\n' "$(hostname)" "$(hostname -I | xargs)" > host-identity.txt
cat host-identity.txt
Inspect Interfaces and IP Addresses
In this step, you will identify network interfaces, link state, IPv4 addresses, prefixes, and address scope.
Use the brief link view:
ip -brief link
lo is the loopback interface. Another interface, commonly named eth0 or ens..., connects the VM to its network. UP means the interface is administratively enabled.
Display addresses in compact form:
ip -brief address
An address such as 192.0.2.10/24 combines an IPv4 address and prefix length. The prefix describes which leading bits identify the local network.
Inspect loopback in full detail:
ip address show dev lo
The IPv4 address 127.0.0.1/8 has scope host, so it is valid only inside this host. Find the interface used by the default route:
primary_if=$(ip route show default | awk 'NR==1 {print $5}')
echo "Primary interface: $primary_if"
ip address show dev "$primary_if"
The ifconfig command is an older interface tool that still appears in existing runbooks and troubleshooting instructions. Compare its output with the modern ip output you just read:
ifconfig
Save the legacy view as well:
ifconfig > ifconfig-addresses.txt
Save a brief interface snapshot:
ip -brief address > interface-addresses.txt
cat interface-addresses.txt
Read the Routing Table
In this step, you will identify the default gateway and ask Linux which route it would use for a destination.
Display the main routing table:
ip route
Connected routes describe directly attached networks. A line beginning with default via is used when no more specific route matches.
Ask the kernel how it would reach a public destination. This command reports the selected gateway, interface, and source address without sending a packet:
ip route get 1.1.1.1
Extract the default gateway and interface:
gateway=$(ip route show default | awk 'NR==1 {print $3}')
primary_if=$(ip route show default | awk 'NR==1 {print $5}')
echo "Default gateway: $gateway via $primary_if"
Save the route summary:
printf 'gateway=%s\ninterface=%s\n' "$gateway" "$primary_if" > route-summary.txt
cat route-summary.txt
Test Network Reachability
In this step, you will use ping to test increasingly distant boundaries while recognizing that some networks block diagnostic packets.
Start with loopback. The options -c 2 send two requests and -W 2 wait at most two seconds for each reply:
ping -c 2 -W 2 127.0.0.1
A successful loopback test proves the local IP stack responds. Next, retrieve and test the default gateway:
gateway=$(ip route show default | awk 'NR==1 {print $3}')
ping -c 2 -W 2 "$gateway" || echo "The gateway does not answer ICMP echo requests"
The fallback message matters because a router can forward traffic while refusing ping. Test a public IP address without relying on DNS:
ping -c 2 -W 2 1.1.1.1 || echo "Public ICMP is blocked or unavailable"
Save a stable local connectivity result rather than depending on external policy:
ping -c 1 -W 2 127.0.0.1 > loopback-ping.txt
tail -n 2 loopback-ping.txt
Test Host Name Resolution
In this step, you will inspect resolver configuration and translate host names into addresses.
View the resolver file used by standard Linux applications:
cat /etc/resolv.conf
It commonly contains one or more nameserver lines. On systemd-resolved hosts, the address can identify a local stub resolver rather than an external DNS server directly.
Resolve a local name through the system's complete name-service configuration:
getent hosts localhost
getent follows /etc/nsswitch.conf, so it can combine /etc/hosts, DNS, and other configured sources. Resolve an external name and request IPv4 socket addresses:
getent ahostsv4 example.com
If IP ping succeeds but this lookup fails, focus on resolver configuration or DNS reachability. Save the first resolved IPv4 record:
getent ahostsv4 example.com | head -n 1 > dns-result.txt
cat dns-result.txt
Inspect a Listening Port and HTTP Response
In this step, you will connect a listening TCP socket to its owning process and test the application protocol.
The prepared demo service listens on loopback port 8088. Use ss to inspect listening TCP sockets. The options -l, -t, -n, and -p mean listening, TCP, numeric addresses, and process information:
sudo ss -ltnp | grep ':8088'
Look for 127.0.0.1:8088. Binding to loopback means the service is reachable only from this host.
Check the service process behind the socket:
systemctl status labex-network-demo.service --no-pager
Use curl -i to display the HTTP response headers and body:
curl -i http://127.0.0.1:8088/
An HTTP 200 OK status proves more than an open port: the application accepted an HTTP request and returned content. Save only the response body with silent mode -s:
cd /home/labex/project/network-lab
curl -s http://127.0.0.1:8088/ > http-response.html
grep 'network demo ready' http-response.html
Preserve Access and Enable UFW
In this step, you will inspect UFW state, preserve remote administration access, allow the practice service port, and enable the firewall.
UFW is a front end for Linux packet-filtering rules. Inspect its current state:
sudo ufw status verbose
The setup leaves UFW inactive with a clean rule set. Before enabling any host firewall remotely, allow the management path you depend on. This VM uses TCP port 22 for SSH:
sudo ufw allow 22/tcp
Now allow inbound TCP traffic to the practice service port:
sudo ufw allow 8088/tcp
Review the prepared changes before activation:
sudo ufw show added
Enable UFW without an interactive confirmation prompt:
sudo ufw --force enable
Confirm that the firewall is active and both allowances are present:
sudo ufw status verbose
The service is bound to loopback, so test it locally after the firewall change:
curl -fsS http://127.0.0.1:8088/
Save the active status as an observable result:
cd /home/labex/project/network-lab
sudo ufw status verbose > firewall-status.txt
cat firewall-status.txt
The order matters: preserve the administration path, add required service rules, enable the firewall, and immediately verify both policy and application reachability. Production hosts may use a different SSH port, so confirm the real management path instead of assuming port 22.
Summary
You followed a structured Linux network diagnostic chain: host identity, interfaces and IP addresses, route selection, reachability, name resolution, listening sockets, and HTTP response. You learned that each layer answers a different question and that failure at one boundary narrows the next investigation.
You also preserved SSH access, allowed a practice service port, enabled UFW, and verified both the active policy and the application's response. These habits prepare you to diagnose and secure a network service without making broad, disruptive changes.
