route-gateway non è redirect-gateway: cosa cambia davvero

Il tunnel si alza, la sottorete privata risponde e la navigazione ordinaria continua a sparire nella VPN anche se qualcuno ha cancellato la riga del gateway dal profilo. Questa combinazione è l’impronta della direttiva sbagliata modificata. Ciò che è stato rimosso dava al client un salto successivo per le rotte che installa; ciò che continuava a catturare il traffico veniva da altrove ed è stato spinto dal server. Copertura e salto successivo sono compiti separati, e solo uno dei due decide se le destinazioni pubbliche usano il tunnel.

La riga che hai rimosso era un salto successivo, non un interruttore di policy

Ogni rotta che il client installa ha bisogno di un indirizzo di gateway verso cui puntare, e la direttiva del gateway è la fonte di quell’indirizzo quando una rotta non ne nomina uno. Cancellala e quelle rotte non hanno a cosa agganciarsi, quindi o non vengono installate o finiscono su un percorso che non porta da nessuna parte. La sottorete privata è esattamente ciò che una rotta simile trasportava.

Nel frattempo il comportamento sopravvissuto ha un altro autore: un’opzione di reindirizzamento nel blocco spinto, che sposta il traffico in uscita ordinario nel tunnel secondo i suoi flag. Rimuovere il gateway non la disattiva né la indebolisce. Il risultato è il peggio dei due stati, con il traffico pubblico ancora catturato e la destinazione privata che giustificava il tunnel ora irraggiungibile. Per questo anche la seconda modifica, fatta nello stesso spirito, non cambia nulla.

Quattro leve, quattro compiti diversi

In questa discussione quattro direttive vengono citate in modo intercambiabile, e solo una di esse governa la copertura, cioè quali destinazioni passano per il tunnel. Una seconda imposta il salto successivo usato dalle rotte, una terza installa un solo prefisso, e una quarta getta via tutto ciò che il server ha spinto, comprese le rotte private di cui ha bisogno la distribuzione. La tabella le ordina in base a ciò che un amministratore cerca di cambiare e non al nome, perché sono i nomi a causare la confusione. Trattale come quattro decisioni separate e scegli quella che vuoi davvero annullare.

In pratica tutte e quattro arrivano spesso in un unico blocco spinto, riga dopo riga, il che le fa sembrare parti di un’unica impostazione. Non lo sono, e la guida di OpenVPN le documenta come meccanismi distinti proprio per questo. Capire quale decisione stai annullando è il lavoro; la modifica è una riga.

Filtra la riga spinta, conserva il salto successivo

Se la copertura che contesti arriva come opzione spinta, la risposta stretta è ignorare quell’opzione per nome e lasciare intatto il resto del blocco spinto. Scritto come filtro, assomiglia alla riga qui sotto, e appartiene al profilo del client interessato, non alla configurazione del server.

pull-filter ignore "redirect-gateway"

La strettezza è il punto. Poiché il filtro confronta un prefisso di testo, uno schema più corto corrisponde anche alla direttiva del salto successivo, il che toglie esattamente l’informazione da cui dipendono le rotte private e riproduce l’errore originale in un abito nuovo. Un filtro agisce anche solo sulle opzioni spinte, quindi non tocca mai una riga equivalente scritta localmente o imposta da un gestore di rete. Riconnettiti dopo, perché una sessione attiva non rivaluta ciò che il server ha spinto.

Leggi la ricerca, non la tabella

Dopo aver ricaricato il profilo, chiedi al kernel dove andrebbero davvero due destinazioni: una dentro il prefisso privato e una su internet pubblico. Un dump completo della tabella principale è più difficile da leggere e più facile da leggere male, perché una rotta può esistere e comunque perdere contro una corrispondenza più specifica. Con l’instradamento basato su policy, anche la regola, la tabella e l’indirizzo di origine fanno parte del controllo.

ip route get 10.40.7.25
ip route get 203.0.113.77
ip rule show

La variante def1 merita familiarità, perché lascia visibile la vecchia voce predefinita mentre una coppia di mezze predefinite vince la ricerca. Quindi una riga 0.0.0.0/0 nell’output non dimostra nulla da sola. La ricerca risponde alla domanda a cui l’elenco sembra solo rispondere.

DNS, IPv6 e la rotta privata devono ancora funzionare

Rifiutare un reindirizzamento IPv4 non dice nulla sul resolver, quindi un’opzione DNS spinta può continuare a inviare query nel tunnel mentre le rotte sembrano corrette. Un valore predefinito IPv6 può fare lo stesso per una famiglia di indirizzi che il controllo IPv4 non ha mai toccato. Entrambi richiedono una decisione esplicita invece di un’ipotesi. Poi conferma che il servizio privato risponde ancora, perché un tunnel diviso che ha perso la sua rotta privata non è un tunnel diviso, è un tunnel rotto.

Uno strumento più ampio merita un avvertimento: route-nopull scarta tutte le rotte spinte e tutte le opzioni DNS spinte, il che ferma certamente il tunnel completo e altrettanto certamente rompe le rotte private da cui dipende la distribuzione, quindi è un martello molto più grande di un filtro per nome mirato a una sola opzione. Controlla la destinazione privata, una destinazione pubblica e il resolver dopo ogni modifica, e considera una stretta di mano completata come prova di nulla tranne la stretta di mano.