SSH falt op 'e VPN eltse minút út? It is net de keepalive

In sesje dy't mei in werheljend ynterval stjert, ferliest meastentiids firewall-steat, net keepalives. Folgje beide rjochtingen foardat jo MTU of timers oanreitsje.

SSH ferbynt, wurket sawat in minút en befriest dan elke kear yn likernôch itselde ynterval. De gewoane ferklearring is in idle-timeout, dus minsken ferleegje de MTU en sette keepalives op 'e klant. In WireGuard-ferbining dêr't ik oan wurke hie dat allegear al trochmakke: in lytsere tunnel-MTU, client-alive-ynstellings, in konfigurearre tunnel-keepalive. De ûnderbrekkings bleaune ûnferoare. De oarsaak die bliken in asymmetryske LAN-route te wêzen, en it patroan is de muoite wurdich te herkennen, want it ferslacht elke timer-basearre oplossing.

In keepalive bewiist dat jo host noch stjoere wol. It kin in steat-hâldend apparaat gjin antwurd sjen litte dat der nea trochhinne giet.

De myte: keepalives meitsje in stille ûnderbrekking goed

SSH-keepalives besteane foar ien taak: foarkomme dat eat dat stilte telt in ydle sesje oprommet. Dat dogge se goed. Se lossen gjin steat-hâldend apparaat op dat it earste pakket yn ien rjochting seach en doe nea it antwurd seach, want neat dat de klant stjoert feroaret hokker ynterface it antwurd brûkt.

In MTU-wiziging is de oare populêre oplossing, en dy hat deselde flatermodus. It ferleegjen fan de MTU helpt by fragmintaasje en paad-MTU-problemen, en it docht neat oan in route. As jo timers en MTU al ridlik binne en de ûnderbrekking is noch hieltyd yn in werheljend ynterval, dan fertelt it ynterval jo oer in timeout earne, net oer pakketgrutte. Skriuw it ynterval op en fergelykje it mei de steat-timeouts op elk apparaat yn it paad.

It teken is regelmjittigens tegearre mei in sesje dy't binnen dat ynterval brûkber bliuwt. Ydle-timeouts slane ta as der neat bart; dizze slacht ta wylst jo type.

Wat de ekstra gateway eins docht

Set de laptop en de VPN-gateway op itselde LAN, mei in aparte LAN-firewall as de standertgateway. De laptop stjoert VPN-ferkear nei de firewall, de firewall stjoert it troch nei de gateway, en de antwurden fan 'e gateway geane direkt werom oer it LAN nei de laptop. Dat twadde skonk giet nea troch de firewall, dus syn steattabel hâldt in heale ferbining.

De adressen hjirûnder wjerspegelje dy 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

Trochstjoeringen en steatbehear meitsje dan fan in wurkjende handshake in ferbining dy't letter stjert ynstee fan daliks. De fertraging is de steatynfiering dy't ferâldet of in strangere kontrôle dy't mislearret, en dêrom liket it ynterval sa meganysk.

Neat hjirfan ferskynt yn 'e klantkonfiguraasje, en dêrom begjint it sykjen dêrnei meastentiids yn it ferkearde bestân.

Kies ien bewuste paad

Foar de opstelling hjirboppe hellet it rûtearjen fan it ôfstienne subnet direkt nei de VPN-gateway de heale ferbining fuort:

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

Dat binne foarbyldadressen. De folgjende hop moat berikber wêze op jo LAN, it foarheaksel moat it bedoelde ôfstienne netwurk wêze, en it twadde kommando lit jo it resultaat sjen foardat jo dêrop fertrouwe. As de gateway net op jo subnet is, is dizze route net de oplossing dy't jo wolle.

As de firewall bedoeld is om ferkear tusken dy systemen te kontrolearjen, dan is rûtearjen deromhinne in ferkeard ûntwerp. Lit beide rjochtingen ynstee de grins oerstekke en konfigurearje de routes oan elke kant sadat it werompaad oerienkomt. It doel is ien bewuste paad, net minder steatkontrôle.

Netgate syn notysjes oer asymmetrysk rûtearjen beskriuwe deselde asymmetry op ynterfacenivo en de steatproblemen dy't it makket, dus lês se foardat jo steatbehear globaal fersoepelje. Tydbûne ferbrekkings lykas dit gefal binne op harsels gjin bewiis. Behandel it artikel as in beskriuwing fan ien flatermodus, en bewiis dan dat jo eigen netwurk dêrop past foardat jo it globale steatbelied feroarje.

Test it fan beide kanten

Lês de route fan 'e laptop nei de bestemming en de route fan 'e bestemming werom nei de laptop; it binne twa aparte besluten en wierskynlik is mar ien fan beide ferkeard. In ping dy't fan 'e gateway sels slagget, kin it probleem hielendal ferbergje, want dy ûntstiet op 'e masine waans paad al goed is. Jo hawwe beide rjochtingen nedich sa't de twa einen fan 'e echte sesje se sjogge.

Iepenje nei de oplossing SSH wer en hâld de sesje iepen fier foarby it ynterval dat earder mislearre. Meitsje de route dan permanint yn 'e goedkarde netwurkkonfiguraasje, want in ienmalige opdracht is gjin herstartplan en it probleem sil by de folgjende herstart weromkomme mei in nij mystearje.

Wannear't asymmetry goed is

Asymmetrysk rûtearjen is normaal yn in protte netwurken en is neffens de definysje net stikken. It wurdt in probleem as steatfolging, oersetting of belied ôfhinklik is fan it sjen fan in paad dat se net sjogge, en elk dêrfan hat in oare remedie. Kontrolearje wat it middenapparaat eins fereasket foardat jo deromhinne opnij ûntwerpe.

It duorsume antwurd neamt de twa paden, it apparaat dat beide sjen moat, en de route dy't dat mooglik makket. As jo it apparaat net neame kinne, hawwe jo de oarsaak noch net fûn.

Relatearre artikelen