SSH falder på VPN hvert minut? Det er ikke keepalive

SSH forbinder, virker omkring et minut og fryser derefter med nogenlunde samme interval hver gang. Den gængse forklaring er en idle-timeout, så folk sænker MTU'en og sætter keepalives på klienten. Et WireGuard-link, jeg arbejdede på, havde allerede været igennem det hele: en mindre tunnel-MTU, client-alive-indstillinger, en konfigureret tunnel-keepalive. Afbrydelserne fortsatte uændret. Årsagen viste sig at være en asymmetrisk LAN-rute, og mønsteret er værd at genkende, fordi det slår enhver timerbaseret løsning.

En keepalive beviser, at din vært stadig er villig til at sende. Den kan ikke få en tilstandsfuld enhed til at se et svar, der aldrig krydser den.

Myten: keepalives løser en tavs afbrydelse

SSH-keepalives findes til én opgave: at forhindre, at noget, der tæller stilhed, rydder en inaktiv session. Det gør de godt. De løser ikke problemet for en tilstandsfuld enhed, der så den første pakke i én retning og derefter aldrig så svaret, fordi intet, klienten sender, ændrer, hvilken grænseflade svaret bruger.

En MTU-ændring er den anden populære løsning, og den har samme fejlmåde. At sænke MTU'en hjælper fragmentering og path-MTU-problemer, og den gør intet ved en rute. Hvis dine timere og din MTU allerede er rimelige, og afbrydelsen stadig sker med et gentageligt interval, fortæller intervallet dig om en timeout et sted, ikke om pakkestørrelse. Skriv intervallet ned, og sammenlign det med tilstandstimeouts på hver enhed på ruten.

Tegnet er regelmæssighed kombineret med en session, der forbliver brugbar inden for det interval. Idle-timeouts rammer, når intet sker; denne rammer, mens du skriver.

Hvad den ekstra gateway faktisk gør

Sæt bærbaren og VPN-gatewayen på samme LAN med en separat LAN-firewall som standardgateway. Bærbaren sender VPN-trafik til firewallen, firewallen videresender den til gatewayen, og gatewayens svar går direkte tilbage over LAN'et til bærbaren. Det andet ben passerer aldrig firewallen, så dens tilstandstabel holder en halv forbindelse.

Adresserne nedenfor afspejler den opsætning:

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

Omdirigeringer og tilstandshåndtering gør derefter et fungerende handshake til en forbindelse, der dør senere i stedet for straks. Forsinkelsen er tilstandsposten, der udløber, eller en strengere kontrol, der fejler, og derfor ser intervallet så mekanisk ud.

Intet af dette vises i klientkonfigurationen, og derfor starter søgningen efter det normalt i den forkerte fil.

Vælg én bevidst vej

For opsætningen ovenfor fjerner routing af det fjernede subnet direkte til VPN-gatewayen den halve forbindelse:

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

Det er eksempeladresser. Det næste hop skal kunne nås på dit LAN, præfikset skal være det tilsigtede fjernnetværk, og den anden kommando viser dig resultatet, før du stoler på det. Hvis gatewayen ikke er på dit subnet, er denne rute ikke den løsning, du vil have.

Hvis firewallen skal overvåge trafik mellem de systemer, er routing uden om den et forkert design. Lad i stedet begge retninger passere grænsen, og konfigurer ruterne på hver side, så returvejen stemmer. Målet er én bevidst vej, ikke mindre tilstandskontrol.

Netgates noter om asymmetrisk routing beskriver den samme asymmetri på grænsefladeniveau og de tilstandsproblemer, den skaber, så læs dem, før du løsner tilstandshåndteringen globalt. Tidsbestemte afbrydelser som denne er ikke bevis i sig selv. Behandl artiklen som en beskrivelse af én fejlmåde, og bevis derefter, at dit eget netværk passer på den, før du ændrer den globale tilstandspolitik.

Test det fra begge ender

Læs bærbarens rute mod destinationen og destinationens rute tilbage mod bærbaren; det er to separate beslutninger, og kun den ene af dem er sandsynligvis forkert. En ping, der lykkes fra gatewayen selv, kan skjule problemet helt, fordi den udgår fra maskinen, hvis vej allerede er korrekt. Du har brug for begge retninger, som de ses af de to ender af den faktiske session.

Efter rettelsen skal du genåbne SSH og holde sessionen åben et godt stykke ud over det interval, der plejede at fejle. Gør derefter ruten permanent i den godkendte netværkskonfiguration, fordi en engangskommando ikke er en genstartplan, og problemet vender tilbage ved næste genstart med et nyt mysterium.

Når asymmetri er i orden

Asymmetrisk routing er normalt i mange netværk og er ikke brudt per definition. Det bliver et problem, når tilstandssporing, oversættelse eller politik afhænger af at se en vej, den ikke ser, og hver af dem har en forskellig løsning. Undersøg, hvad den midterste enhed faktisk kræver, før du redesigner omkring den.

Det holdbare svar nævner de to veje, den enhed, der skal se begge, og den rute, der gør det muligt. Hvis du ikke kan navngive enheden, har du ikke fundet årsagen endnu.