CUNP common mistakes
CUNP · Understand the traps and how to avoid them.
Reading netstat/ss output and assuming a listening socket on 0.0.0.0 means the service is reachable, without checking the firewall, bind address, or whether the process is actually running on the interface the client uses.
Candidates memorize that 0.0.0.0 means 'all interfaces' and stop there, conflating socket binding with end-to-end reachability. The exam deliberately separates local binding state from path-level connectivity, and candidates answer from the first fact they recognize.
What to do instead
For any 'is it reachable' question, walk the chain explicitly: process listening (ss -lntp), bind address/scope, local firewall (nft/iptables rules), routing to the client, and any upstream ACL. Practice classifying each failure as bind-time, filter-time, or route-time before choosing an answer.
Misreading ip route output and longest-prefix match, e.g. treating a default route as taking precedence over a more specific /24, or confusing the 'via' gateway with the destination network.
Candidates learn the routing table as a list rather than a lookup algorithm. Under time pressure they pick the first matching line or the default route, ignoring that the kernel selects the longest prefix regardless of table order or metric.
What to do instead
Rehearse the lookup order: longest prefix wins; among equal prefixes, lowest metric; then policy rules (ip rule) are consulted in priority order before the main table. Work through 5-10 synthetic tables, writing the winning route and outgoing interface for each destination by hand.
Confusing the three TCP handshake and teardown states, attributing TIME_WAIT to a server bug, or claiming a connection in SYN_RECV means the service is down.
State names are memorized as vocabulary without the state machine behind them. Candidates do not connect TIME_WAIT to the side that closed first, or SYN_RECV to a half-open handshake where the final ACK is missing (often a firewall dropping it).
What to do instead
Draw the state diagram from memory weekly and label which side (client/server) sits in each state and for how long. For any 'many sockets in state X' scenario, state the cause (e.g. SYN_RECV -> SYN cookies off or ACK filtered; TIME_WAIT -> active closer with 2*MSL) before picking an answer.
Treating a DNS resolution failure as a network-layer problem, or vice versa, without checking /etc/nsswitch.conf, /etc/resolv.conf, and the resolver search order first.
Candidates jump to ping/traceroute because those are the tools they know best, skipping the name-service switch and resolver configuration that determine whether a name is resolved from files, DNS, or another source. They also forget that a ping failure after successful resolution isolates the fault to layer 3+.
What to do instead
Adopt a fixed triage order: resolve the name (getent hosts, dig +trace), then test the path (ping, traceroute), then the port (nc -zv, curl -v). Learn to read nsswitch.conf hosts: line and resolv.conf search/options, and practice stating which layer is exonerated at each step.
Writing shell scripts that parse command output with awk/sed on unstable formats, or that ignore quoting and exit codes, then failing questions about why a pipeline reports success despite failure.
Candidates script by imitation and do not internalize that pipelines return the last command's status, that unquoted variables word-split and glob, and that human-readable output formats are not a stable API.
What to do instead
Practice set -euo pipefail, quoting every expansion, using set -o pipefail to surface upstream failures, and preferring machine-readable output (ip -j, ss -H, dig +short) over screen-scraping. Write three small scripts that must fail loudly on a bad hostname and verify exit codes with echo $?.
Confusing authentication with authorization when reasoning about SSH, sudo, or PAM, e.g. assuming a valid key means the user may log in, or that a sudoers entry is checked before authentication.
Candidates collapse 'who are you' and 'what may you do' into one step. The exam tests layered controls (PAM stack, sshd AllowUsers/AllowGroups, sudoers, file permissions) where each layer can independently deny access.
What to do instead
For each scenario, list the layers in order (network ACL -> sshd config -> PAM -> account/shell -> sudoers -> filesystem) and identify which layer denies. Learn the PAM stack order (auth, account, password, session) and where pam_access or pam_nologin sit in it.
Assuming iptables/nftables rules take effect in the order written on the command line rather than by chain and hook traversal, and forgetting that a drop in a base chain ends evaluation.
Candidates treat firewall rules as a flat list. They do not trace packet flow through PREROUTING, INPUT/FORWARD/OUTPUT, and POSTROUTING, nor do they account for connection tracking letting established flows bypass filter rules.
What to do instead
Draw the netfilter hook diagram and trace a sample packet (inbound new connection, reply, forwarded) through each table and chain. Practice predicting the verdict for a packet given a rule set, including the effect of conntrack state and the chain policy.
Misattributing latency or throughput problems to the wrong layer, e.g. blaming bandwidth for high latency, or ignoring that a small MTU or PMTUD blackhole causes hangs on large transfers but not small pings.
Candidates reach for the tool they know (speed test, ping) rather than measuring the right quantity. They miss the classic signature: small packets succeed, large ones stall, pointing to MTU/fragmentation rather than loss or congestion.
What to do instead
Learn to pair symptom with measurement: ping -M do -s for MTU, mtr for per-hop loss, ss -ti for retransmits and cwnd, iperf3 for throughput. Build a symptom-to-tool table and practice naming the layer each tool tests.
Treating interface configuration as persistent when it was applied with ip addr add or ifconfig at runtime, and confusing the link state with the addressing state.
Candidates practice on live systems where runtime changes work immediately, so they do not distinguish volatile kernel state from the configuration files (NetworkManager, systemd-networkd, /etc/network/interfaces) that survive reboot.
What to do instead
For every interface task, state both the runtime command and the persistent configuration file that encodes it, and how to verify after a reload (nmcli con show, networkctl status, ip -br addr). Practice spotting a config that exists only in the running kernel.
Ignoring service supervision when debugging a daemon, e.g. starting a daemon manually while systemd already manages it, or editing unit files without daemon-reload, then concluding the config change had no effect.
Candidates debug the daemon binary but not its supervisor. They miss that systemd may restart, mask, or override a unit, and that changes to unit files require daemon-reload and restart to take effect.
What to do instead
Always check systemctl status, systemctl cat (to see drop-ins), and journalctl -u before touching the binary. Learn the reload sequence (edit -> daemon-reload -> restart) and how to verify the effective config with systemctl show and the process's actual command line.