Din VPN-DNS-fallback: vart frågan egentligen tar vägen

En resolverinställning växlar från den privata adressen till en offentlig, och slutsatsen kommer direkt: tunneln läcker. Ibland stämmer det. Ofta reste reservfrågan fortfarande inne i tunneln till en resolver som administratören valt, vilket gör det till ett policybeslut snarare än en defekt. Att skilja dessa fall kräver tre fakta i stället för ett, och det första är vem som svarade. Ta reda på vem som tog emot frågan, vilken rutt som bar den och vilka namn som efterfrågades.

Fallback är en policy, inte ett enda beteende

Varje klient måste bestämma vad den gör när den föredragna resolvern slutar svara. Den kan blockera uppslagning, försöka igen, använda ett konfigurerat alternativ eller överlåta det till operativsystemet, och ur integritetssynpunkt är det fyra olika produkter. Att läsa inställningsskärmen berättar vilket beteende som är konfigurerat; den berättar inte vilket som inträffade. En skärm med en enda brytare beskriver inte fyra möjligheter.

Webbläsare lägger till sitt eget lager. En webbläsare med säker DNS aktiverad kan slå upp ett namn via sin egen valda leverantör även när operativsystemet pekar någon annanstans, vilket innebär att tunnelklientens policy kanske aldrig tillfrågas för de förfrågningar du faktiskt bryr dig om. Kontrollera programmet som gjorde förfrågan, inte bara systeminställningen.

Identiteten hos den ersättande resolvern är det första faktum som är värt att fastställa. En offentlig resolver som tillhör en leverantör du redan litar på är en annan situation än en adress som tillhandahålls av nätverket du råkar vara på. Adressen själv säger sällan vilken av de två du tittar på.

Vem som tar emot frågan efter bytet

Mottagaren och rutten är oberoende, och bara deras kombination beskriver exponeringen. En offentlig resolver som nås genom tunneln ser aldrig adressen till ditt åtkomstnätverk, medan samma resolver nådd direkt ser den. Båda fallen ger ett svar, och ett läckagetest som bara rapporterar resolveradressen kommer att beskriva dem identiskt. Fråga efter gränssnittet såväl som adressen när du läser resultatet.

Interna namn gör skillnaden konkret. En offentlig resolver kan vanligtvis inte svara på ett split-horizon-namn, så frågan misslyckas medan namnet ändå har avslöjats för en part som inte hade något med det att göra. Tillgänglighet och integritet går därför samman här i stället för att bytas mot varandra.

En tunnel kan också bära frågan till en resolver som inte drivs av VPN-leverantören, eftersom tunneln vidarebefordrar i stället för att slå upp. Värden som vidarebefordrar ser frågan i klartext och öppnar sedan sin egen anslutning vidare, vilket skyddar nästa hopp utan att skydda det första.

Kontrollera rutten och mottagaren tillsammans

Observera paketen i stället för konfigurationen. Fråga systemet vilken resolver som skulle användas och bekräfta sedan att frågan verkligen lämnade det förväntade gränssnittet till den förväntade adressen.

resolvectl status | grep -E "Current DNS Server|DNS Servers|DNSOverTLS"
dig +short example.com
tcpdump -ni any udp port 53 or tcp port 853

Om inspelningen visar frågan lämna det fysiska gränssnittet medan tunneln är uppe, kringgick fallbacken tunneln oavsett vad resolverlistan säger. Om den dyker upp på tunnelgränssnittet blir frågan vem som driver den bortre änden och vad den behåller.

Upprepa kontrollen för ett internt namn och ett offentligt namn. Den interna frågan är där en fallback-konfiguration vanligtvis avslöjar sig, eftersom en resolver som inte kan svara ändå tar emot frågan.

Avgör om fallbacken ska tillåtas

Om kravet är att uppslagning stannar när den föredragna resolvern inte är tillgänglig, konfigurera en genomdrivandepolicy som misslyckas stängt och acceptera konsekvensen: namn löses inte under ett avbrott. Det är ett medvetet tillgänglighetsbyte och inte ett fel, och designen bör säga det innan avbrottet inträffar.

Om kravet bara är att frågor inte får resa utanför tunneln, kan en offentlig resolver nådd genom tunneln vara acceptabel förutsatt att operatören och dess lagringspolicy förstås. Ett sådant accepterande är en bedömning av en tredje part och inte ett påstående om kryptografi, och det tillhör den som äger integritetspåståendet. Om interna namn måste fortsätta fungera måste fallbacken vara en resolver som håller de interna zonerna, vilket vanligtvis innebär att fallbackmålet är en annan server och inte en annan adressfamilj.

Dokumentera resultatet som en mening om beteende: vilken resolver som tar emot frågor i normal drift, vilken som tar emot dem efter ett fel och om interna namn löses i det andra fallet. Ett läckagetest som till slut laddar en sida bevisar mindre än den meningen, eftersom en sida kan laddas genom en resolver som aldrig borde ha tillfrågats.