openfortivpn suprascrie mereu DNS? Găsiți adevăratul proprietar

Urmați conexiunea din momentul în care se ridică: clientul se autentifică, pppd negociază, iar apoi ceva scrie setările DNS în sistemul de operare. Dacă știți doar că VPN-ul v-a schimbat resolverul, încă nu știți care dintre acele etape a făcut-o. Două dintre ele pot, iar pe un client care folosește integrarea pppd documentată rulează suficient de aproape unul de altul încât să pară un singur actor. Numirea scriitorului este primul pas; alegerea înlocuitorului său este al doilea, iar aceasta este o decizie separată cu propriile moduri de eșec.

Secvența de mai jos urmărește clientul spre exterior: ce a schimbat conexiunea, care comutator reduce la tăcere care scriitor, cine ar trebui să preia și cum confirmați că rezultatul supraviețuiește unei reconectări. Fiecare etapă lasă o urmă diferită, iar urma este cea care vă spune dacă predarea a avut loc cu adevărat.

Începeți cu ce a schimbat de fapt conexiunea

Conectați-vă o dată cu comanda obișnuită și comparați rezolvarea înainte și după. Pe un host Linux cu systemd-resolved, resolvectl status afișează serverele DNS și domeniile de căutare pentru fiecare legătură, iar o legătură tun sau ppp nouă care își poartă propriile servere este amprenta unei actualizări din partea clientului. Pe macOS, scutil --dns arată configurația resolverului în ordinea în care aplicațiile o consultă.

Comparați asta cu fișierul despre care vă așteptați să se schimbe. O intrare legată de conexiune în vizualizarea pe legături și un /etc/resolv.conf rescris sunt două rezultate diferite, iar al doilea poate fi o legătură simbolică gestionată în întregime de altceva. Notați adresa resolverului, domeniile de căutare și numele interfeței în același moment; o schimbare în oricare dintre ele indică un alt scriitor. Fără acea linie de bază, fiecare corectare ulterioară este o presupunere despre care dintre trei componente s-a mișcat.

Cele două comutatoare și scriitorul pe care fiecare îl reduce la tăcere

openfortivpn documentează un fragment de opțiuni care oprește ambii scriitori pe care îi poate controla, iar fiecare comutator are un echivalent scris complet pe care manualul îl tratează ca aceeași setare.

openfortivpn gw.example.com:443 --no-dns --pppd-no-peerdns
# written out in long form
openfortivpn gw.example.com:443 --set-dns=0 --pppd-use-peerdns=0

--no-dns împiedică clientul să aplice serverele DNS pe care le-a învățat de la poartă, în timp ce --pppd-no-peerdns împiedică pppd să împingă DNS-ul partenerului în sistem. Manualul upstream avertizează că actualizările DNS prin PPP pot concura cu actualizările DNS ale clientului însuși, motiv pentru care ambele comutatoare aparțin fragmentului în loc ca vreunul să fie considerat suficient.

Niciun comutator nu numește un resolver de rezervă, și niciunul nu împiedică un manager de rețea, un client DHCP sau o integrare VPN separată să scrie rezolvarea după aceea. Reducerea la tăcere a doi scriitori lasă câmpul deschis, nu deținut. Dacă o a treia componentă gestionează deja DNS-ul, fragmentul nu schimbă nimic ce puteți observa; dacă nimic nu îl gestionează, tocmai ați eliminat singura sursă de rezolvare a numelor private. Aceasta este o aranjare validă doar când proprietarul înlocuitor a fost ales mai întâi și testat separat.

Alegeți proprietarul înainte de a dezactiva ceva

Decideți mai întâi cine răspunde la interogările pentru numele de lucru, pentru că acea alegere condiționează tot ce urmează. Păstrarea resolverului existent înseamnă că zona privată trebuie să fie deja accesibilă de oriunde se află clientul, iar un resolver privat din birou are nevoie de o rută care supraviețuiește ridicării tunelului. Trimiterea fiecărei interogări către un singur serviciu intern este o a treia politică cu un mod de eșec mai ascuțit: când acel serviciu este inaccesibil, numele publice eșuează împreună cu cele private.

Proprietatea rutelor rămâne separată intenționat. Opțiunile de rută nu sunt necesare pentru că ați schimbat DNS-ul, iar dezactivarea instalării rutelor fără instalarea unui înlocuitor poate face inaccesibil resolverul pe care tocmai l-ați ales. Verificați tabela de rutare specific pentru adresa resolverului, nu doar pentru subrețeaua aplicației pe care ați testat-o din întâmplare.

Verificați rezolvarea pe legătură, nu pe fișier

Un singur /etc/resolv.conf nu este un inventar al ceea ce folosesc de fapt aplicațiile pe un host cu rezolvare limitată sau pe domeniu, așa că citiți starea resolverului așa cum o expune platforma.

resolvectl status
resolvectl query vpn.internal.example.com
resolvectl query example.com
ip route get 10.20.0.53

Întrebați un nume privat și un nume public după ce conexiunea s-a ridicat, și notați care legătură a răspuns la fiecare. Acolo unde legătura VPN poartă o listă de căutare pe domeniu, un nume privat se poate rezolva corect în timp ce un nume public merge încă la resolverul local, iar această separare este proiectarea care funcționează, nu o defecțiune. Dacă interogarea privată eșuează, inspectați ruta către resolver înainte de a atinge din nou DNS-ul; dacă reușește în timp ce o aplicație încă eșuează, aplicația poate citi un resolver propriu, pus în cache sau configurat separat.

Reconectați-vă și confirmați starea deconectată

Coborâți conexiunea și repetați ambele interogări. Ce a instalat proprietarul ales trebuie să fie eliminat sau restaurat de acel proprietar, nu lăsat în urmă de clientul pe care l-ați redus la tăcere. O intrare pe legătură învechită care supraviețuiește tunelului continuă să trimită interogări private către o adresă care nu mai este accesibilă.

Apoi reconectați-vă și citiți din nou aceleași trei valori: adresa resolverului, domeniile de căutare, interfața.

Dacă se potrivesc cu politica pe care ați notat-o, predarea este completă și clientul VPN nu mai este unul dintre scriitori. Dacă o valoare revine câteva secunde după ridicarea legăturii, altceva încă aplică configurație, iar pasul următor este să identificați acea componentă în loc să adăugați încă un indicator. Starea finală pe care o doriți este fără evenimente: un proprietar, o politică documentată și un host deconectat care rezolvă exact cum o făcea înainte de a exista tunelul.