Kvifor DNS sluttar å verke etter at OpenVPN koplar til på Windows

Ein ping til resolvaren på kontoret får framleis svar etter at "OpenVPN" har kopla til, og likevel feilar kvart namneoppslag. Adressa er nåbar medan porten ikkje er det, ein kombinasjon som gjev meining når ein veit at Windows kan filtrere DNS per adapter. Med block-outside-dns i profilen er det filteret den første mistenkte, og rutetabellen er feil stad å leite. Dei to testane nedanfor skil laga på sekund.

Nåbar adresse, daud port

Ein vellukka ping beviser at verten køyrer og at det finst ein veg. Han seier ingenting om løyve til å nå port 53, fordi filteret det gjeld arbeider på eit anna lag og er knytt til adapteren. Difor kan same maskin svare på ICMP og avvise kvar førespurnad som blir send til same adresse. Køyr båe testane i same økt før du endrar noka konfigurasjon.

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

Paret er diagnosen. Vanleg trafikk til subnettet held fram medan namneoppløysinga døyr, og folk konkluderer med at tenaren er øydelagd eller at DNS aldri vart send. Båe forklaringane er dyre å forfølgje, og prova peikar mot noko smalare. Stadfest paret før du rører ei innstilling.

Valet er ein regel i filtreringsplattforma

OpenVPN-referansen skildrar block-outside-dns som ei avgrensing i Windows Filtering Platform som hindrar program i å nå DNS på adapterar utanfor tunnelen. Ho dekkjer TCP og UDP port 53. Fordi filteret bur i WFP og ikkje i den vanlege regellista i brannmuren, endrar ein løyvesregel andre stader ikkje nødvendigvis resultatet. Difor held det vanlege rådet om å tillate DNS fram med å feile.

Innstillinga kan kome frå den importerte profilen eller frå tenaren, og fila du sist redigerte, "er ikkje prov for kva klienten lasta". Les den effektive konfigurasjonen og tilkoplingsloggen saman. Valet er òg Windows-spesifikt, og å handsame det som flyttbart gjev råd som ikkje gjeld.

Sjå etter klientkomponenten som eig avgrensinga, i staden for å leggje til fleire reglar. Eigaren er det som faktisk kan fjerne henne.

Eit filter er ikkje ein resolvar

Blokkering av trafikk utanfor tunnelen installerar ikkje ein verkarande resolvar inni han. Valet fjernar ein veg og overlèt DNS-konfigurasjonen til tunnelen til den som sette opp profilen. Ein profil som aldri sende ein resolvar, har no ingen i det heile.

Gå gjennom tre kontrollar i rekkjefølgje. Fyrst, kva resolvar programmet som feilar faktisk brukar. Deretter, om klienten har brukt VPN-DNS-innstillingane. Til slutt, kva grensesnitt som ber trafikken til den resolvaren.

1. Resolvar i bruk: samanlikn Resolve-DnsName -Server <resolver-ip> <name> med DNS-tenarane som ipconfig /all listar opp.
2. VPN-DNS brukt: gransk DNS-oppføringane til tunneladapteren i same utdata frå ipconfig /all.
3. Grensesnitt brukt: Find-NetRoute -RemoteIPAddress <resolver-ip> namngjev det utgåande grensesnittet for den destinasjonen.

Ein LAN-resolvar blir unåbar av design under denne policyen, sjølv medan annan LAN-trafikk verkar. Det er valet som gjer jobben sin. Viss designet treng VPN-DNS, rett opp resolvarregistreringa og tunnelbanen; viss splitta DNS med lokale unntak er påkravd, må eigaren av konfigurasjonen uttrykkje desse unntaka på ein støtta måte.

Kva valet ikkje dekkjer

Port 53 er ikkje heile namneoppløysinga. DNS over HTTPS og DNS over TLS brukar andre transportvegar, og nokre program køyrer sin eigen resolvarlogikk uavhengig av systeminnstillingar. Ein nettlesar kan difor løyse namn medan kommandolinja ikkje kan.

Handsam den skilnaden som diagnostikk og ikkje som ei motseiing. Samanlikn dei to før du avgjer at resolvaren til systemet er øydelagd.

Hald konklusjonen smal når du skriv han. Dette valet avgrensar éin transport på éi plattform, og resten av oppløysingsvegen er eit eige designspørsmål med sin eigen eigar.

Sjekk tilstanden før og etter fråkopling

Køyr same oppslag under tilkoplinga og igjen etter at den eigde klienten koplar frå. Det fyrste bør feile for ein ekstern resolvar medan tunnelen er oppe, og det andre bør lukkast når filteret er fjerna. Viss det framleis feilar etter fråkopling, vart filteret ikkje rydda.

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

Å starte klienttenesta eller maskinen på nytt ryddar vanlegvis eit gammalt filter. Det stadfester diagnosen utan å prove ei varig løysing. Skriv ned det du såg, for eit filter som overlever ei fråkopling gjer det igjen, og notatet er det som grunngjev ein feilrapport.

Fyrst etter desse kontrollane er det fornuftig å bytte resolvar eller byggje brannmurpolicyen på nytt. Båe er større endringar enn prova støttar.