SSH vsako minuto pade na VPN? Ni kriv keepalive

SSH se poveže, deluje približno minuto in nato vsakič zamrzne v približno enakem intervalu. Običajna razlaga je idle timeout, zato ljudje znižajo MTU in nastavijo odjemalske keepalive. Povezava WireGuard, na kateri sem delal, je vse to že prestala: manjši MTU tunela, nastavitve client-alive, konfiguriran keepalive tunela. Prekinitve so se nadaljevale nespremenjeno. Vzrok je bila asimetrična pot LAN, in ta vzorec je vreden prepoznave, ker premaga vsako popravilo, ki temelji na časovnikih.

Keepalive dokazuje, da je vaš gostitelj še vedno pripravljen pošiljati. Ne more prisiliti naprave, ki vodi stanje, da vidi odgovor, ki nikoli ne gre skozi njo.

Mit: keepalive popravijo tiho prekinitev

Keepalive SSH obstajajo za eno nalogo: preprečiti nečemu, kar šteje tišino, da odstrani nedejavno sejo. To dobro opravijo. Ne rešujejo naprave z vodenim stanjem, ki je videla prvi paket v eno smer in nato nikoli ni videla odgovora, ker nič, kar pošlje odjemalec, ne spremeni, kateri vmesnik uporablja odgovor.

Sprememba MTU je drugo priljubljeno popravilo in ima enak način odpovedi. Znižanje MTU pomaga pri fragmentaciji in težavah s MTU poti, na pot pa ne vpliva. Če so vaši časovniki in MTU že razumni, prekinitev pa je še vedno v ponavljajočem se intervalu, vam interval govori o časovni omejitvi nekje, ne o velikosti paketa. Zapišite interval in ga primerjajte s časovnimi omejitvami stanja na vsaki napravi na poti.

Znak je pravilnost skupaj s sejo, ki ostane uporabna znotraj tega intervala. Idle timeouti udarijo, ko se nič ne zgodi; ta udari, ko tipkate.

Kaj dodatni prehod dejansko počne

Postavite prenosnik in prehod VPN v isti LAN, z ločenim požarnim zidom LAN kot privzetim prehodom. Prenosnik pošlje promet proti VPN požarnemu zidu, požarni zid ga posreduje prehodu, in odgovori prehoda se vrnejo naravnost po LAN do prenosnika. Ta drugi krak nikoli ne gre skozi požarni zid, zato njegova tabela stanja drži polovico povezave.

Spodnji naslovi odražajo to postavitev:

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

Preusmeritve in ravnanje s stanjem nato spremenijo delujoč rokovanje v povezavo, ki umre pozneje, ne takoj. Zamuda je staranje vnosa stanja ali neuspeh strožjega preverjanja, zato je interval videti tako mehanski.

Nič od tega se ne pojavi v konfiguraciji odjemalca, zato se iskanje zanj običajno začne v napačni datoteki.

Izberite eno namerno pot

Za zgornjo postavitev usmerjanje oddaljenega podomrežja neposredno na prehod VPN odpravi polovico povezave:

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

To so primerjalni naslovi. Naslednji skok mora biti dosegljiv v vašem LAN, predpona mora biti predvideno oddaljeno omrežje, in drugi ukaz vam pokaže rezultat, preden se nanj zanesete. Če prehod ni v vašem podomrežju, ta pot ni popravek, ki ga želite.

Če naj požarni zid nadzoruje promet med temi sistemi, je usmerjanje okoli njega napačen načrt. Namesto tega pustite obema smerema skozi mejo in konfigurirajte poti na vsaki strani tako, da se povratna pot ujema. Cilj je ena namerna pot, ne manj preverjanja stanja.

opombe o asimetričnem usmerjanju podjetja Netgate opisujejo isto asimetrijo na ravni vmesnika in težave s stanjem, ki jih ustvarja, zato jih preberite, preden globalno sprostite ravnanje s stanjem. Časovno omejene prekinitve, podobne temu primeru, same po sebi niso dokaz. Obravnavajte članek kot opis enega načina odpovedi, nato dokažite, da vaše omrežje ustreza njemu, preden spremenite globalno politiko stanja.

Preizkusite z obeh koncev

Preberite pot prenosnika proti cilju in pot cilja nazaj proti prenosniku; to sta dve ločeni odločitvi in verjetno je napačna le ena od njih. Ping, ki uspe s prehoda samega, lahko težavo popolnoma skrije, ker izvira s stroja, katerega pot je že pravilna. Potrebujete obe smeri, kot ju vidita oba konca dejanske seje.

Po popravilu znova odprite SSH in držite sejo odprto precej dlje od intervala, ki je prej odpovedal. Nato naredite pot trajno v odobreni omrežni konfiguraciji, ker enkratni ukaz ni načrt za ponovni zagon in težava se bo vrnila ob naslednjem zagonu z novo uganko.

Kdaj je asimetrija v redu

Asimetrično usmerjanje je v mnogih omrežjih normalno in po definiciji ni pokvarjeno. Postane težava, ko so sledenje stanju, prevajanje ali politika odvisni od videnja poti, ki je ne vidijo, in vsak od tega ima drugo zdravilo. Preverite, kaj vmesna naprava dejansko zahteva, preden načrtujete okoli nje.

Trajen odgovor poimenuje obe poti, napravo, ki mora videti obe, in pot, ki to omogoča. Če naprave ne morete poimenovati, vzroka še niste našli.