openfortivpn continua a sovrascrivere il DNS? Trova il vero proprietario

Segui la connessione dal momento in cui si alza: il client si autentica, pppd negozia, e poi qualcosa scrive le impostazioni DNS nel sistema operativo. Se sai solo che la VPN ha cambiato il tuo resolver, non sai ancora quale di quelle fasi lo ha fatto. Due di esse possono, e su un client che usa l'integrazione pppd documentata girano abbastanza vicine da sembrare un unico attore. Nominare lo scrittore è il primo passo; sceglierne il sostituto è il secondo, ed è una decisione separata con i propri modi di guasto.

La sequenza sotto segue il client verso l'esterno: cosa ha cambiato la connessione, quale interruttore zittisce quale scrittore, chi dovrebbe subentrare e come confermare che il risultato sopravviva a una riconnessione. Ogni fase lascia una traccia diversa, e la traccia è ciò che ti dice se il passaggio è davvero avvenuto.

Parti da ciò che la connessione ha realmente cambiato

Connettiti una volta con la tua invocazione abituale e confronta la risoluzione prima e dopo. Su un host Linux con systemd-resolved, resolvectl status stampa i server DNS e i domini di ricerca per collegamento, e un nuovo collegamento tun o ppp che porta i propri server è l'impronta di un aggiornamento lato client. Su macOS, scutil --dns mostra la configurazione del resolver nell'ordine in cui le applicazioni la consultano.

Confronta questo con il file che ti aspettavi cambiasse. Una voce legata alla connessione nella vista per collegamento e un /etc/resolv.conf riscritto sono due esiti diversi, e il secondo può essere un collegamento simbolico gestito del tutto da qualcos'altro. Annota l'indirizzo del resolver, i domini di ricerca e il nome dell'interfaccia nello stesso istante; un cambiamento in uno qualsiasi di essi punta a uno scrittore diverso. Senza quella linea di base, ogni correzione successiva è una congettura su quale di tre componenti si sia mosso.

I due interruttori e lo scrittore che ciascuno zittisce

openfortivpn documenta un frammento di opzioni che spegne entrambi gli scrittori che può controllare, e ogni interruttore ha un equivalente scritto per esteso che il manuale tratta come la stessa impostazione.

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 impedisce al client di applicare i server DNS appresi dal gateway, mentre --pppd-no-peerdns impedisce a pppd di spingere il DNS del peer nel sistema. Il manuale di upstream avverte che gli aggiornamenti DNS via PPP possono gareggiare con gli aggiornamenti DNS del client stesso, ed è per questo che entrambi gli interruttori appartengono al frammento invece di considerarne sufficiente uno solo.

Nessun interruttore nomina un resolver sostitutivo, e nessuno impedisce a un gestore di rete, a un client DHCP o a un'integrazione VPN separata di scrivere la risoluzione in seguito. Zittire due scrittori lascia il campo aperto anziché posseduto. Se un terzo componente gestisce già il DNS, il frammento non cambia nulla che tu possa osservare; se nulla lo gestisce, hai appena rimosso l'unica fonte di risoluzione dei nomi privati. È una disposizione valida solo quando il proprietario sostitutivo è stato scelto prima e provato da solo.

Scegli il proprietario prima di disattivare qualsiasi cosa

Decidi prima chi risponde alle query per i nomi di lavoro, perché quella scelta vincola tutto ciò che segue. Mantenere il resolver esistente significa che la zona privata deve già essere raggiungibile da dove si trova il client, e un resolver privato dentro l'ufficio ha bisogno di una rotta che sopravviva all'alzarsi del tunnel. Inviare ogni query a un solo servizio interno è una terza politica con un modo di guasto più affilato: quando quel servizio non è raggiungibile, i nomi pubblici falliscono insieme a quelli privati.

La proprietà delle rotte resta separata di proposito. Le opzioni di rotta non sono necessarie perché hai cambiato il DNS, e disattivare l'installazione delle rotte senza installare un sostituto può rendere irraggiungibile il resolver che hai appena scelto. Controlla la tabella di routing specificamente per l'indirizzo del resolver, non solo per la sottorete dell'applicazione che hai provato per caso.

Verifica la risoluzione per collegamento, non per file

Un solo /etc/resolv.conf non è un inventario di ciò che le applicazioni usano davvero su un host con risoluzione limitata o per dominio, quindi leggi lo stato del resolver come la piattaforma lo espone.

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

Interroga un nome privato e un nome pubblico una volta alzata la connessione, e annota quale collegamento ha risposto a ciascuno. Dove il collegamento VPN porta una lista di ricerca per dominio, un nome privato può risolversi correttamente mentre un nome pubblico va ancora al resolver locale, e quella separazione è il progetto che funziona e non un guasto. Se la query privata fallisce, ispeziona la rotta verso il resolver prima di toccare di nuovo il DNS; se riesce mentre un'applicazione continua a fallire, l'applicazione potrebbe leggere un resolver proprio in cache o configurato a parte.

Riconnettiti e conferma lo stato disconnesso

Abbassa la connessione e ripeti entrambe le query. Ciò che il proprietario scelto ha installato deve essere rimosso o ripristinato da quel proprietario, non lasciato indietro dal client che hai zittito. Una voce per collegamento obsoleta che sopravvive al tunnel continua a inviare query private a un indirizzo che non è più raggiungibile.

Poi riconnettiti e leggi di nuovo gli stessi tre valori: indirizzo del resolver, domini di ricerca, interfaccia.

Se corrispondono alla politica che hai annotato, il passaggio è completo e il client VPN non è più uno degli scrittori. Se un valore torna indietro pochi secondi dopo l'alzarsi del collegamento, qualcos'altro sta ancora applicando configurazione, e il passo successivo è identificare quel componente invece di aggiungere un altro indicatore. Lo stato finale che vuoi è senza incidenti: un proprietario, una politica documentata e un host disconnesso che risolve esattamente come faceva prima che il tunnel esistesse.