SSH tappar VPN varje minut? Det är inte keepalive

SSH ansluter, fungerar ungefär en minut och fryser sedan med ungefär samma intervall varje gång. Den vanliga förklaringen är en idle-timeout, så folk sänker MTU:n och ställer in keepalives på klienten. WireGuard-länken jag arbetade med hade redan gått igenom allt detta: en mindre tunnel-MTU, client-alive-inställningar, en konfigurerad tunnel-keepalive. Avbrotten fortsatte oförändrade. Orsaken visade sig vara en asymmetrisk LAN-rutt, och mönstret är värt att känna igen eftersom det besegrar varje timerbaserad lösning.

En keepalive bevisar att din värd fortfarande är villig att skicka. Den kan inte få en tillståndsbaserad enhet att se ett svar som aldrig passerar den.

Myten: keepalives lagar ett tyst avbrott

SSH-keepalives finns för en enda uppgift: att hindra något som räknar tystnad från att rensa en inaktiv session. Det gör de bra. De löser inte en tillståndsbaserad enhet som såg det första paketet i en riktning och sedan aldrig såg svaret, eftersom inget klienten skickar ändrar vilket gränssnitt svaret använder.

En MTU-ändring är den andra populära lösningen, och den har samma felmod. Att sänka MTU:n hjälper fragmentering och path-MTU-problem, och den gör ingenting för en rutt. Om dina timers och din MTU redan är rimliga och avbrottet fortsätter med ett återkommande intervall, berättar intervallet om en timeout någonstans, inte om paketstorlek. Skriv ner intervallet och jämför det med tillståndstimeouterna på varje enhet i vägen.

Tecknet är regelbundenhet kombinerat med en session som förblir användbar inom det intervallet. Idle-timeouts slår till när ingenting händer; den här slår till medan du skriver.

Vad den extra gatewayen faktiskt gör

Sätt bärbara datorn och VPN-gatewayen i samma LAN, med en separat LAN-brandvägg som standardgateway. Den bärbara datorn skickar VPN-trafik till brandväggen, brandväggen vidarebefordrar den till gatewayen, och gatewayens svar går rakt tillbaka över LAN:et till den bärbara datorn. Det andra benet passerar aldrig brandväggen, så dess tillståndstabell håller en halv anslutning.

Adresserna nedan speglar den uppställningen:

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

Omdirigeringar och tillståndshantering gör sedan en fungerande handskakning till en anslutning som dör senare i stället för omedelbart. Fördröjningen är tillståndsposten som åldras eller en strängare kontroll som misslyckas, och därför ser intervallet så mekaniskt ut.

Inget av detta visas i klientkonfigurationen, och därför börjar sökandet efter det vanligtvis i fel fil.

Välj en medveten väg

För uppställningen ovan tar routning av fjärrsubnätet direkt till VPN-gatewayen bort den halva anslutningen:

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

Det är exempeladresser. Nästa hopp måste vara nåbart på ditt LAN, prefixet måste vara det avsedda fjärrnätverket, och det andra kommandot visar dig resultatet innan du litar på det. Om gatewayen inte finns i ditt subnät är den här rutten inte den lösning du vill ha.

Om brandväggen ska övervaka trafik mellan dessa system är routning runt den fel design. Låt i stället båda riktningarna passera gränsen och konfigurera rutter på varje sida så att returvägen stämmer. Målet är en enda medveten väg, inte mindre tillståndskontroll.

Netgates anteckningar om asymmetrisk routning beskriver samma asymmetri på gränssnittsnivå och de tillståndsproblem den skapar, så läs dem innan du lossar på tillståndshanteringen globalt. Tidsbestämda avbrott som liknar det här fallet är inte bevis i sig själva. Behandla artikeln som en beskrivning av ett felmod och bevisa sedan att ditt eget nätverk matchar det innan du ändrar den globala tillståndspolicyn.

Testa det från båda hållen

Läs den bärbara datorns rutt mot destinationen och destinationens rutt tillbaka mot den bärbara datorn; det är två separata beslut och förmodligen är bara ett av dem fel. En ping som lyckas från gatewayen själv kan dölja problemet helt, eftersom den utgår från maskinen vars väg redan är korrekt. Du behöver båda riktningarna så som de två ändarna av den faktiska sessionen ser dem.

Efter åtgärden, öppna SSH igen och håll sessionen öppen långt förbi det intervall som tidigare misslyckades. Gör sedan rutten permanent i den godkända nätverkskonfigurationen, eftersom ett engångskommando inte är en omstartsplan och problemet kommer tillbaka vid nästa omstart med ett nytt mysterium.

När asymmetri är okej

Asymmetrisk routning är normalt i många nätverk och är inte trasigt per definition. Det blir ett problem när tillståndsspårning, översättning eller policy är beroende av att se en väg de inte ser, och var och en av dem har ett annat botemedel. Kontrollera vad mellanliggande enhet faktiskt kräver innan du designar om runt den.

Det hållbara svaret namnger de två vägarna, enheten som måste se båda, och rutten som gör det möjligt. Om du inte kan namnge enheten har du inte hittat orsaken än.