Uw VPN-DNS-fallback: waar de query werkelijk naartoe gaat

Een resolverinstelling schakelt van het privéadres naar een openbaar adres, en de conclusie komt meteen: de tunnel lekt. Soms is dat zo. Vaak reisde de reservequery toch binnen de tunnel naar een resolver die de beheerder had gekozen, wat er een beleidsbeslissing van maakt in plaats van een defect. Die gevallen scheiden vereist drie feiten in plaats van één, en het eerste is wie er antwoordde. Zoek uit wie de query ontving, welke route hem droeg en naar welke namen is gevraagd.

Fallback is een beleid, niet één gedrag

Elke client moet beslissen wat hij doet wanneer de voorkeursresolver stopt met antwoorden. Hij kan de resolutie blokkeren, het opnieuw proberen, een geconfigureerd alternatief gebruiken of het aan het besturingssysteem overlaten, en vanuit privacyoogpunt zijn dat vier verschillende producten. Het instellingenscherm lezen vertelt u welk gedrag is geconfigureerd; het vertelt u niet welk gedrag zich heeft voorgedaan. Een scherm met één schakelaar beschrijft geen vier mogelijkheden.

Browsers voegen hun eigen laag toe. Een browser met beveiligde DNS ingeschakeld kan een naam via zijn eigen gekozen provider oplossen, zelfs wanneer het besturingssysteem elders naartoe wijst, wat betekent dat het beleid van de tunnelclient misschien nooit wordt geraadpleegd voor de verzoeken die u echt belangrijk vindt. Controleer de applicatie die het verzoek deed, niet alleen de systeeminstelling.

De identiteit van de vervangende resolver is het eerste feit dat het waard is vast te stellen. Een openbare resolver van een provider die u al vertrouwt, is een andere situatie dan een adres dat wordt geleverd door het netwerk waarop u toevallig zit. Het adres zelf zegt zelden welke van de twee u voor zich hebt.

Wie de query na de wissel ontvangt

De ontvanger en de route zijn onafhankelijk, en alleen hun combinatie beschrijft de blootstelling. Een openbare resolver bereikt via de tunnel ziet nooit het adres van uw toegangsnetwerk, terwijl dezelfde resolver direct bereikt dat wel ziet. Beide gevallen leveren een antwoord op, en een lektest die alleen het resolveradres rapporteert, zal ze identiek beschrijven. Vraag bij het lezen van het resultaat om de interface én het adres.

Interne namen maken het onderscheid concreet. Een openbare resolver kan een split-horizonnaam meestal niet beantwoorden, dus de query mislukt terwijl de naam toch is onthuld aan een partij die er niets mee te maken had. Beschikbaarheid en privacy gaan hier dus samen in plaats van tegen elkaar te worden ingeruild.

Een tunnel kan de query ook naar een resolver dragen die niet door de VPN-provider wordt beheerd, omdat de tunnel doorstuurt in plaats van op te lossen. De doorsturende host ziet de query in platte tekst en opent daarna zijn eigen verbinding verder, wat de volgende hop beschermt zonder de eerste te beschermen.

Controleer de route en de ontvanger samen

Observeer de pakketten in plaats van de configuratie. Vraag het systeem welke resolver gebruikt zou worden en bevestig dan dat de query daadwerkelijk van de verwachte interface naar het verwachte adres is vertrokken.

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

Als de opname laat zien dat de query de fysieke interface verlaat terwijl de tunnel actief is, heeft de fallback de tunnel omzeild ongeacht wat de resolverslijst zegt. Als hij op de tunnelinterface verschijnt, wordt de vraag wie het verre uiteinde beheert en wat het bewaart.

Herhaal de controle voor één interne naam en één openbare naam. De interne query is waar een fallbackconfiguratie zich meestal openbaart, omdat een resolver die niet kan antwoorden de vraag toch ontvangt.

Bepaal of de fallback moet worden toegestaan

Als de eis is dat resolutie stopt wanneer de voorkeursresolver niet beschikbaar is, configureer dan een handhavingsbeleid dat gesloten faalt en accepteer het gevolg: namen worden tijdens een storing niet opgelost. Dat is een bewuste beschikbaarheidsruil en geen storing, en het ontwerp zou dat moeten zeggen voordat de storing plaatsvindt.

Als de eis alleen is dat queries niet buiten de tunnel mogen reizen, kan een openbare resolver bereikt via de tunnel aanvaardbaar zijn mits de exploitant en zijn bewaarbeleid worden begrepen. Zo'n aanvaarding is een oordeel over een derde partij en geen uitspraak over cryptografie, en ze hoort bij degene die de privacymaking bezit. Als interne namen moeten blijven werken, moet de fallback een resolver zijn die de interne zones bevat, wat meestal betekent dat het fallbackdoel een andere server is en geen andere adresfamilie.

Documenteer de uitkomst als een zin over gedrag: welke resolver queries ontvangt in normaal bedrijf, welke ze na een storing ontvangt, en of interne namen in het tweede geval worden opgelost. Een lektest die uiteindelijk een pagina laadt, bewijst minder dan die zin, omdat een pagina kan laden via een resolver die nooit geraadpleegd had mogen worden.