SSH padá na VPN každú minútu? Príčina nie je keepalive

SSH sa pripojí, funguje asi minútu a potom zakaždým zamrzne približne v rovnakom intervale. Bežné vysvetlenie je idle timeout, takže ľudia znížia MTU a nastavia klientske keepalivy. WireGuard spoj, na ktorom som pracoval, už tým všetkým prešiel: menšie MTU tunela, nastavenia client-alive, nakonfigurovaný keepalive tunela. Výpadky pokračovali bez zmeny. Príčinou bola asymetrická LAN trasa a ten vzor stojí za rozpoznanie, pretože poráža každú opravu založenú na časovačoch.

Keepalive dokazuje, že váš hostiteľ je stále ochotný odosielať. Nemôže prinútiť zariadenie, ktoré vedie stav, aby videlo odpoveď, ktorá cez neho nikdy neprejde.

Mýtus: keepalivy opravujú tichý výpadok

Keepalivy SSH existujú pre jednu úlohu: zabrániť niečomu, čo počíta ticho, aby odstránilo neaktívnu reláciu. To robia dobre. Neriešia zariadenie s vedeným stavom, ktoré videlo prvý paket v jednom smere a potom už nikdy nevidelo odpoveď, pretože nič z toho, čo klient posiela, nemení rozhranie, ktoré odpoveď používa.

Zmena MTU je druhá obľúbená oprava a má rovnaký spôsob zlyhania. Zníženie MTU pomáha fragmentácii a problémom s MTU cesty a trase nerobí nič. Ak sú vaše časovače a MTU už rozumné a výpadok je stále v opakujúcom sa intervale, interval vám hovorí o timeoute niekde inde, nie o veľkosti paketu. Zapíšte interval a porovnajte ho so stavovými timeoutmi na každom zariadení na ceste.

Príznakom je pravidelnosť spojená s reláciou, ktorá zostáva v tom intervale použiteľná. Idle timeouts udierajú, keď sa nič nedeje; tento udiera, keď píšete.

Čo vlastne robí ďalšia brána

Umiestnite notebook a VPN bránu do rovnakej LAN, so samostatným LAN firewallom ako predvolenou bránou. Notebook posiela prevádzku smerujúcu do VPN firewallu, firewall ju preposiela bráne a odpovede brány idú priamo späť cez LAN k notebooku. Tá druhá noha nikdy neprejde firewallom, takže jeho stavová tabuľka drží polovicu spojenia.

Adresy nižšie zodpovedajú tomuto usporiadaniu:

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

Presmerovania a práca so stavom potom premenia fungujúci handshake na spojenie, ktoré umiera neskôr, nie hneď. Oneskorenie je starnutie stavového záznamu alebo zlyhanie prísnejšej kontroly, a preto interval vyzerá tak mechanicky.

Nič z toho sa v konfigurácii klienta neobjavuje, a preto hľadanie zvyčajne začína v nesprávnom súbore.

Vyberte si jednu zámernú cestu

Pre usporiadanie vyššie odstráni smerovanie vzdialenej podsiete priamo na VPN bránu polovicu spojenia:

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

To sú ukážkové adresy. Ďalší skok musí byť dostupný vo vašej LAN, prefix musí byť zamýšľaná vzdialená sieť a druhý príkaz vám ukáže výsledok, skôr než sa naň spoľahnete. Ak brána nie je vo vašej podsieti, táto trasa nie je oprava, ktorú chcete.

Ak má firewall strážiť prevádzku medzi tými systémami, smerovanie okolo neho je nesprávny návrh. Namiesto toho nechajte oba smery prejsť hranicou a nakonfigurujte trasy na každej strane tak, aby sa spätná cesta zhodovala. Cieľom je jediná zámerná cesta, nie menej kontroly stavu.

poznámky k asymetrickému smerovaniu od Netgate opisujú rovnakú asymetriu na úrovni rozhrania a stavové problémy, ktoré vytvára, takže si ich prečítajte, skôr než celkovo uvoľníte prácu so stavom. Časované výpadky podobné tomuto prípadu nie sú samy o sebe dôkazom. Berte článok ako opis jedného spôsobu zlyhania a potom dokážte, že vaša sieť mu zodpovedá, skôr než zmeníte globálnu stavovú politiku.

Otestujte to z oboch koncov

Prečítajte si trasu notebooku k cieľu a trasu cieľa späť k notebooku; sú to dve samostatné rozhodnutia a pravdepodobne len jedno z nich je nesprávne. Ping, ktorý uspeje z brány samotnej, môže problém úplne skryť, pretože vychádza zo stroja, ktorého cesta je už správna. Potrebujete oba smery tak, ako ich vidia dva konce skutočnej relácie.

Po oprave znova otvorte SSH a držte reláciu otvorenú výrazne dlhšie než interval, ktorý predtým zlyhával. Potom urobte trasu trvalou v schválenej sieťovej konfigurácii, pretože jednorazový príkaz nie je plán reštartu a problém sa vráti pri ďalšom reštarte s novou záhadou.

Kedy je asymetria v poriadku

Asymetrické smerovanie je v mnohých sieťach normálne a nie je podľa definície pokazené. Problémom sa stane, keď sledovanie stavu, preklad alebo politika závisia od videnia cesty, ktorú nevidia, a každé z toho má inú nápravu. Skontrolujte, čo prostredné zariadenie skutočne vyžaduje, skôr než okolo neho budete redizajnovať.

Trvalá odpoveď pomenuje obe cesty, zariadenie, ktoré musí vidieť obe, a trasu, ktorá to umožňuje. Ak nedokážete zariadenie pomenovať, ešte ste príčinu nenašli.