Il server web scompare quando il client VPN si connette

Un servizio che scompare nel momento in cui un client VPN si connette di solito non è bloccato, ma risponde tramite l’interfaccia sbagliata. La richiesta arriva sulla scheda di rete fisica, il demone scrive una risposta e la tabella di routing consegna quella risposta al tunnel, poiché il tunnel ha assunto la rotta predefinita. Il client remoto non vede mai una risposta a una connessione che ha aperto, quindi attende e poi segnala un timeout. Nessuna regola del firewall interviene in quella sequenza.

Il sintomo: richieste in entrata, risposte dalla porta sbagliata

L’indizio è una connessione in entrata che fallisce mentre tutto il resto sull’host funziona. Un altro indizio è un host raggiungibile dalla LAN ma non da internet, o uno che funziona finché il tunnel non si riconnette e poi si ferma. In ogni caso la direzione di andata si comportava bene e quella di ritorno no, il che indica un’asimmetria di routing e non una policy.

Confermatelo osservando dove va la risposta, non osservando come arriva la richiesta.

Catturate insieme sull’interfaccia fisica e sul dispositivo del tunnel. Se la richiesta compare sull’interfaccia fisica e la risposta sul tunnel, la diagnosi è conclusa. Una risposta che non compare da nessuna parte significa che il servizio non ha mai accettato la connessione, il che è un’indagine separata con una causa separata.

Due rotte predefinite e una sola decisione di routing

Un client che installa una rotta predefinita aggiunge una seconda voce con una metrica migliore di quella del gateway della LAN. Alcuni client installano invece due rotte a metà intervallo, che coprono lo stesso spazio in modo più specifico e vincono la ricerca allo stesso modo. Entrambe le tecniche lasciano che i normali pacchetti in uscita scelgano l’interfaccia del tunnel.

Questa scelta avviene solo per destinazione. Il kernel non chiede da dove sia arrivato un pacchetto se non glielo impone una regola di policy. Così la risposta a un indirizzo pubblico del client viene consegnata al tunnel, il cui estremo remoto riceve un pacchetto con un indirizzo di origine che non possiede e lo scarta o lo inoltra in un luogo inutile. Su Linux, un filtro rigoroso del percorso inverso può anche scartare la richiesta originale prima che il vostro servizio la veda, il che dall’esterno appare identico. Entrambi i sintomi derivano dalla stessa associazione mancante tra un flusso in entrata e la sua risposta.

Il tunnel si comporta correttamente per tutto il tempo. Gli è stato detto di portare la rotta predefinita e fa esattamente questo.

Riparate il percorso di ritorno senza rompere il tunnel

Esistono tre forme durature di riparazione, e la scelta dipende da quanta parte del traffico proprio dell’host deve restare dentro il tunnel. Escludere la destinazione o la porta del servizio è la modifica più piccola. Il routing per policy secondo l’origine o il marchio è il più preciso. La traduzione dell’origine è la più grossolana e la più facile da spiegare due anni dopo.

Scegliete in base a ciò che l’host deve fare, non in base a quale frammento avete trovato per primo.

Escludere una destinazione si adatta a un servizio con un indirizzo pubblico stabile, e legare il demone all’indirizzo fisico anziché a ogni indirizzo rende più sicura quell’esclusione. Una regola di policy che sceglie una tabella in base all’origine mantiene le connessioni dell’host dentro il tunnel mentre restituisce le risposte del servizio attraverso il gateway WAN. Mascherare le risposte sull’interfaccia WAN raggiunge lo stesso percorso al prezzo di nascondere l’indirizzo del client dai log del servizio. Un cambio improvvisato della rotta predefinita è una diagnosi e non una configurazione, perché il client riscrive le rotte a ogni riconnessione.

ip rule show
ip route get 203.0.113.9 from 192.0.2.44

Quando l’host instrada anche per una LAN dietro di sé

Un salto più in là, la stessa asimmetria ritorna con più parti in movimento. Il traffico raggiunge il router da internet, viene inoltrato a un dispositivo interno, e l’unico percorso di ritorno di quel dispositivo è il tunnel, quindi la risposta raggiunge il client originale dall’indirizzo del provider stesso. Il tracciamento delle connessioni incontra allora una risposta per un flusso di cui non ha visto l’inizio, e la scarta. Il client, nel frattempo, non vede assolutamente nulla.

Due modifiche lo riparano: la traduzione di destinazione perché la connessione in entrata raggiunga il dispositivo interno, e la traduzione di origine perché la risposta di quel dispositivo sembri venire dal router stesso.

Nel firmware del router l’espressione abituale è una regola di policy che fissa l’inoltro delle porte sul lato WAN mentre il traffico proprio del router viaggia sul tunnel. Senza traduzione di origine, quella risposta è indirizzata al client esterno e il dispositivo interno semplicemente non ha una rotta verso di essa. Provate tre cose separatamente, perché falliscono per motivi diversi: una connessione che arriva dall’esterno, una che l’host stesso avvia e una ricerca di nome.