VPN sa pripojí, chvíľu funguje a potom prestane prepúšťať prevádzku, kým klient stále zobrazuje reláciu. Opätovné pripojenie to opraví, preto to vyzerá ako chyba klienta. Zvyčajne ide o firewall alebo zariadenie NAT, ktoré zahodilo neaktívne UDP mapovanie a nemá poňatia, že tunel ešte existuje.

Príznak je dostatočne konzistentný na diagnostiku: objavuje sa po nečinnosti, nie pod záťažou.

Ako vyzerá zaseknutie pri nečinnosti

Zmerajte to, namiesto toho, aby ste to opisovali. Zapíšte, ako dlho tunel stojí nečinne, kým prevádzka ustane, či ho nový odchádzajúci paket oživí a či si klientske rozhranie stále drží svoju adresu. Ak nová požiadavka z klienta funguje, ale odpoveď na existujúci tok nie, podozrivé je mapovanie. Ak nič nefunguje, kým sa znova nepripojíte, je stratený aj stav relácie v klientovi.

Oba prípady súvisia s nečinnosťou a potrebujú rôzne opravy.

Zapíšte si časy, skôr než čokoľvek zmeníte. Hlásenie, že sa to zastaví po približne desiatich minútach nečinnosti, je overiteľné, kým hlásenie, že to padá náhodne, overiteľné nie je. Tento rozdiel rozhoduje, či naháňate časovač alebo zmenu smerovania.

Nájdite zariadenie, ktoré zabudlo

Stav pre ten istý tok môže držať niekoľko zariadení: miestny router, prekladač vyššie v ceste, hranica cloudu a firewall hostiteľa. Každé má vlastný časovač a vyhráva najkratší. Päťminútový výpadok zvyčajne znamená, že jedno zariadenie je nastavené výrazne nižšie ako ostatné.

Nepredpokladajte, že dokumentovaná predvolená hodnota je časový limit na vašej ceste. Je to predvolená hodnota jedného zariadenia.

  • Domáci router: často minúty, niekedy oveľa menej.
  • Cloudový NAT alebo vyrovnávač záťaže: vyhľadajte dokumentovaný časový limit nečinnosti konkrétne pre UDP.
  • Firewall hostiteľa: časovače sledovania netfilter platia pre každý tok.

Skontrolujte časovače na skutočnej ceste

V Linuxe sú časovače sledovania netfilter viditeľné a nastaviteľné: sysctl net.netfilter.nf_conntrack_udp_timeout a net.netfilter.nf_conntrack_udp_timeout_stream. Druhý platí, keď bola prevádzka videná v oboch smeroch, a preto zavedený tunel môže prežiť obyčajnú sondu.

RFC 4787 opisuje správanie UDP NAT a odporúčané minimá. Je to referencia, ktorú treba citovať, keď predvolená hodnota dodávateľa vyzerá nezvyčajne krátka.

Keepalive a opätovné pripojenie sú rôzne nástroje

Keepalive udržiava mapovanie živé; opätovné pripojenie znovu stavia mŕtvu reláciu. Riešia rôzne poruchy a nie sú zameniteľné nastavenia rýchlosti. Nastavenie PersistentKeepalive vo WireGuarde posiela paket v pevnom intervale, aby udržalo väzbu NAT otvorenú. Voľba keepalive v OpenVPN robí rovnakú prácu po svojom. Ani jedno nepomôže, ak zariadenie v strede už tok zabudlo a zahadzuje oba smery.

Veľmi časté sondy pridávajú prácu bez opravy nesprávnej hranice.

Overujte novou požiadavkou, nie obnovením stránky

Po zmene časovača alebo pridaní keepalive zopakujte scenár nečinnosti presne ako predtým. Potom z pokrytej aplikácie pošlite skutočne novú požiadavku. Karta prehliadača, ktorá už bola načítaná, sa môže vykresliť z vyrovnávacej pamäte a nič vám nepovie.

Ak zaseknutie pretrváva, posuňte sa o jeden skok von a skontrolujte tabuľku stavov daného zariadenia.

Súvisiace články