Wordt de DNS van je VPN echt gebruikt? Vang poort 53 en kijk

Vraag de meeste mensen wat een VPN-client met DNS doet en ze zeggen dat hij de resolver instelt, zodat queries binnen de tunnel reizen. De push is echt; de aanname dat er een query uit volgt niet. Tussen een gepushte optie en een pakket op de draad liggen drie fasen, en elk faalt onafhankelijk op manieren die allemaal op een kapotte DNS-server lijken. Daarom kunnen een lektettestpagina en een werkende browser het op hetzelfde moment oneens zijn over dezelfde machine.

Een gepushte optie is geen query

Fase één is dat de server instellingen aanbiedt, bijvoorbeeld een gepushte DNS-optie die een resolver in de tunnel noemt. Fase twee is dat de client die instellingen op een interface toepast. Fase drie is dat een toepassing daadwerkelijk een query naar dat adres stuurt. Een fout in fase twee laat de optie zichtbaar in het verbindingslog terwijl de resolverlijst ongewijzigd blijft, en een fout in fase drie laat een volledig correcte resolverlijst ongebruikt.

De meeste probleemoplossing smelt die drie samen tot één en geeft de VPN-server de schuld, die meestal de enige partij is die kan bewijzen dat hij zijn deel deed. Lees in plaats daarvan de werkelijke resolverstatus van de client en kijk dan hoe één query vertrekt. Die twee waarnemingen scheiden configuratie van routing en van beleid, en ze kosten ongeveer vijf minuten. Bewaar de opnames, want de volgende engineer wil het voor en na, geen beschrijving ervan.

Controleer wat de interface werkelijk vasthoudt

Op Linux kan de systeemresolver het gewone bestand, NetworkManager of systemd-resolved zijn, en welke daarvan hem bezit bepaalt waar een gepushte server landt. Een OpenVPN-proces vanaf de opdrachtregel werkt de systeemresolver niet zelf bij, dus de gedocumenteerde integratie is een up/down-script of een verbindingsbeheerder die de instellingen al kan toepassen. Beide draaien is een efficiënte manier om een race te maken.

resolvectl status
cat /etc/resolv.conf

Op Windows is de lijst per adapter, dus de tunneladapter kan de interne servers houden terwijl de fysieke adapter de lokale houdt en voor sommige namen wint. Vergelijk beide adapters in plaats van degene waarvan je aanneemt dat hij actief is.

Volg één query de machine uit

Leg beide interfaces tegelijk vast en los dan één naam op die de interne resolver zou moeten gebruiken. Dat paar opnames beantwoordt wat geen enkele configuratie-uitvoer kan.

sudo tcpdump -ni tun0 port 53
sudo tcpdump -ni any port 53

Een query die op de fysieke interface verschijnt en nooit in de tunnel, betekent dat de client de verkeerde resolver koos. Een query op geen van beide betekent dat de toepassing uit de cache antwoordde, een stub op loopback vroeg of een versleutelde resolver gebruikte waarvan het verkeer nooit als poort 53 verschijnt. Leg ook antwoorden vast, niet alleen queries, want een query die door de tunnel naar buiten gaat met een antwoord van een openbaar adres is een andere fout dan helemaal geen antwoord.

De firewall die alleen zijn eigen DNS accepteert

Commerciële clients installeren soms hun eigen filterketens. Eén gedocumenteerd patroon staat DNS naar de eigen resolver van de client toe en gooit al het overige UDP-verkeer op poort 53 weg dat een niet-loopback-interface probeert te verlaten, inclusief verkeer dat de gebruiker bewust elders heeft gerouteerd. Daemon-queries verdwijnen zonder spoor, wat als een resolverfout wordt gelezen en niet als een filter.

sudo iptables -S OUTPUT
sudo iptables -S | grep -i -E 'dns|53'

Wordt een verwervingsregel vóór je uitzondering geëvalueerd, dan wordt een toegevoegde regel nooit bereikt, dus voeg hem op de eerste positie in en beperk de bestemming tot de resolver die je werkelijk bedoelt.

sudo iptables -I OUTPUT 1 -p udp --dport 53 -d 172.20.8.1 -j ACCEPT

Die uitzondering is diagnostisch en geen beleid. Is de regel van de leverancier bewust, dan is de ondersteunde reparatie de client zo te configureren dat hij die resolver toestaat en de beslissing vast te leggen, want een ingevoegde regel overleeft de volgende clientupdate niet.

Waarom een lektepagina minder bewijst dan het lijkt

Wat een lektettestpagina toont, is de resolver die met de testbeheerder sprak, niet degene die je machine raadpleegde. Een lokale doorstuurder die naar buiten recurseert zet zijn eigen uitgangsadres op die pagina, en versleutelde queries kunnen de pagina helemaal leeg laten. Beide resultaten worden verkeerd gelezen, het ene als lek en het andere als garantie, en geen van beide lezingen volgt uit de waarneming.

Het verdedigbare bewijs is de opname: interface, bestemmingsadres, antwoord en tijdstempel. Neem er één voordat de tunnel omhoog komt en één daarna, en vergelijk ze de volgende keer dat een naam faalt. Dat paar vertelt de volgende persoon ook of de fout in de resolutie, de routing of het eigen toegangsbeleid van de resolver zat.