Perché una rotta a tunnel completo taglia fuori il server che la trasporta

Attiva un tunnel completo e ogni destinazione appartiene ora all’interfaccia VPN, compresa la macchina che lo termina. I pacchetti esterni che trasportano il tunnel sono indirizzati a quella macchina, quindi la rotta finisce per consumare il trasporto da cui dipende. Una rotta specifica in più risolve, e vale la pena capire il motivo. Senza quel motivo, la prossima ricostruzione reintroduce il difetto.

Una rotta che mangia il proprio trasporto

L’incapsulamento avvolge ogni pacchetto in una seconda intestazione. Quella esterna è indirizzata dall’indirizzo fisico locale all’indirizzo pubblico del server, e deve attraversare il collegamento fisico prima che qualsiasi tunnel possa esistere.

Ora lascia che la ricerca di quell’indirizzo pubblico scelga il tunnel. Per inviare il pacchetto, la macchina deve incapsularlo, il che richiede una rotta verso lo stesso indirizzo, che restituisce il tunnel. I client lo gestiscono in uno di due modi. Uno attento rifiuta di installare la rotta predefinita e segnala un errore, mentre uno meno attento segnala successo e poi non sposta nulla. Il guasto silenzioso è quello che costa un pomeriggio.

La corrispondenza del prefisso più lungo decide la ricerca prima che si consulti qualsiasi metrica, quindi una rotta a indirizzo singolo supera ogni rotta predefinita della macchina. È tutto il meccanismo dietro la riparazione.

Installa l’eccezione prima della predefinita

Crea una rotta a indirizzo singolo per il server, con il gateway fisico come salto successivo, prima che la rotta predefinita si muova. L’ordine conta: installarla dopo significa convivere con un tunnel rotto mentre digiti.

La maggior parte dei client lo fa senza che venga chiesto. OpenVPN cerca l’indirizzo remoto e lo fissa prima di riscrivere il gateway predefinito, e la sua opzione route-delay esiste per le piattaforme dove quella sequenza corre. wg-quick prende una strada del tutto diversa, marcando i pacchetti e consultando una regola di policy invece di aggiungere un’eccezione. Meccanismi diversi, stesso requisito: il pacchetto esterno deve sfuggire al tunnel che crea.

ip route add 203.0.113.10/32 via 192.168.1.1 dev eth0
ip route get 203.0.113.10

L’output della ricerca è il test di accettazione. Deve nominare il dispositivo fisico e il salto successivo fisico. Un dispositivo di tunnel in quella risposta significa che l’eccezione manca, o è stata inserita dopo qualcosa che la sovrascrive.

L’immagine speculare sul server

La stessa trappola attende dall’altro lato, al contrario. Dai al server una rotta predefinita attraverso un altro tunnel, oppure spingigli una rotta che copre gli indirizzi pubblici dei client, e le sue risposte acquisiranno l’abitudine alla direzione sbagliata.

Immagina un client che si connette e invia una richiesta. La risposta è indirizzata all’indirizzo pubblico di quel client, che ora corrisponde a una rotta del tunnel, quindi parte da un’interfaccia diversa portando una sorgente che il client non ha mai composto. Il client può ricevere quel pacchetto e comunque scartarlo, perché nulla lo lega alla richiesta che ha inviato. Parti dalla decisione di routing del server invece che dal timeout del client, dato che solo una delle due mostra la scelta reale.

ip route get 198.51.100.44 from 10.90.0.1
ip rule show
sudo tcpdump -ni any host 198.51.100.44

Esistono tre riparazioni e non sono equivalenti. Fissare il servizio all’indirizzo fisico, o tradurre la sorgente, entrambe nascondono la decisione di routing invece di correggerla. Inviare il traffico di risposta del pool del tunnel attraverso una tabella dedicata corregge la causa, e le altre due sono accettabili solo finché il progetto di routing resta congelato.

Eccezioni che il tunnel continua a rubare

Una manciata di attività ha bisogno dell’internet aperto anche mentre il tunnel possiede la rotta predefinita, e ciascuna ha bisogno della propria eccezione. L’aggiornatore del DNS dinamico è di solito il primo a rompersi.

Risolve il provider, apre una connessione e scopre che i propri pacchetti viaggiano attraverso un tunnel il cui indirizzo è cambiato pochi secondi prima, quindi l’aggiornamento fallisce o pubblica l’indirizzo sbagliato. Tre vie d’uscita: fissare il provider con una rotta host attraverso il gateway fisico, eseguire l’aggiornamento prima che il tunnel salga, oppure dare all’aggiornatore una tabella di policy che il tunnel non tocca mai. La sincronizzazione dell’orario ha la stessa esposizione su un dispositivo che si avvia senza resolver, e gli endpoint di validazione dei certificati rientrano nell’elenco per lo stesso motivo.

Un’eccezione che nessuno ha scritto è un’eccezione che la prossima ricostruzione lascerà cadere in silenzio.

Provalo dopo una riconnessione, non prima

Prova tre destinazioni, non una: l’endpoint, un indirizzo privato dietro il tunnel e un indirizzo pubblico oltre. Una sola ricerca riuscita non dice quasi nulla sulle altre due.

ip route get 203.0.113.10
traceroute -n 203.0.113.10
ip route get 10.90.0.5
ip route get 1.1.1.1

Poi riavvia la connessione, perché un client che ricostruisce la sua tabella alla riconnessione scarterà una rotta che hai digitato a mano. Con un kill switch attivo, controlla che l’endpoint sia permesso, altrimenti il tunnel non può tornare dopo un cambio di rete e il sintomo sembra un’interruzione. Conserva l’eccezione nel profilo o nel file unit invece che nella cronologia della shell, così la riconnessione la ricrea invece di cancellarla.