Kodėl Windows sistemoje po OpenVPN prisijungimo DNS nustoja veikti

53 prievadas niekur neveda, o sprendėjas vis dar atsako į ping. Patikrinkite, ar filtruoja block-outside-dns, tada pateikite sprendėją, kurį tunelis pasieks.

Ping į biuro sprendėją vis dar sulaukia atsakymo po to, kai "OpenVPN" prisijungia, ir vis tiek kiekviena vardo paieška nepavyksta. Adresas pasiekiamas, o prievadas ne, derinys, kuris įgauna prasmę supratus, kad Windows gali filtruoti DNS pagal adapterį. Jei profilyje yra block-outside-dns, tas filtras yra pirmasis įtariamasis, o maršrutų lentelė yra netinkama vieta ieškoti. Du testai žemiau atskiria sluoksnius per kelias sekundes.

Pasiekiamas adresas, miręs prievadas

Sėkmingas ping įrodo, kad pagrindinė mašina veikia ir kad kelias egzistuoja. Apie leidimą pasiekti 53 prievadą jis nieko nesako, nes minėtas filtras dirba kitame sluoksnyje ir priklauso nuo adapterio. Todėl ta pati mašina gali atsakyti į ICMP ir atmesti kiekvieną užklausą, siunčiamą tuo pačiu adresu. Paleiskite abu testus toje pačioje sesijoje prieš keisdami bet kokią konfigūraciją.

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

Ta pora yra diagnozė. Įprastas srautas į potinklį veikia toliau, o vardų skiriamoji geba miršta, ir žmonės daro išvadą, kad serveris sugedęs arba kad DNS niekada nebuvo nusiųstas. Abi paaiškinimus sekti brangu, o įrodymai rodo į siauresnę vietą. Patvirtinkite porą prieš liesdami bet kokį nustatymą.

Ši parinktis yra filtravimo platformos taisyklė

OpenVPN žinynas apibūdina block-outside-dns kaip Windows Filtering Platform apribojimą, kuris neleidžia programoms pasiekti DNS adapteriuose už tunelio ribų. Jis apima TCP ir UDP 53 prievadą. Kadangi filtras gyvena WFP, o ne įprastame ugniasienės taisyklių sąraše, leidimo taisyklės pridėjimas kitur nebūtinai pakeičia rezultatą. Todėl įprastas patarimas leisti DNS vis dar nepavyksta.

Nustatymas gali ateiti iš importuoto profilio arba iš serverio, o failas, kurį paskutinį kartą redagavote, "nėra įrodymas, ką įkėlė klientas". Skaitykite veikiančią konfigūraciją ir ryšio žurnalą kartu. Parinktis taip pat būdinga Windows, o traktuojant ją kaip perkeliamą gaunami patarimai, kurie netaikomi.

Ieškokite kliento komponento, kuriam priklauso apribojimas, o ne pridėkite daugiau taisyklių. Savininkas yra tai, kas iš tiesų gali jį pašalinti.

Filtras nėra sprendėjas

Srauto už tunelio ribų blokavimas neįdiegia jame veikiančio sprendėjo. Parinktis pašalina kelią ir palieka tunelio DNS konfigūraciją tam, kas nustatė profilį. Profilis, kuris niekada nesiuntė sprendėjo, dabar jo neturi visai.

Atlikite tris patikras iš eilės. Pirma, kurį sprendėją iš tikrųjų naudoja nepavykstanti programa. Antra, ar klientas pritaikė VPN DNS nustatymus. Trečia, kuri sąsaja neša srautą į tą sprendėją.

  1. Naudojamas sprendėjas: palyginkite Resolve-DnsName -Server <resolver-ip> <name> su DNS serveriais, kuriuos išvardija ipconfig /all.
  2. VPN DNS pritaikytas: peržiūrėkite tunelio adapterio DNS įrašus tame pačiame ipconfig /all išvestyje.
  3. Naudojama sąsaja: Find-NetRoute -RemoteIPAddress <resolver-ip> nurodo išeinančią sąsają tam tikslui.

LAN sprendėjas pagal projektą tampa nepasiekiamas pagal šią politiką, net kai kitas LAN srautas veikia. Tai parinktis, kuri dirba savo darbą. Jei projektui reikia VPN DNS, pataisykite sprendėjo registraciją ir tunelio kelią; jei reikia split DNS su vietinėmis išimtimis, konfigūracijos savininkas turi tas išimtis išreikšti palaikomu būdu.

Ko parinktis neapima

53 prievadas nėra visa vardų skiriamoji geba. DNS over HTTPS ir DNS over TLS naudoja skirtingą transportą, o kai kurios programos vykdo savo sprendėjo logiką nepriklausomai nuo sistemos nustatymų. Todėl naršyklė gali išspręsti vardus, o komandinė eilutė negali.

Traktuokite šį skirtumą kaip diagnostiką, o ne kaip prieštaravimą. Palyginkite abu prieš nuspręsdami, kad sistemos sprendėjas sugedęs.

Rašydami laikykite išvadą siaurą. Ši parinktis apriboja vieną transportą vienoje platformoje, o likusi sprendimo kelio dalis yra atskiras projektavimo klausimas su savo savininku.

Patikrinkite būseną prieš atjungimą ir po jo

Paleiskite tą pačią paiešką ryšio metu ir dar kartą po to, kai savininkas klientas atsijungia. Pirmoji turėtų nepavykti išoriniam sprendėjui, kol tunelis pakeltas, o antroji turėtų pavykti pašalinus filtrą. Jei po atjungimo vis dar nepavyksta, filtras nebuvo išvalytas.

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

Kliento tarnybos ar mašinos paleidimas iš naujo paprastai išvalo pasenusį filtrą. Tai patvirtina diagnozę neįrodydamas nuolatinio pataisymo. Užsirašykite, ką matėte, nes atjungimą išgyvenęs filtras tai padarys vėl, o įrašas yra tai, kas pateisina klaidos ataskaitą.

Tik po šių patikrų prasminga pakeisti sprendėją arba perstatyti ugniasienės politiką. Abu yra didesni pakeitimai, nei įrodymai palaiko.

Susiję straipsniai