Il tunnel completo ha ucciso la sessione SSH: fissa la rotta di ritorno

Avvia un client OpenVPN sulla macchina su cui stai lavorando via SSH, e a metà comando la sessione si blocca. Il tunnel risulta connesso, l'host raggiunge internet attraverso di esso, e i tuoi tasti continuano ad arrivare mentre non torna nulla. Ciò che è cambiato non è il tunnel: è il percorso di ritorno dei pacchetti indirizzati a te, che ora corrisponde alla nuova rotta predefinita ed entra in un tunnel che il gateway remoto non userà per raggiungere la tua scrivania.

Che cosa installa davvero redirect-gateway

Nella sua forma def1, redirect-gateway aggiunge 0.0.0.0/1 e 128.0.0.0/1 invece di sovrascrivere la rotta predefinita. Queste due metà coprono l'intero spazio degli indirizzi pur restando entrambe prefissi più lunghi di 0.0.0.0/0, quindi ogni destinazione senza una corrispondenza più specifica finisce ora nel tunnel. È questo il meccanismo da tenere presente, perché ogni correzione qui sotto funziona installando una corrispondenza più specifica.

Il tuo indirizzo amministrativo è una di quelle destinazioni.

Il server VPN inoltra il traffico dei suoi client verso internet. Non ha alcuna rotta per l'indirizzo pubblico da cui ti connetti, né motivo di trattare quei pacchetti come qualcosa di diverso dal traffico in arrivo da un client, quindi li scarta. Nel frattempo la richiesta che hai inviato ha comunque raggiunto l'host, ed è per questo che la sessione sembra viva solo da un lato.

ip route show table main | head -n 20
ip route get 198.51.100.23

Trova il tuo indirizzo sorgente e il percorso precedente al tunnel

Sul server, elenca la connessione SSH stabilita e annota l'indirizzo del peer da cui è arrivata. È quell'indirizzo che la tua rotta di ritorno deve coprire, e non è sempre quello che pensi: un jump host, un gateway NAT o un traduttore dell'operatore possono sostituire la sorgente con un'altra.

Poi individua il gateway fisico e l'interfaccia che trasportavano il traffico prima che il tunnel partisse. Nella def1 configurazione la rotta predefinita è ancora presente sotto le mezze rotte predefinite, quindi l'informazione è disponibile, anche se leggere a occhio una tabella di routing lunga invita a errori.

Annota insieme i due valori e il nome dell'interfaccia, perché la rotta che stai per aggiungere li richiede tutti e tre. Se l'host usava una regola di policy routing per scegliere il suo uplink, una rotta semplice potrebbe non essere consultata affatto, e questa possibilità cambia la correzione.

Fissa una rotta host che superi le mezze rotte predefinite

Una rotta /32 è più lunga di entrambe le mezze rotte predefinite, quindi le risposte al tuo indirizzo la preferiscono al tunnel. Il next hop è il gateway precedente al tunnel e il dispositivo è l'interfaccia fisica, il che mantiene il pacchetto sul percorso che usava prima che il tunnel esistesse.

ip route add 198.51.100.23/32 via 203.0.113.1 dev eth0

Verifica con una lookup invece di ispezionare la tabella: la risposta deve nominare eth0 e il gateway, mai tun0.

OpenVPN aggiunge già una rotta host verso l'indirizzo del server VPN stesso per la stessa ragione, quindi lo schema è familiare e l'indirizzo amministrativo è semplicemente un'altra eccezione. Non ricorrere a route-nopull per risolvere questo, perché scarta le rotte push di cui il tunnel ha bisogno, compresa la rete remota e le opzioni DNS.

Falla sopravvivere a una riconnessione

Una rotta aggiunta a mano sparisce quando il client si riconnette e reinstalla la propria, il che trasforma una correzione in un disservizio ricorrente. Aggancia il comando a qualcosa che viene eseguito dopo l'installazione delle rotte.

Sia uno script route-up sia l'hook pre-up del gestore di rete funzionano, e il controllo affidabile è una riconnessione seguita dalla stessa lookup.

Su Windows l'equivalente è una rotta persistente aggiunta con -p, che sopravvive ai riavvii ma deve comunque puntare al gateway corretto dopo un cambio di rete. Qualunque sia la piattaforma, scrivi il motivo accanto alla rotta: il prossimo amministratore deve sapere che esiste per proteggere una sessione di gestione, non perché il progetto di rete lo richiedesse.

Quando una rotta fissata non basta ancora

Il filtraggio del percorso inverso può scartare un pacchetto che arriva su un'interfaccia ed esce da un'altra, che è esattamente ciò che crea una rotta fissata. Controlla il valore effettivo di rp_filter prima di disabilitare qualcosa a livello globale, e preferisci correggere l'asimmetria invece di spegnere il controllo. È l'impostazione per interfaccia quella che si applica, e la modalità loose spesso si limita a registrare l'asimmetria invece di scartare il pacchetto. Leggi entrambe le cose prima di concludere che il filtro sia colpa tua.

Gli host con policy routing hanno bisogno di una regola oltre che di una rotta, perché la base delle regole sceglie la tabella prima che venga consultata la rotta al suo interno. Una rotta nella tabella main è invisibile a un flusso che corrisponde a una regola che punta a un'altra tabella. Leggi le regole prima di aggiungere qualsiasi cosa a main. Se una regola copre già il traffico di gestione, l'eccezione appartiene invece alla tabella di quella regola.

Tieni aperta una console out-of-band mentre provi, e ricontrolla da un secondo login prima di scollegare quello che stai usando. Una rotta che manda il tuo traffico di gestione nel tunnel taglia la connessione attraverso cui la stai riparando. Rientrare allora significa una console seriale o un boot di recupero, che è uno scambio pessimo per essersi risparmiati un passaggio di verifica.