L’SSH cau a la VPN cada minut? No és el keepalive

L’SSH es connecta, funciona aproximadament un minut i després es congela aproximadament al mateix interval cada vegada. L’explicació habitual és un temps d’inactivitat, així que la gent baixa l’MTU i configura keepalives al client. L’enllaç WireGuard en què vaig treballar ja havia passat per tot això: una MTU de túnel més petita, paràmetres client-alive i un keepalive de túnel configurat. Les caigudes continuaven igual. La causa va resultar ser una ruta LAN asimètrica, i el patró val la pena reconèixer-lo perquè derrota qualsevol correcció basada en temporitzadors.

Un keepalive demostra que el vostre amfitrió encara vol enviar. No pot fer que un dispositiu amb estat vegi una resposta que mai el travessa.

El mite: els keepalives arreglen una caiguda silenciosa

Els keepalives de l’SSH existeixen per a una sola feina: evitar que una cosa que compta el silenci reculli una sessió inactiva. Ho fan bé. No adrecen un dispositiu amb estat que va veure el primer paquet en una direcció i després no va veure mai la resposta, perquè res del que envia el client no canvia quina interfície fa servir la resposta.

Un canvi d’MTU és l’altra correcció popular, i té la mateixa manera de fallar. Reduir l’MTU ajuda la fragmentació i els problemes d’MTU de camí, i no fa res a una ruta. Si els vostres temporitzadors i l’MTU ja són raonables i la caiguda continua en un interval repetible, l’interval us parla d’un temps d’espera en algun lloc, no de la mida dels paquets. Apunteu l’interval i compareu-lo amb els temps d’espera d’estat de cada dispositiu del camí.

La pista és la regularitat combinada amb una sessió que continua sent utilitzable dins d’aquell interval. Els temps d’inactivitat ataquen quan no passa res; aquest ataca mentre escriviu.

Què fa realment la passarel·la addicional

Poseu l’ordinador portàtil i la passarel·la VPN a la mateixa LAN, amb un tallafoc LAN separat com a passarel·la per defecte. L’ordinador envia el trànsit destinat a la VPN al tallafoc, el tallafoc el reenvia a la passarel·la, i les respostes de la passarel·la tornen directament per la LAN fins a l’ordinador. Aquesta segona cama no passa mai pel tallafoc, així que la seva taula d’estat manté mitja connexió.

Les adreces de sota reflecteixen aquesta disposició:

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

Les redireccions i la gestió d’estat converteixen llavors un handshake funcional en una connexió que mor més tard en lloc d’immediatament. El retard és l’entrada d’estat que caduca o una comprovació més estricta que falla, i per això l’interval sembla tan mecànic.

Res d’això no apareix a la configuració del client, i per això la seva cerca sol començar al fitxer equivocat.

Trieu un camí deliberat

Per a la disposició de dalt, encaminar la subxarxa remota directament a la passarel·la VPN elimina la mitja connexió:

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

Aquestes són adreces d’exemple. El següent salt ha de ser abastable a la vostra LAN, el prefix ha de ser la xarxa remota prevista, i la segona ordre us mostra el resultat abans que hi confieu. Si la passarel·la no és a la vostra subxarxa, aquesta ruta no és la correcció que voleu.

Si el tallafoc ha de vigilar el trànsit entre aquests sistemes, encaminar-lo per fora és un disseny equivocat. Feu que les dues direccions travessin la frontera i configureu les rutes a cada costat perquè el camí de tornada coincideixi. L’objectiu és un sol camí deliberat, no menys comprovació d’estat.

Les notes sobre encaminament asimètric de Netgate descriuen la mateixa asimetria a nivell d’interfície i els problemes d’estat que crea, així que llegiu-les abans d’afluixar la gestió d’estat globalment. Les desconnexions temporals semblants a aquest cas no són prova per si soles. Tracteu l’article com la descripció d’una manera de fallar i després demostreu que la vostra xarxa hi encaixa abans de canviar la política global d’estat.

Proveu-ho des de les dues bandes

Llegiu la ruta de l’ordinador cap al destí i la ruta del destí de tornada cap a l’ordinador; són dues decisions separades i probablement només una és incorrecta. Un ping que té èxit des de la mateixa passarel·la pot amagar el problema del tot, perquè s’origina a la màquina el camí de la qual ja és correcte. Necessiteu les dues direccions tal com les veuen els dos extrems de la sessió real.

Després de la correcció, torneu a obrir l’SSH i manteniu la sessió oberta molt més enllà de l’interval que abans fallava. Després feu la ruta persistent a la configuració de xarxa aprovada, perquè una ordre puntual no és un pla de reinici i el problema tornarà al proper reinici amb un misteri nou.

Quan l’asimetria és correcta

L’encaminament asimètric és normal en moltes xarxes i no està trencat per definició. Es converteix en un problema quan el seguiment d’estat, la traducció o la política depenen de veure un camí que no veuen, i cadascun d’aquests té un remei diferent. Comproveu què requereix realment el dispositiu intermedi abans de redissenyar-hi al voltant.

La resposta duradora anomena els dos camins, el dispositiu que ha de veure els dos i la ruta que ho fa possible. Si no podeu anomenar el dispositiu, encara no heu trobat la causa.