Hvorfor DNS slutter å virke etter at OpenVPN kobler til på Windows

En ping til kontorets resolver får fortsatt svar etter at "OpenVPN" har koblet til, og likevel feiler hvert navneoppslag. Adressen er nåbar mens porten ikke er det, en kombinasjon som gir mening når man vet at Windows kan filtrere DNS per adapter. Med block-outside-dns i profilen er det filteret den første mistenkte, og rutetabellen er feil sted å lete. De to testene nedenfor skiller lagene på sekunder.

Nåbar adresse, død port

En vellykket ping beviser at verten kjører og at det finnes en vei. Den sier ingenting om tillatelse til å nå port 53, fordi filteret det gjelder arbeider på et annet lag og er knyttet til adapteren. Derfor kan samme maskin svare på ICMP og avvise hver forespørsel som sendes til samme adresse. Kjør begge testene i samme økt før du endrer noen konfigurasjon.

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

Paret er diagnosen. Vanlig trafikk til subnettet fortsetter mens navneoppløsningen dør, og folk konkluderer med at serveren er ødelagt eller at DNS aldri ble sendt. Begge forklaringene er dyre å forfølge, og bevisene peker mot noe smalere. Bekreft paret før du rører en innstilling.

Valget er en regel i filtreringsplattformen

OpenVPN-referansen beskriver block-outside-dns som en begrensning i Windows Filtering Platform som hindrer programmer i å nå DNS på adaptere utenfor tunnelen. Den dekker TCP og UDP port 53. Fordi filteret bor i WFP og ikke i den vanlige regelisten i brannmuren, endrer en tillatelsesregel andre steder ikke nødvendigvis resultatet. Derfor fortsetter det vanlige rådet om å tillate DNS å feile.

Innstillingen kan komme fra den importerte profilen eller fra serveren, og filen du sist redigerte, "er ikke bevis for hva klienten lastet". Les den effektive konfigurasjonen og tilkoblingsloggen sammen. Valget er også Windows-spesifikt, og å behandle det som flyttbart gir råd som ikke gjelder.

Se etter klientkomponenten som eier begrensningen, i stedet for å legge til flere regler. Eieren er det som faktisk kan fjerne den.

Et filter er ikke en resolver

Blokkering av trafikk utenfor tunnelen installerer ikke en fungerende resolver inni den. Valget fjerner en vei og overlater tunnelens DNS-konfigurasjon til den som satte opp profilen. En profil som aldri sendte en resolver, har nå ingen i det hele tatt.

Gå gjennom tre kontroller i rekkefølge. Først, hvilken resolver programmet som feiler faktisk bruker. Deretter, om klienten har brukt VPN-DNS-innstillingene. Til slutt, hvilket grensesnitt som bærer trafikken til den resolveren.

1. Resolver i bruk: sammenlign Resolve-DnsName -Server <resolver-ip> <name> med DNS-serverne som ipconfig /all lister opp.
2. VPN-DNS brukt: undersøk tunneladapterens DNS-oppføringer i samme utdata fra ipconfig /all.
3. Grensesnitt brukt: Find-NetRoute -RemoteIPAddress <resolver-ip> navngir det utgående grensesnittet for den destinasjonen.

En LAN-resolver blir unåbar av design under denne policyen, selv mens annen LAN-trafikk virker. Det er valget som gjør jobben sin. Hvis designet trenger VPN-DNS, rett opp resolverregistreringen og tunnelbanen; hvis splittet DNS med lokale unntak er påkrevd, må konfigurasjonens eier uttrykke disse unntakene på en støttet måte.

Hva valget ikke dekker

Port 53 er ikke hele navneoppløsningen. DNS over HTTPS og DNS over TLS bruker andre transportveier, og noen programmer kjører sin egen resolverlogikk uavhengig av systeminnstillinger. En nettleser kan derfor løse navn mens kommandolinjen ikke kan.

Behandle den forskjellen som diagnostikk og ikke som en motsigelse. Sammenlign de to før du avgjør at systemets resolver er ødelagt.

Hold konklusjonen smal når du skriver den. Dette valget begrenser én transport på én plattform, og resten av oppløsningsveien er et eget designspørsmål med sin egen eier.

Sjekk tilstanden før og etter frakobling

Kjør samme oppslag under tilkoblingen og igjen etter at den eide klienten kobler fra. Det første bør feile for en ekstern resolver mens tunnelen er oppe, og det andre bør lykkes når filteret er fjernet. Hvis det fortsatt feiler etter frakobling, ble filteret ikke ryddet.

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

Å starte klienttjenesten eller maskinen på nytt rydder vanligvis et gammelt filter. Det bekrefter diagnosen uten å bevise en varig løsning. Skriv ned det du så, for et filter som overlever en frakobling gjør det igjen, og notatet er det som begrunner en feilrapport.

Først etter disse kontrollene er det fornuftig å bytte resolver eller bygge brannmurpolicyen på nytt. Begge er større endringer enn bevisene støtter.