Används VPN:ens DNS verkligen? Fånga port 53 och se efter

Fråga de flesta vad en VPN-klient gör med DNS och de säger att den ställer in resolveraren, så frågor färdas inne i tunneln. Pushen är verklig; antagandet att den blir en fråga är det inte. Mellan ett pushat alternativ och ett paket på tråden ligger tre steg, och varje steg misslyckas oberoende på sätt som alla ser ut som en trasig DNS-server. Därför kan en läcktestssida och en fungerande webbläsare tycka olika om samma maskin i samma ögonblick.

Ett pushat alternativ är inte en fråga

Steg ett är att servern erbjuder inställningar, till exempel ett pushat DNS-alternativ som namnger en resolverare inne i tunneln. Steg två är att klienten tillämpar dessa inställningar på ett gränssnitt. Steg tre är att ett program faktiskt skickar en fråga till den adressen. Ett fel i steg två lämnar alternativet synligt i anslutningsloggen medan resolverarlistan är oförändrad, och ett fel i steg tre lämnar en helt korrekt resolverarlista oanvänd.

Det mesta av felsökningen smälter samman de tre till en och skyller på VPN-servern, som oftast är den enda parten som kan bevisa att den gjorde sin del. Läs i stället klientens faktiska resolverarstatus och se sedan en fråga gå ut. De två observationerna skiljer konfiguration från routing och från policy, och de tar ungefär fem minuter. Spara fångsterna, för nästa ingenjör vill ha före och efter i stället för en beskrivning av dem.

Kontrollera vad gränssnittet faktiskt håller

På Linux kan systemresolveraren vara den vanliga filen, NetworkManager eller systemd-resolved, och vilken av dem som äger den avgör var en pushad server landar. En OpenVPN-process från kommandoraden uppdaterar inte systemresolveraren själv, så den dokumenterade integrationen är ett up/down-skript eller en anslutningshanterare som redan vet hur inställningarna tillämpas. Att köra båda är ett effektivt sätt att skapa ett kapplöpning.

resolvectl status
cat /etc/resolv.conf

På Windows är listan per adapter, så tunneladaptern kan hålla de interna servrarna medan den fysiska adaptern behåller de lokala och vinner för vissa namn. Jämför båda adaptrarna i stället för den du antar är aktiv.

Följ en fråga ut ur maskinen

Fånga båda gränssnitten samtidigt och lös sedan upp ett namn som borde använda den interna resolveraren. Det paret fångster svarar på det ingen konfigurationsutskrift kan.

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

En fråga som dyker upp på det fysiska gränssnittet och aldrig i tunneln betyder att klienten valde fel resolverare. En fråga på ingen av dem betyder att programmet svarade från cachen, frågade en stub som lyssnar på loopback eller använde en krypterad resolverare vars trafik aldrig syns som port 53. Fånga också svar, inte bara frågor, för en fråga som går ut genom tunneln med ett svar från en offentlig adress är ett annat fel än att inget svar kommer.

Brandväggen som bara accepterar sin egen DNS

Kommersiella klienter installerar ibland egna filterkedjor. Ett dokumenterat mönster tillåter DNS till klientens egen resolverare och kastar all kvarvarande UDP-trafik på port 53 som försöker lämna ett gränssnitt som inte är loopback, inklusive trafik som användaren medvetet dirigerat någon annanstans. Daemonfrågor försvinner spårlöst, vilket läses som ett resolverarfel och inte som ett filter.

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

Om en kastregel utvärderas före ditt undantag nås en tillagd regel aldrig, så sätt in den på första plats och begränsa målet till den resolverare du faktiskt menar.

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

Undantaget är diagnostiskt och inte policy. Om leverantörens regel är avsiktlig är den stödda reparationen att konfigurera klienten att tillåta den resolveraren och registrera beslutet, för en insatt regel överlever inte nästa klientuppgradering.

Varför en läcksida bevisar mindre än den ser ut att göra

Det en läcktestssida visar är den resolverare som talade med testoperatören, inte den din maskin frågade. En lokal vidarebefordrare som rekurserar utåt sätter sin egen utgångsadress på den sidan, och krypterade frågor kan lämna sidan helt tom. Båda resultaten läses fel, det ena som läcka och det andra som garanti, och ingen av läsningarna följer av observationen.

Det försvarbara beviset är fångsten: gränssnitt, destinationsadress, svar och tidsstämpel. Ta en innan tunneln kommer upp och en efter, och jämför dem nästa gång ett namn misslyckas. Det paret säger också till nästa person om felet låg i uppslagning, routing eller i resolverarens egen åtkomstpolicy.