Split DNS and default route on a dual-homed workstation
A Debian 12 laptop uses NetworkManager and systemd-resolved. enp3s0 is on the office LAN 192.168.50.0/24 with gateway 192.168.50.1 and DNS 192.168.50.1. wlp2s0 connects to the lab Wi-Fi 10.20.0.0/16 with gateway 10.20.0.1 and DNS 10.20.0.53. Both connections are configured as default routes. ssh build.lab.example sometimes reaches 10.20.1.5 and sometimes times out; ping 10.20.1.5 always works. ping build.lab.example sometimes resolves to 192.168.50.77, a decommissioned office server. resolvectl status shows both links with DNS servers and +DefaultRoute; no search domains are configured. /etc/resolv.conf is a symlink to /run/systemd/resolve/stub-resolv.conf. Internet traffic should use the office link; only 10.20.0.0/16 and names under lab.example should use Wi-Fi. The laptop must keep working after suspend/resume and after switching networks.
1. Explain the two independent causes of the intermittent SSH failure. Which commands distinguish a DNS answer problem from a routing problem?
Read the worked answer
Two things are wrong. Both links have +DefaultRoute, so systemd-resolved may send build.lab.example to the office DNS and accept its stale 192.168.50.77; the lab DNS has the right 10.20.1.5. The default route can also flip to Wi-Fi, which does not break the directly connected 10.20.0.0/16 route but does break policy for other traffic and can confuse name resolution if the resolver follows the default link. Distinguish with resolvectl query build.lab.example (shows which link and address answered), resolvectl status, dig @192.168.50.1 build.lab.example, dig @10.20.0.53 build.lab.example, ip route get 10.20.1.5, and ip route get 192.168.50.77. If ping 10.20.1.5 works but the name gives 192.168.50.77, it is DNS. If the correct address is returned but ssh hangs, inspect ip route get 10.20.1.5, ss -tn state syn-sent, and the firewall. Also check getent hosts build.lab.example to see the NSS path.
2. Give persistent NetworkManager changes so the office link is the only default route, Wi-Fi is used for 10.20.0.0/16 and lab.example DNS, and answer which mechanism routes only that DNS suffix.
Read the worked answer
Use NetworkManager properties, not hand-edited /etc/resolv.conf, which is a stub symlink. Assuming connection names office and lab-wifi:
nmcli con mod office ipv4.never-default no ipv4.route-metric 100
nmcli con mod lab-wifi ipv4.never-default yes ipv4.route-metric 600 ipv4.dns-search '~lab.example'
nmcli con up office
nmcli con up lab-wifi
ipv4.never-default yes removes the Wi-Fi default route but keeps its connected 10.20.0.0/16 route and its DNS server reachable. The lower metric on office makes it the preferred default. The ~lab.example search entry is a systemd-resolved routing domain: queries for that suffix go only to the link that owns the domain, preventing the office DNS from answering with the stale address. Verify with ip route, ip route get 10.20.1.5, resolvectl domain, resolvectl status, and resolvectl query build.lab.example. If DHCP supplies unwanted DNS servers, also set ipv4.ignore-auto-dns yes and list the intended server. The nonpersistent equivalent is resolvectl domain wlp2s0 '~lab.example', which will be lost on reconnect.
3. After the change, resolvectl query build.lab.example returns 10.20.1.5, but ssh still hangs at Connecting. What are the three most likely layers to check and what single command for each?
Read the worked answer
First confirm the resolver is no longer the problem: resolvectl query build.lab.example returns 10.20.1.5. Then check layers. Local route: ip route get 10.20.1.5 must show dev wlp2s0 src 10.20.x.x; if it shows enp3s0 or the office default, the /16 route is missing and nmcli device status plus ip addr show wlp2s0 will show Wi-Fi down. Local firewall: sudo nft list ruleset or sudo iptables -S for a drop on output to 10.20.0.0/16 or on established/related traffic. Path/server: nc -vz -w 3 10.20.1.5 22 and ssh -vvv; ip neigh show 10.20.1.5 shows whether ARP/ND resolution succeeds. If ARP resolves but TCP stays in SYN-SENT, suspect AP client isolation, a server-side firewall, or sshd not listening (ss -ltn sport = :22 on the server). Check journalctl -u NetworkManager after resume, because a suspended Wi-Fi link can take seconds to reassociate while SSH is already attempting.