De ce DNS-ul nu mai funcționează după conectarea OpenVPN pe Windows

Portul 53 nu duce nicăieri, dar resolverul răspunde în continuare la ping. Verificați dacă block-outside-dns filtrează, apoi furnizați un resolver la care tunelul poate ajunge.

Un ping către resolverul biroului primește în continuare răspuns după ce "OpenVPN" se conectează, și totuși fiecare căutare de nume eșuează. Adresa este accesibilă, iar portul nu, o combinație care are sens când știți că Windows poate filtra DNS după adaptor. Cu block-outside-dns în profil, acel filtru este primul suspect, iar tabela de rutare este locul greșit unde să căutați. Cele două teste de mai jos separă straturile în câteva secunde.

Adresă accesibilă, port mort

Un ping reușit dovedește că gazda rulează și că există o cale. Nu spune nimic despre permisiunea de a ajunge la portul 53, pentru că filtrul în cauză lucrează la alt strat și depinde de adaptor. De aceea aceeași mașină poate răspunde la ICMP și poate refuza fiecare interogare trimisă la aceeași adresă. Rulați ambele teste în aceeași sesiune înainte de a schimba orice configurație.

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

Perechea este diagnosticul. Traficul obișnuit către subrețea continuă să funcționeze în timp ce rezolvarea numelor moare, iar oamenii concluzionează că serverul este defect sau că DNS-ul nu a fost trimis niciodată. Ambele explicații sunt scumpe de urmărit, iar dovezile indică un loc mai îngust. Confirmați perechea înainte de a atinge o setare.

Opțiunea este o regulă a platformei de filtrare

Documentația OpenVPN descrie block-outside-dns ca o restricție a Windows Filtering Platform care împiedică aplicațiile să ajungă la DNS pe adaptoare din afara tunelului. Acoperă TCP și UDP pe portul 53. Deoarece filtrul trăiește în WFP, nu în lista obișnuită de reguli a paravanului, adăugarea unei reguli de permisiune în altă parte nu schimbă neapărat rezultatul. De aceea sfatul obișnuit de a permite DNS continuă să eșueze.

Setarea poate veni din profilul importat sau de la server, iar fișierul pe care l-ați editat ultima dată "nu este dovada a ceea ce a încărcat clientul". Citiți configurația efectivă și jurnalul conexiunii împreună. Opțiunea este și specifică Windows, iar tratarea ei ca portabilă produce sfaturi care nu se aplică.

Căutați componenta client care deține restricția în loc să adăugați mai multe reguli. Proprietarul este lucrul care o poate elimina cu adevărat.

Un filtru nu este un resolver

Blocarea traficului din afara tunelului nu instalează un resolver funcțional în interiorul lui. Opțiunea elimină o cale și lasă configurația DNS a tunelului în seama celui care a pregătit profilul. Un profil care nu a trimis niciodată un resolver acum nu are niciunul.

Parcurgeți trei verificări în ordine. Întâi, ce resolver folosește de fapt aplicația care eșuează. Apoi, dacă clientul a aplicat setările DNS ale VPN-ului. În final, ce interfață transportă traficul către acel resolver.

  1. Resolver folosit: comparați Resolve-DnsName -Server <resolver-ip> <name> cu serverele DNS pe care le listează ipconfig /all.
  2. DNS al VPN-ului aplicat: examinați intrările DNS ale adaptorului tunelului în aceeași ieșire de la ipconfig /all.
  3. Interfață folosită: Find-NetRoute -RemoteIPAddress <resolver-ip> numește interfața de ieșire pentru acea destinație.

Un resolver LAN devine inaccesibil prin proiectare sub această politică, chiar în timp ce alt trafic LAN funcționează. Este opțiunea care își face treaba. Dacă proiectarea are nevoie de DNS prin VPN, reparați înregistrarea resolverului și calea tunelului; dacă este necesar split DNS cu excepții locale, proprietarul configurației trebuie să exprime acele excepții într-un mod acceptat.

Ce nu acoperă opțiunea

Portul 53 nu este toată rezolvarea numelor. DNS over HTTPS și DNS over TLS folosesc alt transport, iar unele aplicații rulează propria logică de resolver indiferent de setările sistemului. Un browser poate deci să rezolve nume în timp ce linia de comandă nu poate.

Tratați această diferență ca diagnostic și nu ca o contradicție. Comparați cele două înainte de a decide că resolverul sistemului este defect.

Păstrați concluzia îngustă când o scrieți. Această opțiune restricționează un singur transport pe o singură platformă, iar restul căii de rezolvare este o întrebare separată de proiectare, cu propriul proprietar.

Verificați starea înainte și după deconectare

Rulați aceeași căutare în timpul conexiunii și din nou după ce clientul proprietar se deconectează. Prima ar trebui să eșueze pentru un resolver extern cât timp tunelul este ridicat, iar a doua ar trebui să reușească odată ce filtrul este eliminat. Dacă eșuează și după deconectare, filtrul nu a fost curățat.

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

Repornirea serviciului client sau a mașinii curăță de obicei un filtru vechi. Asta confirmă diagnosticul fără a dovedi o corectare permanentă. Notați ce ați văzut, pentru că un filtru care supraviețuiește unei deconectări o va face din nou, iar notița este ceea ce justifică un raport de eroare.

Abia după aceste verificări are sens să înlocuiți resolverul sau să reconstruiți politica paravanului. Ambele sunt schimbări mai mari decât susțin dovezile.

Articole similare