SSH pada na VPN-u svake minute? Nije kriv keepalive

SSH se poveže, radi oko minute, a zatim se svaki put zamrzne otprilike u istom intervalu. Uobičajeno objašnjenje je idle timeout, pa ljudi smanje MTU i postave klijentske keepalive. WireGuard veza na kojoj sam radio već je prošla kroz sve to: manji MTU tunela, postavke client-alive, konfiguriran keepalive tunela. Prekidi su se nastavili nepromijenjeni. Uzrok je bio asimetrična LAN ruta, a obrazac je vrijedan prepoznavanja jer pobjeđuje svako rješenje zasnovano na tajmerima.

Keepalive dokazuje da je vaš host još voljan da šalje. On ne može natjerati uređaj koji vodi stanje da vidi odgovor koji nikada ne prolazi kroz njega.

Mit: keepalive popravljaju tihi prekid

SSH keepalive postoje zbog jednog posla: da nešto što broji tišinu ne ukloni neaktivnu sesiju. To rade dobro. Ne rješavaju uređaj sa stanjem koji je vidio prvi paket u jednom smjeru i zatim nikada nije vidio odgovor, jer ništa što klijent šalje ne mijenja interfejs koji odgovor koristi.

Promjena MTU-a je drugo popularno rješenje i ima isti način neuspjeha. Smanjenje MTU-a pomaže fragmentaciji i problemima MTU-a putanje, a ruti ne čini ništa. Ako su vaši tajmeri i MTU već razumni, a prekid je i dalje u pravilnom intervalu, interval vam govori o timeoutu negdje, a ne o veličini paketa. Zapišite interval i uporedite ga sa state timeoutima na svakom uređaju na putu.

Znak je pravilnost u kombinaciji sa sesijom koja ostaje upotrebljiva unutar tog intervala. Idle timeouti udaraju kad se ništa ne događa; ovaj udara dok kucate.

Šta dodatni gateway zapravo radi

Stavite laptop i VPN gateway na isti LAN, sa odvojenim LAN firewall-om kao zadanim gatewayem. Laptop šalje VPN saobraćaj firewall-u, firewall ga prosljeđuje gatewayu, a odgovori gatewaya idu ravno natrag preko LAN-a do laptopa. Ta druga dionica nikada ne prolazi kroz firewall, pa njegova tablica stanja drži pola veze.

Adrese ispod odražavaju taj raspored:

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

Preusmjeravanja i rad sa stanjem zatim pretvaraju funkcionalan handshake u vezu koja umire kasnije, a ne odmah. Kašnjenje je starenje state zapisa ili neuspjeh strože provjere, zato interval izgleda tako mehanički.

Ništa od ovoga ne pojavljuje se u konfiguraciji klijenta, zato pretraga za tim obično počinje u pogrešnoj datoteci.

Odaberite jednu namjernu putanju

Za raspored iznad, rutiranje udaljene podmreže direktno na VPN gateway uklanja pola veze:

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

To su primjerne adrese. Sljedeći hop mora biti dostupan na vašem LAN-u, prefiks mora biti namjeravana udaljena mreža, a druga komanda vam pokazuje rezultat prije nego se na njega oslonite. Ako gateway nije na vašoj podmreži, ova ruta nije popravka koju želite.

Ako firewall treba da kontroliše saobraćaj između tih sistema, rutiranje oko njega je pogrešan dizajn. Umjesto toga natjerajte oba smjera da pređu granicu i konfigurirajte rute na svakoj strani tako da se povratna putanja poklapa. Cilj je jedna namjerna putanja, a ne manje provjere stanja.

Netgateove bilješke o asimetričnom rutiranju opisuju istu asimetriju na nivou interfejsa i state probleme koje stvara, pa ih pročitajte prije nego globalno olabavite rad sa stanjem. Vremenski prekidi slični ovom slučaju nisu dokaz sami po sebi. Tretirajte članak kao opis jednog načina neuspjeha, zatim dokažite da vaša mreža odgovara njemu prije nego promijenite globalnu state politiku.

Testirajte sa oba kraja

Pročitajte rutu laptopa prema odredištu i rutu odredišta natrag prema laptopu; to su dvije odvojene odluke i vjerovatno je samo jedna od njih pogrešna. Ping koji uspije sa samog gatewaya može potpuno sakriti problem, jer potiče sa mašine čija je putanja već ispravna. Potrebni su vam oba smjera onako kako ih vide dva kraja stvarne sesije.

Nakon popravke ponovo otvorite SSH i držite sesiju otvorenom znatno duže od intervala koji je prije padao. Zatim učinite rutu trajnom u odobrenoj mrežnoj konfiguraciji, jer jednokratna komanda nije plan za restart i problem će se vratiti pri sljedećem restartu sa novom misterijom.

Kada je asimetrija u redu

Asimetrično rutiranje je normalno u mnogim mrežama i nije pokvareno po definiciji. Ono postaje problem kada praćenje stanja, prevođenje ili politika zavise od viđenja putanje koju ne vide, a svako od toga ima drugačiji lijek. Provjerite šta srednji uređaj zapravo zahtijeva prije nego redizajnirate oko njega.

Trajan odgovor imenuje dvije putanje, uređaj koji mora vidjeti obje i rutu koja to omogućava. Ako ne možete imenovati uređaj, još niste našli uzrok.