Hvorfor DNS holder op med at virke, når OpenVPN forbinder på Windows

Et ping til kontorets resolver får stadig svar, efter at "OpenVPN" har forbundet, og alligevel fejler hvert navneopslag. Adressen kan nås, mens porten ikke kan, en kombination der giver mening, når man ved, at Windows kan filtrere DNS per adapter. Med block-outside-dns i profilen er det filter den første mistænkte, og rutetabellen er det forkerte sted at kigge. De to test nedenfor skiller lagene på få sekunder.

Tilgængelig adresse, død port

Et vellykket ping beviser, at værten kører, og at der findes en vej. Det siger intet om tilladelse til at nå port 53, fordi det pågældende filter arbejder på et andet lag og er knyttet til adapteren. Derfor kan samme maskine svare på ICMP og afvise hver forespørgsel sendt til samme adresse. Kør begge test i samme session, før du ændrer nogen konfiguration.

ping <resolver-ip>
nslookup <name> <resolver-ip>

Parret er diagnosen. Almindelig trafik til undernettet fortsætter, mens navneopløsningen dør, og folk konkluderer, at serveren er i stykker, eller at DNS aldrig blev sendt. Begge forklaringer er dyre at forfølge, og beviserne peger et smallere sted hen. Bekræft parret, før du rører en indstilling.

Indstillingen er en regel i filtreringsplatformen

OpenVPN-referenceen beskriver block-outside-dns som en begrænsning i Windows Filtering Platform, der forhindrer programmer i at nå DNS på adaptere uden for tunnelen. Den dækker TCP og UDP port 53. Fordi filteret ligger i WFP og ikke i den almindelige regeliste i firewallen, ændrer en tilladelsesregel andre steder ikke nødvendigvis resultatet. Derfor bliver det almindelige råd om at tillade DNS ved med at fejle.

Indstillingen kan komme fra den importerede profil eller fra serveren, og den fil, du sidst redigerede, "er ikke bevis for, hvad klienten har indlæst". Læs den effektive konfiguration og forbindelsesloggen sammen. Indstillingen er også Windows-specifik, og behandler man den som portabel, får man råd, der ikke gælder.

Led efter den klientkomponent, der ejer begrænsningen, i stedet for at tilføje flere regler. Ejeren er det, der faktisk kan fjerne den.

Et filter er ikke en resolver

Blokering af trafik uden for tunnelen installerer ikke en fungerende resolver indeni den. Indstillingen fjerner en vej og overlader tunnelens DNS-konfiguration til den, der opsatte profilen. En profil, der aldrig sendte en resolver, har nu slet ingen.

Gå gennem tre kontroller i rækkefølge. Først, hvilken resolver det fejlende program faktisk bruger. Dernæst, om klienten har anvendt VPN-DNS-indstillingerne. Til sidst, hvilken grænseflade der bærer trafik til den resolver.

1. Resolver i brug: sammenlign Resolve-DnsName -Server <resolver-ip> <name> med de DNS-servere, som ipconfig /all viser.
2. VPN-DNS anvendt: undersøg tunneladapterens DNS-poster i samme output fra ipconfig /all.
3. Grænseflade brugt: Find-NetRoute -RemoteIPAddress <resolver-ip> angiver den udgående grænseflade for den destination.

En LAN-resolver bliver utilgængelig efter design under denne politik, selv mens andre LAN-trafik virker. Det er indstillingen, der gør sit arbejde. Hvis designet har brug for VPN-DNS, skal resolverregistreringen og tunnelens vej rettes; hvis der kræves split DNS med lokale undtagelser, skal konfigurationens ejer udtrykke disse undtagelser på en understøttet måde.

Hvad indstillingen ikke dækker

Port 53 er ikke hele navneopløsningen. DNS over HTTPS og DNS over TLS bruger andre transportveje, og nogle programmer kører deres egen resolverlogik uanset systemindstillinger. En browser kan derfor opløse navne, mens kommandolinjen ikke kan.

Behandl den forskel som diagnostik og ikke som en modsigelse. Sammenlign de to, før du beslutter, at systemets resolver er i stykker.

Hold konklusionen smal, når du skriver den ned. Denne indstilling begrænser én transport på én platform, og resten af opløsningsvejen er et separat designspørgsmål med sin egen ejer.

Tjek tilstanden før og efter afbrydelse

Kør samme opslag under forbindelsen og igen, efter at den ejende klient afbryder. Det første bør fejle for en ekstern resolver, mens tunnelen er oppe, og det andet bør lykkes, når filteret er fjernet. Hvis det stadig fejler efter afbrydelsen, blev filteret ikke ryddet op.

ipconfig /displaydns
nslookup <name> <resolver-ip>

Genstart af klienttjenesten eller maskinen rydder normalt et gammelt filter. Det bekræfter diagnosen uden at bevise en permanent løsning. Skriv ned, hvad du så, for et filter, der overlever en afbrydelse, gør det igen, og notatet er det, der begrunder en fejlrapport.

Først efter de kontroller giver det mening at udskifte resolveren eller genopbygge firewallpolitikken. Begge er større ændringer, end beviserne understøtter.