Diagnose why a workstation cannot reach external websites by validating interface addressing, routing, DNS, and raw IP connectivity. Prove the root cause with CLI evidence and confirm the system’s resolver configuration.
A user reports they cannot access external websites. You must determine whether the issue is IP addressing, default routing, DNS resolution, or upstream connectivity, and capture evidence for each layer.
This is the minimum set of checks you run before blaming the ISP, the firewall, or “the internet.” You gather proof for what works, what fails, and where it fails.
/etc/resolv.conf shows what the host will use for name resolution, but it may be managed by a network service.
ip aThis proves whether the interface is up and whether it has a valid IPv4 address. If the host has no address, DNS and routing checks are premature.
# Look for an "inet" line on the active interface (example):
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
inet 192.168.1.42/24 brd 192.168.1.255 scope global eth0ip route
External access requires a default route. If there is no default via line,
the machine will not know where to send traffic off the local subnet.
# Confirm a default gateway exists (example):
default via 192.168.1.1 dev eth0 proto dhcp metric 100dig google.comThis isolates name resolution from raw connectivity. If DNS fails but pinging a public IP works, your root cause is likely resolver configuration or upstream DNS reachability.
# Any valid A/AAAA answer indicates resolution is working:
google.com. 300 IN A 142.250.190.78ping -c 4 1.1.1.1Pinging a known public IP tells you whether the host can get out to the internet at all. If this fails, focus on addressing, routing, firewall rules, or upstream network access.
# Look for 0% packet loss (example):
4 packets transmitted, 4 received, 0% packet losscat /etc/resolv.confThis file shows which nameservers the host is using for DNS. If it points at an unreachable resolver, lookups will fail even if raw IP connectivity works.
# Example:
nameserver 1.1.1.1
nameserver 8.8.8.8ip addr showThis gives a clean summary view of addresses and link state. It is useful after making changes, renewing DHCP, or restarting network services to confirm you are still configured correctly.
# Confirm the expected IPv4 is still present on the interface:
inet 192.168.1.42/24DHCP may have failed, or the host may be configured statically with no address. Confirm whether the interface should use DHCP or a static config, then re-run your address check.
Without a default via route, the host cannot reach off-subnet destinations.
Fix gateway configuration first, then re-test raw IP reachability.
Connectivity is fine. Focus on resolver configuration: check /etc/resolv.conf, confirm
the listed nameservers are reachable, and verify upstream DNS policy.
The issue may be application-layer (proxy, firewall policy, TLS inspection, or browser config). Confirm reachability with a simple CLI request tool if available, and validate proxy settings.
This lab is primarily diagnostic. If you changed addressing or resolver settings during troubleshooting, confirm the machine has a valid address, a default route, and working DNS.
ip addr show
ip route
cat /etc/resolv.conf
The host shows a valid IPv4 address, a default via route, and resolvers you can reach.
ip a / ip addr show: Displays interfaces, link state, and assigned IP addresses.
ip route: Displays the routing table, including the default gateway.
dig <name>: Queries DNS records and shows whether name resolution works.
host <name>: Quick DNS lookup that returns A/AAAA and other records.
nslookup <name>: DNS query tool commonly present on many systems.
ping -c <count> <ip>: Tests reachability to an IP address while limiting packet count.
/etc/resolv.conf: Resolver configuration used by libc for DNS lookups (nameserver entries).