Waarom DNS ophou werk nadat OpenVPN op Windows verbind

’n Ping na die kantooroplosser antwoord nog steeds nadat "OpenVPN" verbind het, en tog misluk elke naamsoektog. Die adres is bereikbaar terwyl die poort dit nie is nie, ’n kombinasie wat sin maak sodra jy weet dat Windows DNS per adapter kan filter. Met block-outside-dns in die profiel is daardie filter die eerste verdagte, en die roetetabel is die verkeerde plek om te kyk. Die twee toetse hieronder skei die lae binne sekondes.

Bereikbare adres, dooie poort

’n Suksesvolle ping bewys dat die gasheer op is en dat daar ’n pad bestaan. Dit sê niks oor toestemming om poort 53 te bereik nie, want die betrokke filter werk op ’n ander laag en koppel aan die adapter. Daarom kan dieselfde masjien ICMP beantwoord en elke navraag na dieselfde adres weier. Hardloop albei toetse in dieselfde sessie voordat jy enige konfigurasie verander.

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

Die paar is die diagnose. Gewone verkeer na die subnet werk aan terwyl naamresolusie sterf, en mense kom tot die gevolgtrekking dat die bediener stukkend is of dat DNS nooit gestuur is nie. Albei verklarings is duur om na te jaag, en die bewyse wys na iets smaller. Bevestig die paar voordat jy aan enige instelling raak.

Die opsie is ’n reël van die filteringsplatform

Die OpenVPN-verwysing beskryf block-outside-dns as ’n Windows Filtering Platform-beperking wat verhoed dat toepassings DNS bereik op adapters buite die tonnel. Dit dek TCP en UDP poort 53. Omdat die filter in WFP sit eerder as in die gewone vuurmuurreëllys, verander die byvoeging van ’n toelaatreël elders nie noodwendig die uitkoms nie. Daarom bly die algemene raad om DNS toe te laat misluk.

Die instelling kan van die ingevoerde profiel of van die bediener af kom, en die lêer wat jy laas geredigeer het, is "nie bewys van wat die kliënt gelaai het nie". Lees die effektiewe konfigurasie en die verbindingslog saam. Die opsie is ook Windows-spesifiek, en om dit as oordraagbaar te behandel lewer raad op wat nie van toepassing is nie.

Soek die kliëntkomponent wat die beperking besit in plaas daarvan om meer reëls by te voeg. Die eienaar is die ding wat dit werklik kan verwyder.

’n Filter is nie ’n oplosser nie

Om verkeer buite die tonnel te blokkeer, installeer nie ’n werkende oplosser binne-in dit nie. Die opsie verwyder ’n pad en laat die tonnel se DNS-konfigurasie oor aan wie ook al die profiel opgestel het. ’n Profiel wat nooit ’n oplosser gestuur het nie, het nou heeltemal geen een nie.

Werk in volgorde deur drie kontroles. Eerstens: watter oplosser die mislukte toepassing werklik gebruik. Tweedens: of die kliënt die VPN-DNS-instellings toegepas het. Derdens: watter koppelvlak verkeer na daardie oplosser dra.

1. Oplosser in gebruik: vergelyk Resolve-DnsName -Server <resolver-ip> <name> met die DNS-bedieners wat ipconfig /all lys.
2. VPN-DNS toegepas: ondersoek die tonneladapter se DNS-inskrywings in dieselfde uitset van ipconfig /all.
3. Koppelvlak gebruik: Find-NetRoute -RemoteIPAddress <resolver-ip> noem die uitgaande koppelvlak vir daardie bestemming.

’n LAN-oplosser word per ontwerp onbereikbaar onder hierdie beleid, selfs terwyl ander LAN-verkeer werk. Dit is die opsie wat sy werk doen. As die ontwerp VPN-DNS nodig het, maak die oplosserregistrasie en die tonnelpad reg; as split-DNS met plaaslike uitsonderings vereis word, moet die eienaar van die konfigurasie daardie uitsonderings op ’n ondersteunde manier uitdruk.

Wat die opsie nie dek nie

Poort 53 is nie die hele naamresolusie nie. DNS oor HTTPS en DNS oor TLS gebruik ander transport, en sommige toepassings hardloop hul eie oplosserlogika ongeag stelselinstellings. ’n Blaaier kan dus name oplos terwyl die opdragreël dit nie kan nie.

Behandel daardie verskil as ’n diagnose eerder as ’n teenstrydigheid. Vergelyk die twee voordat jy besluit die stelseloplosser is stukkend.

Hou die gevolgtrekking eng wanneer jy dit neerskryf. Hierdie opsie beperk een transport op een platform, en die res van die resolusiepad is ’n aparte ontwerpvraag met sy eie eienaar.

Kontroleer die toestand voor en na ontkoppeling

Hardloop dieselfde soektog tydens die verbinding en weer nadat die eienareskliënt ontkoppel. Die eerste behoort te misluk vir ’n buiteoplosser terwyl die tonnel op is, en die tweede behoort te slaag sodra die filter verwyder is. As dit steeds misluk ná ontkoppeling, is die filter nie opgeruim nie.

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

Om die kliëntdiens of die masjien te herbegin, verwyder gewoonlik ’n verouderde filter. Dit bevestig die diagnose sonder om ’n permanente oplossing te bewys. Teken op wat jy gesien het, want ’n filter wat ’n ontkoppeling oorleef, sal dit weer doen, en die rekord is wat ’n foutverslag regverdig.

Eers ná daardie kontroles maak dit sin om die oplosser te vervang of die vuurmuurbeleid te herbou. Albei is groter veranderinge as wat die bewyse ondersteun.