Avvii un client VPN via SSH? Fissa prima la tua rotta

Ti connetti via SSH a un host di build, avvii lì il client VPN e la sessione smette di rispondere. Niente si è bloccato, e niente sembra configurato male nel senso ovvio. Il client ha installato una rotta predefinita, quindi le risposte verso la tua workstation ora escono dal tunnel, dove l'indirizzo della tua workstation non è instradabile. La parte interessante è che questo esito era prevedibile, e la correzione è una rotta scritta prima che il client parta. Supponiamo un server con una sola scheda di rete, un gateway 192.0.2.254 e un amministratore che si connette da 203.0.113.9.

Registra il percorso prima di iniziare

ip route show default indica il gateway e l'interfaccia attuali, mentre ip route get 203.0.113.9 mostra quale interfaccia e quale indirizzo sorgente userebbe il kernel per la tua sessione. Conserva entrambi gli output. Dopo che il tunnel sale, quei due comandi dovrebbero ancora descrivere il percorso fisico, e se descrivono invece il tunnel, la sessione vive già di tempo preso in prestito.

Conta la connessione già stabilita, quindi non convalidare solo con un nuovo accesso. Una nuova sessione può riuscire brevemente grazie a uno stato che la vecchia non ha più.

Fissa l'indirizzo nella configurazione del client stesso

Una rotta aggiunta a mano sparisce al riavvio e gareggia con gli aggiornamenti della tabella del client stesso, quindi metti l'eccezione dove la tabella è gestita. In OpenVPN la parola chiave net_gateway si risolve nel gateway che esisteva prima del tunnel, quindi route 203.0.113.9 255.255.255.255 net_gateway mantiene esattamente un indirizzo fuori. WireGuard richiede un approccio diverso perché wg-quick gestisce le rotte da sé: imposta Table = off e aggiungi l'eccezione in PostUp, con un PostDown corrispondente che la rimuove. Entrambe le forme esprimono la stessa intenzione, ed entrambe limitano l'eccezione a un indirizzo invece di indebolire il tunnel per tutto.

Per IPv6 la stessa idea prende un prefisso a host singolo, e il caso del trasporto incapsulato vale la pena ricordarlo: se la connessione esterna del tunnel stesso vive su un indirizzo fisso, quell'indirizzo deve restare fuori dal tunnel che trasporta, altrimenti il client instrada il proprio trasporto dentro se stesso.

Oppure togli la tabella principale dall'equazione

Quando più servizi sull'host devono mantenere il loro percorso normale, smetti di modificare la tabella principale e dai al client la sua. Uno spazio dei nomi di rete con una coppia veth lo fa in modo pulito: la rotta predefinita del client vive in un altro stack e solo i processi avviati al suo interno usano il tunnel. Il policy routing arriva in un posto simile per una destinazione, inviando il traffico corrispondente a una tabella dedicata la cui rotta predefinita punta ancora al gateway fisico. Ciascuno dei due approcci lascia la tabella principale dell'host senza una nuova rotta predefinita, ed è questa proprietà che mantiene SSH in grado di rispondere.

Entrambi sono più macchinario di una singola rotta host, ed entrambi valgono la pena quando più di una cosa sulla macchina deve sopravvivere al tunnel.

Dai per scontato che il fissaggio possa fallire

Una rotta legata al tuo indirizzo pubblico attuale si rompe nel momento in cui il tuo provider lo riassegna. Un server remoto ha allora bisogno di un percorso che non dipenda da quell'indirizzo: una console, una seconda interfaccia di gestione o un jump host che resta fuori dal tunnel.

Due salvaguardie costano dieci minuti. Un watchdog che ferma il client se un accesso di conferma non compare entro qualche minuto trasforma un blocco in un ritardo, e una seconda sessione SSH tenuta aperta durante il cambiamento dimostra che l'eccezione funziona mentre il tunnel è su. I soli keepalive non aiutano qui, perché il percorso è sparito invece di essere inattivo; rendono solo la morte più facile da notare.

Verifica nell'ordine che conta

Connetti il tunnel, conferma che la rotta verso il tuo indirizzo esce ancora dal gateway fisico, poi apri una nuova sessione. Se la nuova sessione funziona e la vecchia muore comunque, la causa è il connection tracking o un firewall stateful e non l'instradamento, il che è una correzione diversa.

Scrivi l'indirizzo fissato e il comando che l'ha dimostrato nel registro delle modifiche. La prossima persona che avvierà un client su quell'host avrà bisogno di entrambi, e l'indirizzo potrebbe essere già cambiato nel frattempo.