Perché route-nopull da solo lascia irraggiungibile il server file
Ignorare le rotte spinte è solo metà di un tunnel diviso. Scegli il proprietario della rotta, aggiungi a mano il prefisso dell’ufficio e prova tre flussi prima di dichiararlo risolto.
Il server file si apre bene, e la videochiamata nella finestra accanto inizia a scattare. Niente è lento e nessun MTU è sbagliato: il tuo client ha accettato l’elenco di rotte che il server gli ha dato, quindi ora ogni pacchetto esce dal firewall dell’ufficio. La soluzione non è un altro flag di regolazione ma una decisione su chi possiede la tabella delle rotte del client. Quella decisione appartiene a un solo posto, e i modi di fallire qui sotto ti dicono quale posto hai scelto davvero.
Decidi chi possiede la tabella delle rotte
Sono possibili tre proprietari. Il server può spingere rotte e un gateway predefinito, nel qual caso il client installa ciò che gli viene detto e diventa un tunnel completo. Il profilo del client può assumere la proprietà scartando le spinte e portando le proprie righe di rotta. Anche un gestore di connessioni desktop può possedere la decisione tramite le proprie proprietà di rotta e di rotta predefinita.
Ogni scelta fallisce in modo diverso, ed è per questo che vale la pena leggere la tabella prima di modificare un profilo. La riga che corrisponde al tuo sintomo è il proprietario che hai davvero.
| Owner | Where it lives | Result |
|---|---|---|
| Server | server config, redirect-gateway, pushed routes | client becomes a full tunnel |
| Profile | route-nopull and its own route lines | tunnel up, office prefix missing |
| Manager | never-default plus its own routes | desktop decides, profile ignored |
Scegline uno e scrivilo. Mescolarne due lascia un host il cui percorso predefinito contraddice la propria documentazione, e l’ingegnere successivo non può sapere quale livello ha vinto. Elimina esplicitamente il perdente.
route-nopull filtra le spinte, non aggiunge rotte
route-nopull appartiene al profilo del client, e il suo ordine in quel file è irrilevante perché scarta solo i valori che arrivano dal server. Scarta le rotte spinte, compresa una rotta predefinita spinta, mentre il tunnel sale comunque normalmente.
La conseguenza che le persone trascurano è che le opzioni DHCP spinte se ne vanno con loro. Anche le impostazioni DNS inviate dal server vengono scartate, così i nomi interni smettono di risolversi anche se il tunnel è sano e il server è raggiungibile per indirizzo.
Questo lascia un tunnel senza percorso verso il prefisso dell’ufficio a meno che tu non ne aggiunga uno: route-nopull seguito da route 10.30.0.0 255.255.0.0 nello stesso profilo. Quella riga porta un indirizzo e una maschera; non nomina un salto successivo.
Una forma alternativa aggiunge un token di gateway, route 10.30.0.0 255.255.0.0 vpn_gateway, che punta la voce al tunnel per nome. Gli importatori differiscono sul fatto di tradurre quella variante, quindi ispeziona la connessione salvata se la voce manca dalla tabella del kernel.
Verifica con ricerche di rotta, non con un ping
Un ping ti dice che qualcosa ha risposto. Una ricerca di rotta ti dice quale interfaccia sceglierebbe il kernel, ed è la domanda che hai posto davvero. Quattro comandi brevi separano una rotta assente da una rotta che punta al dispositivo sbagliato.
Leggi cosa ha installato il tunnel con ip route show dev tun0. Nessun output significa zero rotte, che non è un tunnel diviso funzionante, ed è il risultato abituale dell’aggiunta del filtro senza la riga esplicita.
Poi controlla un indirizzo dell’ufficio con ip route get 10.30.5.7, e un indirizzo internet ordinario con ip route get 1.1.1.1. Il secondo dovrebbe nominare l’interfaccia fisica; se nomina il tunnel, la spinta non è stata affatto filtrata.
Infine leggi ip rule, perché una regola di policy lasciata da un tentativo precedente può sovrascrivere la tabella che hai appena corretto. Un profilo corretto con una regola obsoleta sopra sembra esattamente un profilo rotto. Elimina la regola che hai aggiunto l’ultima volta prima di aggiungerne un’altra.
Le sottoreti sovrapposte sembrano un tunnel rotto
Due intervalli privati possono essere identici dal punto di vista del client, ed è lì che un tunnel diviso viene incolpato di qualcosa che non ha causato. Se l’ufficio distribuisce lo stesso prefisso che usa il tuo router di casa, la rotta del tunnel copre il router e la rete di casa sembra sparire.
Confronta l’indirizzo della tua interfaccia con la rotta che il profilo installa, usando un semplice elenco di indirizzi prima di cambiare qualsiasi cosa. La sovrapposizione è reale, e nessuna opzione del profilo la risolve. Quello che puoi correggere è la denominazione, così la prossima persona vede due intervalli invece di uno.
Le correzioni oneste sono rinumerare un lato o tradurre gli indirizzi in ufficio. Fissare una singola rotta host al router funziona finché l’indirizzo del router non cambia, e allora diventa un secondo mistero sopra il primo.
Fai sopravvivere la decisione a una riconnessione
Le voci digitate a mano non sopravvivono a una riconnessione, e un gestore di connessioni ricostruisce la tabella ogni volta che il profilo parte. Metti la decisione dove viene creata la connessione, che sia il profilo o le impostazioni salvate del gestore. Poi riavvia la connessione una volta di proposito invece di scoprire il comportamento durante una chiamata. Un profilo che funziona solo fino alla prossima riconnessione non è finito.
Esercita tre percorsi insieme: un host dell’ufficio per indirizzo letterale, lo stesso host per nome, e un sito pubblico normale. Quello centrale dipende dal servizio dei nomi che hai configurato dopo aver scartato le opzioni DNS spinte, ed è quello che fallisce in silenzio.