LEARN. PRACTICE. GROW.Concept and mechanism
A flow depends on source, destination, route, kernel forwarding, and applicable policies. Ip route get helps observe a concrete decision; on a multihomed host, include the relevant source and consider routing rules. On an IPv4 router, prepared routes and filters do not replace enabled ip_forward. NAT changes addresses but does not grant universal authorization: a destination on another host still follows the forward path. A change should include return traffic and new connectivity rather than only an old session. Nft -c validates commands without applying changes, but correct syntax does not demonstrate intended policy.
Guided application
Tunnels add encapsulation and can expose MTU problems. Small requests passing while large transfers stall justify measuring that hypothesis without declaring it proven. For a local diagnostic SSH tunnel, confirm loopback binding and the forwarded destination; a high port does not limit who can connect. In dynamic routing, an Established session does not prove prefix acceptance or advertisement. If FRR requires policies and a filter is missing, define permitted scope rather than disabling controls to obtain routes. In a fictional firewall exercise, retain an authorized console and test a new login before closing recovery access. Also record access that should remain denied.
The old SSH session survives but a new one fails: the tests measure different states.
Common pitfalls
NAT as authorization; Established as accepted routes; syntax as connectivity; MTU as certain diagnosis without testing.
Related topics: Automate with evidence · Operate and recover systems · Identity, PAM, and SSH
Validate the complete flow, including cases that should be denied.
Reference: Linux route inspection · Historical LFCE V3.18 (2018-06-12); exam retired 2022-05-01; technical references inspected 2026-09-30