SSH rompiĝas en la VPN ĉiun minuton? Ne la keepalive kulpas

SSH konektiĝas, funkcias proksimume minuton, poste frostas je proksimume la sama intervalo ĉiufoje. La kutima klarigo estas senokupa tempolimo, do homoj malaltigas la MTU kaj agordas klientajn keepalive. La WireGuard-ligo, ĉe kiu mi laboris, jam estis trapasinta ĉion ĉi: pli malgrandan tunelan MTU, agordojn client-alive, agorditan tunelan keepalive. La interrompoj daŭris senŝanĝe. La kaŭzo montriĝis asimetria LAN-itinero, kaj la ŝablono indas rekoni, ĉar ĝi venkas ĉiun tempoŝaltilan riparon.

Keepalive pruvas, ke via gastiganto ankoraŭ pretas sendi. Ĝi ne povas igi statokonservan aparaton vidi respondon, kiu neniam trapasas ĝin.

La mito: keepalive riparas silentan interrompon

SSH-keepalive ekzistas por unu tasko: malhelpi, ke io, kio kalkulas silenton, forigu senokupan sesion. Tion ili bone faras. Ili ne solvas aparaton kun stato, kiu vidis la unuan paketon en unu direkto kaj poste neniam vidis la respondon, ĉar nenio, kion la kliento sendas, ŝanĝas kiun interfacon la respondo uzas.

MTU-ŝanĝo estas la alia populara ripeto, kaj ĝi havas la saman fiaskmanieron. Malaltigi la MTU helpas fragmentadon kaj vojan MTU-problemojn, kaj ĝi faras nenion al itinero. Se viaj tempoŝaltiloj kaj MTU jam estas prudentaj kaj la interrompo ankoraŭ okazas je ripetiĝanta intervalo, la intervalo parolas al vi pri tempolimo ie, ne pri paketgrandeco. Notu la intervalon kaj komparu ĝin kun la statotempolimoj sur ĉiu aparato en la vojo.

La signo estas reguleco kune kun sesio, kiu restas uzebla ene de tiu intervalo. Senokupaj tempolimoj frapas, kiam nenio okazas; ĉi tiu frapas dum vi tajpas.

Kion la plia enirejo efektive faras

Metu la tekkomputilon kaj la VPN-enirejon en la saman LAN, kun aparta LAN-fajroŝirmilo kiel la defaŭlta enirejo. La tekkomputilo sendas VPN-celan trafikon al la fajroŝirmilo, la fajroŝirmilo plusendas ĝin al la enirejo, kaj la respondoj de la enirejo reiras rekte trans la LAN al la tekkomputilo. Tiu dua kruro neniam trapasas la fajroŝirmilon, do ĝia stata tabelo tenas duonan konekton.

La adresoj sube spegulas tiun aranĝon:

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

Alidirektadoj kaj stata pritraktado tiam transformas funkciantan manpremon en konekton, kiu mortas poste anstataŭ tuj. La prokrasto estas la stateniro maljuniĝanta aŭ pli strikta kontrolo fiaskanta, kaj tial la intervalo aspektas tiel mekanika.

Nenio el tio aperas en la klienta agordo, kaj tial la serĉado pri ĝi kutime komenciĝas en la malĝusta dosiero.

Elektu unu intencan vojon

Por la aranĝo supre, enkursigado de la fora subreto rekte al la VPN-enirejo forigas la duonan konekton:

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

Tiuj estas ekzemplaj adresoj. La sekva saltado devas esti atingebla en via LAN, la prefikso devas esti la celata fora reto, kaj la dua komando montras al vi la rezulton antaŭ ol vi fidas ĝin. Se la enirejo ne estas en via subreto, ĉi tiu itinero ne estas la riparo, kiun vi volas.

Se la fajroŝirmilo celas kontroli trafikon inter tiuj sistemoj, enkursigado ĉirkaŭ ĝi estas malĝusta dezajno. Anstataŭe igi ambaŭ direktojn trapasi la limon, kaj agordu la itinerojn ĉe ĉiu flanko tiel, ke la reena vojo kongruu. La celo estas unu intenca vojo, ne malpli da stata kontrolado.

La notoj pri asimetria enkursigado de Netgate priskribas la saman asimetrion je interfaca nivelo kaj la statproblemojn, kiujn ĝi kreas, do legu ilin antaŭ ol malstreĉi statan pritraktadon tutmonde. Tempigitaj malkonektoj similaj al ĉi tiu kazo ne estas pruvo memstare. Traktu la artikolon kiel priskribon de unu fiaskmaniero, poste pruvu, ke via propra reto kongruas kun ĝi, antaŭ ol ŝanĝi tutmondan statan politikon.

Testu ĝin de ambaŭ finoj

Legu la itineron de la tekkomputilo al la celo kaj la itineron de la celo reen al la tekkomputilo; temas pri du apartaj decidoj kaj verŝajne nur unu el ili estas malĝusta. Ping, kiu sukcesas de la enirejo mem, povas kaŝi la problemon tute, ĉar ĝi originas sur la maŝino, kies vojo jam estas ĝusta. Vi bezonas ambaŭ direktojn tiel, kiel vidas ilin la du finoj de la reala sesio.

Post la riparo, remalfermu SSH kaj tenu la sesion malferma longe preter la intervalo, kiu antaŭe fiaskis. Poste faru la itineron daŭra en la aprobita reta agordo, ĉar unufoja komando ne estas restartplano kaj la problemo revenos ĉe la sekva restarto kun nova mistero.

Kiam asimetrio estas en ordo

Asimetria enkursigado estas normala en multaj retoj kaj ne estas rompita laŭdifine. Ĝi fariĝas problemo, kiam stata postspurado, tradukado aŭ politiko dependas de vidi vojon, kiun ili ne vidas, kaj ĉiu el tiuj havas malsaman rimedon. Kontrolu, kion la meza aparato efektive postulas, antaŭ ol redesegni ĉirkaŭ ĝi.

La daŭra respondo nomas la du vojojn, la aparaton, kiu devas vidi ambaŭ, kaj la itineron, kiu ebligas tion. Se vi ne povas nomi la aparaton, vi ankoraŭ ne trovis la kaŭzon.