SSH cade sulla VPN ogni minuto? Non è il keepalive

SSH si connette, funziona per circa un minuto, poi si blocca più o meno allo stesso intervallo ogni volta. La spiegazione comune è un timeout di inattività, quindi le persone abbassano l’MTU e impostano keepalive sul client. Il collegamento WireGuard su cui lavoravo aveva già passato tutto questo: un MTU del tunnel più piccolo, impostazioni client-alive, un keepalive del tunnel configurato. Le cadute continuavano invariate. La causa si è rivelata una rotta LAN asimmetrica, e lo schema merita di essere riconosciuto perché batte ogni correzione basata su timer.

Un keepalive dimostra che il tuo host è ancora disposto a inviare. Non può far vedere a un dispositivo con stato una risposta che non lo attraversa mai.

Il mito: i keepalive riparano una caduta silenziosa

I keepalive SSH esistono per un solo compito: impedire che qualcosa che conta il silenzio recuperi una sessione inattiva. Lo fanno bene. Non risolvono il caso di un dispositivo con stato che ha visto il primo pacchetto in una direzione e poi non ha mai visto la risposta, perché nulla di ciò che invia il client cambia quale interfaccia usa la risposta.

Cambiare l’MTU è l’altra correzione popolare, e ha la stessa modalità di guasto. Ridurre l’MTU aiuta la frammentazione e i problemi di MTU del percorso, e non fa nulla a una rotta. Se i tuoi timer e l’MTU sono già ragionevoli e la caduta è ancora a intervalli regolari, l’intervallo ti parla di un timeout da qualche parte, non della dimensione dei pacchetti. Annota l’intervallo e confrontalo con i timeout di stato su ogni dispositivo del percorso.

L’indizio è la regolarità combinata con una sessione che resta utilizzabile dentro quell’intervallo. I timeout di inattività colpiscono quando non succede nulla; questo colpisce mentre stai digitando.

Cosa fa davvero il gateway aggiuntivo

Metti il portatile e il gateway VPN sulla stessa LAN, con un firewall LAN separato come gateway predefinito. Il portatile invia il traffico diretto alla VPN al firewall, il firewall lo inoltra al gateway, e le risposte del gateway tornano direttamente attraverso la LAN al portatile. Quel secondo tratto non passa mai dal firewall, quindi la sua tabella di stato tiene mezza connessione.

Gli indirizzi qui sotto riflettono questa disposizione:

Laptop:             192.168.50.20
LAN firewall:       192.168.50.1
WireGuard gateway:  192.168.50.10
Remote VPN subnet:  10.77.0.0/24

I reindirizzamenti e la gestione dello stato trasformano poi un handshake funzionante in una connessione che muore più tardi anziché subito. Il ritardo è la voce di stato che scade o un controllo più severo che fallisce, ed è per questo che l’intervallo sembra così meccanico.

Niente di tutto questo appare nella configurazione del client, ed è per questo che la sua ricerca di solito inizia nel file sbagliato.

Scegli un percorso deliberato

Per la disposizione sopra, instradare la sottorete remota direttamente verso il gateway VPN elimina la mezza connessione:

sudo ip route add 10.77.0.0/24 via 192.168.50.10
ip route get 10.77.0.42

Sono indirizzi di esempio. Il salto successivo deve essere raggiungibile sulla tua LAN, il prefisso deve essere la rete remota prevista, e il secondo comando ti mostra il risultato prima che tu ci faccia affidamento. Se il gateway non è sulla tua sottorete, questa rotta non è la correzione che vuoi.

Se il firewall deve sorvegliare il traffico tra quei sistemi, instradare aggirandolo è un progetto sbagliato. Fai invece attraversare il confine a entrambe le direzioni e configura le rotte su ciascun lato perché il percorso di ritorno corrisponda. L’obiettivo è un unico percorso deliberato, non meno controllo dello stato.

Le note sul routing asimmetrico di Netgate descrivono la stessa asimmetria a livello di interfaccia e i problemi di stato che crea, quindi leggile prima di allentare la gestione dello stato a livello globale. Le disconnessioni temporizzate simili a questo caso non sono prove da sole. Tratta l’articolo come la descrizione di una modalità di guasto, poi dimostra che la tua rete vi corrisponde prima di cambiare la politica di stato globale.

Provalo da entrambe le estremità

Leggi la rotta del portatile verso la destinazione e la rotta della destinazione verso il portatile; sono due decisioni separate e probabilmente solo una delle due è sbagliata. Un ping che riesce dal gateway stesso può nascondere del tutto il problema, perché parte dalla macchina il cui percorso è già corretto. Ti servono entrambe le direzioni come le vedono le due estremità della sessione reale.

Dopo la correzione, riapri SSH e tieni la sessione aperta ben oltre l’intervallo che prima falliva. Poi rendi la rotta persistente nella configurazione di rete approvata, perché un comando una tantum non è un piano di riavvio e il problema tornerà al prossimo riavvio con un nuovo mistero.

Quando l’asimmetria va bene

Il routing asimmetrico è normale in molte reti e non è rotto per definizione. Diventa un problema quando il tracciamento dello stato, la traduzione o la politica dipendono dal vedere un percorso che non vedono, e ognuno di questi ha un rimedio diverso. Controlla ciò che il dispositivo intermedio richiede davvero prima di riprogettare attorno a esso.

La risposta duratura nomina i due percorsi, il dispositivo che deve vedere entrambi e la rotta che lo rende possibile. Se non riesci a nominare il dispositivo, non hai ancora trovato la causa.