SSH valt elke minuut weg op de VPN? Het is niet de keepalive

SSH maakt verbinding, werkt ongeveer een minuut en bevriest dan elke keer met ongeveer hetzelfde interval. De gangbare verklaring is een idle-timeout, dus mensen verlagen de MTU en zetten keepalives aan de clientkant. De WireGuard-verbinding waaraan ik werkte had dat allemaal al gehad: een kleinere tunnel-MTU, client-alive-instellingen, een geconfigureerde tunnel-keepalive. De onderbrekingen gingen ongewijzigd door. De oorzaak bleek een asymmetrische LAN-route, en het patroon is de moeite waard te herkennen omdat het elke op timers gebaseerde oplossing verslaat.

Een keepalive bewijst dat je host nog steeds wil verzenden. Hij kan een stateful apparaat geen antwoord laten zien dat er nooit doorheen gaat.

De mythe: keepalives verhelpen een stille onderbreking

SSH-keepalives bestaan voor één taak: voorkomen dat iets dat stilte telt een inactieve sessie opruimt. Dat doen ze goed. Ze lossen geen stateful apparaat op dat het eerste pakket in één richting zag en daarna nooit het antwoord, want niets wat de client stuurt verandert welke interface het antwoord gebruikt.

Een MTU-wijziging is de andere populaire oplossing, en die heeft dezelfde faalmodus. De MTU verlagen helpt bij fragmentatie en path-MTU-problemen, en het doet niets aan een route. Als je timers en MTU al redelijk zijn en de onderbreking blijft op een herhaalbaar interval, dan vertelt het interval je over een timeout ergens, niet over pakketgrootte. Schrijf het interval op en vergelijk het met de state-timeouts op elk apparaat in het pad.

Het teken is regelmaat in combinatie met een sessie die binnen dat interval bruikbaar blijft. Idle-timeouts slaan toe als er niets gebeurt; deze slaat toe terwijl je typt.

Wat de extra gateway werkelijk doet

Zet de laptop en de VPN-gateway op hetzelfde LAN, met een aparte LAN-firewall als standaardgateway. De laptop stuurt VPN-verkeer naar de firewall, de firewall stuurt het door naar de gateway, en de antwoorden van de gateway gaan rechtstreeks via het LAN terug naar de laptop. Dat tweede been gaat nooit door de firewall, dus de statustabel houdt een halve verbinding.

De adressen hieronder weerspiegelen die opstelling:

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

Redirects en statusafhandeling maken dan van een werkende handshake een verbinding die later sterft in plaats van meteen. De vertraging is de statusvermelding die veroudert of een strengere controle die faalt, waardoor het interval zo mechanisch lijkt.

Niets hiervan verschijnt in de clientconfiguratie, en daarom begint het zoeken ernaar meestal in het verkeerde bestand.

Kies één bewust pad

Voor de opstelling hierboven verwijdert het routeren van het externe subnet rechtstreeks naar de VPN-gateway de halve verbinding:

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

Dat zijn voorbeeldadressen. De volgende hop moet bereikbaar zijn op je LAN, het prefix moet het bedoelde externe netwerk zijn, en de tweede opdracht laat je het resultaat zien voordat je erop vertrouwt. Als de gateway niet op je subnet staat, is deze route niet de oplossing die je wilt.

Als de firewall het verkeer tussen die systemen moet bewaken, is eromheen routeren het verkeerde ontwerp. Laat in plaats daarvan beide richtingen de grens passeren en configureer de routes aan elke kant zodat het terugpad klopt. Het doel is één bewust pad, niet minder statuscontrole.

Netgates notities over asymmetrische routering beschrijven dezelfde asymmetrie op interfaceniveau en de statusproblemen die zij veroorzaakt, dus lees ze voordat je statusafhandeling wereldwijd versoepelt. Getimede onderbrekingen zoals dit geval zijn op zichzelf geen bewijs. Behandel het artikel als een beschrijving van één faalmodus en bewijs daarna dat je eigen netwerk erbij past voordat je het wereldwijde statusbeleid wijzigt.

Test het van beide kanten

Lees de route van de laptop naar de bestemming en de route van de bestemming terug naar de laptop; dat zijn twee aparte beslissingen en waarschijnlijk is er maar één van beide fout. Een ping die vanaf de gateway zelf slaagt, kan het probleem volledig verbergen, omdat hij afkomstig is van de machine wier pad al correct is. Je hebt beide richtingen nodig zoals de twee uiteinden van de werkelijke sessie ze zien.

Open na de oplossing SSH opnieuw en houd de sessie open ruim voorbij het interval dat vroeger faalde. Maak de route daarna permanent in de goedgekeurde netwerkconfiguratie, want een eenmalige opdracht is geen herstartplan en het probleem komt bij de volgende herstart terug met een nieuw mysterie.

Wanneer asymmetrie in orde is

Asymmetrische routering is in veel netwerken normaal en is per definitie niet kapot. Het wordt een probleem wanneer statusbewaking, vertaling of beleid afhankelijk zijn van het zien van een pad dat ze niet zien, en elk daarvan heeft een ander middel. Controleer wat het middelste apparaat werkelijk vereist voordat je eromheen herontwerpt.

Het duurzame antwoord noemt de twee paden, het apparaat dat beide moet zien, en de route die dat mogelijk maakt. Als je het apparaat niet kunt noemen, heb je de oorzaak nog niet gevonden.