DNS-ul împins de OpenVPN este ignorat: ce componentă îl aplică

Jurnalul arată opțiunea împinsă de server, tunelul este activ, iar numele interne tot eșuează. O interogare directă la resolver răspunde, deci serverul este în regulă, însă fiecare aplicație continuă să întrebe routerul local. Ce a ajuns la client este o ofertă, nu o modificare în resolver, iar componenta care deține rezolvarea numelor diferă pe Linux, Windows și macOS. Odată ce separați opțiunea de proprietarul ei, patru defecte acoperă aproape fiecare raport: niciun hook, două hook-uri concurente, DNS divizat funcționând conform proiectării, sau un nume scurt care are nevoie de un sufix, nu de un server.

O opțiune împinsă este o ofertă, nu o instalare

Pe server, două directive descriu intenția, nu efectul:

push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DOMAIN corp.example"

Clientul nu primește un resolver configurat. Primește variabile de mediu, foreign_option_1 și următoarele, una pentru fiecare linie împinsă, iar ceva local trebuie să le citească și să rescrie starea resolverului sistemului de operare. Pe Linux nimic nu face asta implicit, de aceea un server corect și un client conectat pot rezolva în continuare nume prin LAN.

Între cele două capete stau trei etape: împingerea trebuie să ajungă, clientul trebuie să o expună, iar un hook trebuie să o aplice. Citiți etapa din mijloc în jurnalul clientului și pe ultima în starea resolverului, niciodată invers, fiindcă o linie de jurnal dovedește doar primele două.

Confirmați că împingerea a ajuns și găsiți proprietarul

Începeți prin a numi lansatorul: o comandă openvpn goală, o instanță systemd, NetworkManager sau un client al furnizorului. Asta decide unde poate locui un hook. Pe un host cu systemd-resolved, resolvectl status listează fiecare legătură cu serverele DNS și domeniile de căutare pe care le folosește efectiv, iar legătura tunelului nu se numește mereu tun0.

Dacă adresa împinsă apare în jurnal dar pe nicio legătură, integrarea lipsește. Dacă apare pe legătură și interogările tot pleacă altundeva, problema este care interogări selectează acea legătură. NetworkManager dns=dnsmasq în fișierul /etc/NetworkManager/NetworkManager.conf rulează un redirecționator local care aplică DNS divizat intenționat: numele din domeniul VPN merg la resolverul VPN, iar restul își păstrează calea anterioară. Acest comportament pare un defect când vă așteptați ca tot traficul să se mute; verificați setările pe conexiune cu nmcli connection show "My VPN", unde ipv4.dns și ipv4.dns-search păstrează valorile din spatele a ceea ce raportează dispozitivul, înainte să-l numiți stricat. Dacă fiecare interogare trebuie într-adevăr să ajungă la resolverul VPN, eliminați dns=dnsmasq din NetworkManager.conf și reporniți NetworkManager, ceea ce readuce rezolvarea la setările conexiunii; altfel păstrați DNS-ul divizat și corectați lista de domenii împinsă.

Linux: predați opțiunile resolverului

Pachetele distribuțiilor livreză un hook pentru asta, iar clientului trebuie să i se permită să îl execute. O amenajare tipică pe un host fără systemd-resolved:

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

Cu systemd-resolved, scriptul mai vechi resolv.conf poate să nu schimbe nimic important, fiindcă resolverul stub ține starea pe fiecare legătură. update-systemd-resolved ajutorul documentează o formă de hook care folosește up-restart și down-pre, ceea ce contează când o interfață supraviețuiește unei singure încercări de conectare. Orice ați alege, o singură componentă trebuie să dețină starea. Adăugarea unui hook străin lângă NetworkManager dă doi scriitori aceleiași legături, iar rezultatul depinde atunci de ordine, nu de configurația dumneavoastră.

Există și cazul în care NetworkManager a ignorat complet opțiunea împinsă până când adresa serverului a fost introdusă în setările IPv4 ale conexiunii, după care starea resolverului a arătat că este folosită. Merită încercat înainte de a rescrie scripturi, fiindcă mută problema dintr-un hook de shell în profilul conexiunii care duce deja tunelul.

Windows și macOS aplică părți diferite

Clientul Windows setează într-adevăr serverele DNS ale adaptorului VPN, dar Windows alege în continuare interfața după metrică și are în continuare nevoie de un sufix pentru a extinde un nume scurt. Confirmați starea adaptorului, nu a profilului:

Get-DnsClientServerAddress -InterfaceAlias "My VPN"
Get-DnsClientNrptPolicy

Dacă adresa lipsește, setați-o cu Set-DnsClientServerAddress -InterfaceAlias "My VPN" -ServerAddresses 10.8.0.1, apoi adăugați sufixul la proprietățile IPv4 ale adaptorului ca fileserver să devină fileserver.corp.example. O valoare SearchList la nivelul întregii mașini sub Tcpip\Parameters face același lucru. Acolo unde numele lung se rezolvă iar cel gol nu, resolverul este deja corect și vina este a listei de căutare. Corecțiile, în ordine: împingeți un DOMAIN ca clientul să învețe sufixul, adăugați acel sufix în lista de căutare a adaptorului sau a conexiunii, și ca măsură temporară fixați numele în hosts, sau LMHOSTS pe Windows; navigarea NetBIOS nu traversează un router, așa că difuzarea care găsește un nume scurt în LAN-ul biroului nu ajunge niciodată la un client de tunel.

block-outside-dns block-outside-dns este un comportament al clientului Windows, nu o linie de profil portabilă, iar copierea într-un profil Linux sau macOS nu îl reproduce acolo. Dacă numele publice funcționează și cele interne eșuează pe Windows, comparați ordinea adaptoarelor din Setări avansate cu ipconfig /all. Pe macOS ordinea resolverelor pe serviciu aparține sistemului, așa că folosiți scutil --dns pentru a vedea ce resolver este întrebat pentru ce domeniu, și tratați orice corecție de profil raportată ca dependentă de client și nu generală.

O mașină virtuală pe același laptop nu moștenește nimic din asta. Dați invitatului propria intrare de resolver pentru domeniul intern, sau lăsați NAT-ul hipervizorului să redirecționeze interogările prin host, ceea ce este corect doar cât timp tunelul hostului este activ.

Istoricul este a treia cauză. Serverele DNS sau setările de sufix dintr-un profil anterior pot supraviețui reconectărilor, așa că atunci când adaptorul pare corect și căutările tot eșuează, comparați adaptorul activ cu Get-VpnConnection și ștergeți sau suprascrieți intrarea învechită înainte de a atinge serverul.

Dovediți unde a mers interogarea

O captură în timpul unei căutări tranșează discuția: tcpdump -ni eth0 port 53 arată interogări pe interfața fizică, ceea ce înseamnă că ies în afara tunelului și că resolverul nu a fost niciodată schimbat. dig @10.8.0.1 name.corp.example apoi separă cele două cazuri rămase. Dacă interogarea directă răspunde, resolverul funcționează și clientul nu îl folosește; dacă expiră, resolverul este inaccesibil prin tunel și nicio schimbare locală nu va ajuta.

Dacă resolverul încă folosit este cel dat de furnizor, tunelul criptează traficul, dar numele rămân vizibile acelui furnizor. Este o chestiune de scurgere, nu de funcționare, iar aceeași captură răspunde: o interogare pe interfața fizică merge către cineva din afara tunelului.

Accesibilitatea include firewallul de pe hostul VPN, care trebuie să permită UDP și TCP 53 din pool. Un port blocat arată exact ca o împingere stricată, la fel și un resolver care răspunde doar din interiorul rețelei tunelului. Repetați captura după o deconectare și reconectare, fiindcă setările care apar la prima conectare și dispar la a doua sunt un defect al ciclului de viață în hook, nu o opțiune lipsă.

Păstrați un singur proprietar și verificați în ordine

Un script care rescrie DNS-ul adaptorului pe baza unei stări presupuse a tunelului duplică o configurație pe care profilul o duce deja și eșuează în tăcere prima dată când presupunerea este greșită. Preferați setările DNS ale conexiunii sau un singur hook documentat și notați pe care l-ați ales, ca următoarea persoană să nu adauge un al doilea.

Închideți bucla cu patru verificări: adresa împinsă prezentă pe legătura tunelului, numele intern rezolvat ca nume complet calificat, același nume rezolvat fără sufix, și ambele încă adevărate după o reconectare. O captură vă spune care dintre cele patru a eșuat. Manualul OpenVPN 2.6 enumeră dhcp-option și directivele de script cu notele lor de platformă.