SSH fell på VPN kvart minutt? Det er ikkje keepalive

SSH koplar til, verkar omtrent eitt minutt og frys så med omtrent same intervall kvar gong. Den vanlege forklaringa er ein idle-timeout, så folk senkjer MTU-en og set keepalives på klienten. WireGuard-lenkja eg arbeidde med hadde alt vore gjennom dette: ein mindre tunnel-MTU, client-alive-innstillingar, ein konfigurert tunnel-keepalive. Avbrota heldt fram utan endring. Årsaka viste seg å vere ei asymmetrisk LAN-rute, og mønsteret er verdt å kjenne att fordi det slår kvar timerbasert løysing.

Ein keepalive provar at verten din framleis er viljug til å sende. Han kan ikkje få eit tilstandsbasert apparat til å sjå eit svar som aldri passerer det.

Myten: keepalives fiksar eit stille avbrot

SSH-keepalives finst for éin oppgåve: å hindre at noko som tel stille fjernar ei inaktiv økt. Det gjer dei godt. Dei løyser ikkje problemet med eit tilstandsbasert apparat som såg den første pakken i éi retning og deretter aldri så svaret, fordi ingenting klienten sender endrar kva grensesnitt svaret brukar.

Ei MTU-endring er den andre populære løysinga, og ho har same feilmodus. Å senkje MTU-en hjelper fragmentering og path-MTU-problem, og ho gjer ingenting med ei rute. Viss timarane og MTU-en din alt er rimelege og avbrotet framleis skjer med eit gjentakande intervall, fortel intervallet deg om ein timeout ein stad, ikkje om pakkestorleik. Skriv ned intervallet og samanlikn det med tilstandstimeoutane på kvar eining i banen.

Teiknet er regelmessigheit kombinert med ei økt som held seg brukande innanfor det intervallet. Idle-timeouts slår til når ingenting skjer; denne slår til medan du skriv.

Kva den ekstra gatewayen faktisk gjer

Set den berebara datamaskinen og VPN-gatewayen på same LAN, med ein eigen LAN-brannmur som standardgateway. Den berebara datamaskinen sender VPN-trafikk til brannmuren, brannmuren videresender han til gatewayen, og svara frå gatewayen går rett tilbake over LAN-et til den berebara datamaskinen. Det andre beinet passerer aldri brannmuren, så tilstandstabellen held ei halv tilkopling.

Adressene nedanfor speglar dette 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

Omdirigeringar og tilstandsbehandling gjer deretter eit fungerande handtrykk om til ei tilkopling som døyr seinare i staden for straks. Forsinkinga er tilstandsoppføringa som eldast eller ein strengare kontroll som feilar, og difor ser intervallet så mekanisk ut.

Ingenting av dette viser seg i klientkonfigurasjonen, og difor byrjar søket etter det vanlegvis i feil fil.

Vel éin medviten veg

For oppsettet ovanfor fjernar ruting av det eksterne subnettet direkte til VPN-gatewayen den halve tilkoplinga:

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

Det er døme på adresser. Neste hopp må vere nåbart på LAN-et ditt, prefikset må vere det tiltenkte eksterne nettet, og den andre kommandoen viser deg resultatet før du stolar på det. Viss gatewayen ikkje er på subnettet ditt, er denne ruta ikkje løysinga du vil ha.

Viss brannmuren skal overvake trafikk mellom desse systema, er ruting utanom han feil design. La i staden begge retningar passere grensa og konfigurer rutene på kvar side slik at returvegen stemmer. Målet er éin medviten veg, ikkje mindre tilstandskontroll.

Netgates notat om asymmetrisk ruting skildrar den same asymmetrien på grensesnittnivå og tilstandsproblema han skapar, så les dei før du lempar på tilstandsbehandlinga globalt. Tidsbestemte avbrot som liknar dette tilfellet er ikkje bevis i seg sjølv. Handsame artikkelen som ei skildring av éin feilmodus, og prov deretter at ditt eige nettverk passar med han før du endrar den globale tilstandspolitikken.

Test det frå begge endar

Les ruta til den berebara datamaskinen mot målet og ruta til målet tilbake mot den berebara datamaskinen; det er to separate avgjerder, og berre éi av dei er truleg feil. Ein ping som lukkast frå gatewayen sjølv, kan skjule problemet heilt, fordi han kjem frå maskinen der vegen alt er rett. Du treng begge retningane slik dei to endane av den faktiske økta ser dei.

Etter rettinga, opne SSH på nytt og hald økta open godt utover intervallet som pleidde å feile. Gjer deretter ruta permanent i den godkjende nettverkskonfigurasjonen, fordi ein eingongskommando ikkje er ein omstartplan, og problemet kjem tilbake ved neste omstart med eit nytt mysterium.

Når asymmetri er greitt

Asymmetrisk ruting er normalt i mange nettverk og er ikkje øydelagt per definisjon. Det blir eit problem når tilstandssporing, omsetjing eller policy er avhengig av å sjå ein veg dei ikkje ser, og kvar av desse har ei anna kur. Sjekk kva mellomleddet faktisk krev før du redesignar rundt det.

Det varige svaret namngir dei to vegane, eininga som må sjå begge, og ruta som gjer det mogleg. Viss du ikkje kan namngje eininga, har du ikkje funne årsaka enno.