SSH faller på VPN hvert minutt? Det er ikke keepalive

SSH kobler til, virker omtrent et minutt og fryser deretter med omtrent samme intervall hver gang. Den vanlige forklaringen er en idle-timeout, så folk senker MTU-en og setter keepalives på klienten. WireGuard-lenken jeg jobbet med hadde allerede vært gjennom alt dette: en mindre tunnel-MTU, client-alive-innstillinger, en konfigurert tunnel-keepalive. Avbruddene fortsatte uendret. Årsaken viste seg å være en asymmetrisk LAN-rute, og mønsteret er verdt å kjenne igjen fordi det slår enhver timerbasert løsning.

En keepalive beviser at verten din fortsatt er villig til å sende. Den kan ikke få en tilstandsbasert enhet til å se et svar som aldri passerer den.

Myten: keepalives fikser et stille avbrudd

SSH-keepalives finnes for én oppgave: å hindre at noe som teller stillhet rydder bort en inaktiv økt. Det gjør de bra. De løser ikke problemet med en tilstandsbasert enhet som så den første pakken i én retning og deretter aldri så svaret, fordi ingenting klienten sender endrer hvilket grensesnitt svaret bruker.

En MTU-endring er den andre populære løsningen, og den har samme feilmodus. Å senke MTU-en hjelper fragmentering og path-MTU-problemer, og den gjør ingenting med en rute. Hvis timerne og MTU-en din allerede er fornuftige og avbruddet fortsatt skjer med et gjentakende intervall, forteller intervallet deg om en timeout et sted, ikke om pakkestørrelse. Skriv ned intervallet og sammenlign det med tilstandstimeoutene på hver enhet i banen.

Tegnet er regelmessighet kombinert med en økt som forblir brukbar innenfor det intervallet. Idle-timeouts slår til når ingenting skjer; denne slår til mens du skriver.

Hva den ekstra gatewayen faktisk gjør

Sett bærbaren og VPN-gatewayen på samme LAN, med en egen LAN-brannmur som standardgateway. Bærbaren sender VPN-trafikk til brannmuren, brannmuren videresender den til gatewayen, og gatewayens svar går rett tilbake over LAN-et til bærbaren. Det andre benet passerer aldri brannmuren, så tilstandstabellen holder en halv forbindelse.

Adressene nedenfor gjenspeiler den oppsettet:

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 tilstandsbehandling gjør deretter en fungerende håndtrykk til en forbindelse som dør senere i stedet for umiddelbart. Forsinkelsen er tilstandsoppføringen som eldes eller en strengere kontroll som feiler, og derfor ser intervallet så mekanisk ut.

Ingenting av dette vises i klientkonfigurasjonen, og derfor starter søket etter det vanligvis i feil fil.

Velg én bevisst vei

For oppsettet ovenfor fjerner ruting av det eksterne subnettet direkte til VPN-gatewayen den halve forbindelsen:

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

Det er eksempeladresser. Neste hopp må være nåbart på LAN-et ditt, prefikset må være det tiltenkte eksterne nettet, og den andre kommandoen viser deg resultatet før du stoler på det. Hvis gatewayen ikke er på subnettet ditt, er denne ruten ikke løsningen du vil ha.

Hvis brannmuren skal overvåke trafikk mellom disse systemene, er ruting utenom den feil design. La i stedet begge retninger passere grensen og konfigurer rutene på hver side slik at returveien stemmer. Målet er én bevisst vei, ikke mindre tilstandskontroll.

Netgates notater om asymmetrisk ruting beskriver den samme asymmetrien på grensesnittnivå og tilstandsproblemene den skaper, så les dem før du lemper på tilstandsbehandlingen globalt. Tidsbestemte avbrudd som ligner dette tilfellet er ikke bevis i seg selv. Behandle artikkelen som en beskrivelse av én feilmodus, og bevis deretter at ditt eget nettverk passer med den før du endrer den globale tilstandspolicyen.

Test det fra begge ender

Les bærbarens rute mot destinasjonen og destinasjonens rute tilbake mot bærbaren; det er to separate beslutninger, og bare én av dem er sannsynligvis feil. En ping som lykkes fra gatewayen selv, kan skjule problemet helt, fordi den kommer fra maskinen hvis vei allerede er riktig. Du trenger begge retninger slik de to endene av den faktiske økten ser dem.

Etter rettelsen, åpne SSH på nytt og hold økten åpen godt utover intervallet som pleide å feile. Gjør deretter ruten permanent i den godkjente nettverkskonfigurasjonen, fordi en engangskommando ikke er en omstartplan, og problemet kommer tilbake ved neste omstart med et nytt mysterium.

Når asymmetri er greit

Asymmetrisk ruting er normalt i mange nettverk og er ikke ødelagt per definisjon. Det blir et problem når tilstandssporing, oversettelse eller policy avhenger av å se en vei de ikke ser, og hver av disse har en annen kur. Sjekk hva mellomleddet faktisk krever før du redesigner rundt det.

Det varige svaret navngir de to veiene, enheten som må se begge, og ruten som gjør det mulig. Hvis du ikke kan navngi enheten, har du ikke funnet årsaken ennå.