SSH padá na VPN každou minutu? Příčina není keepalive

SSH se připojí, funguje asi minutu a pak vždy zamrzne přibližně ve stejném intervalu. Běžné vysvětlení je idle timeout, takže lidé sníží MTU a nastaví klientské keepalivy. WireGuard spoj, na kterém jsem pracoval, už tím vším prošel: menší MTU tunelu, nastavení client-alive, nakonfigurovaný keepalive tunelu. Výpadky pokračovaly beze změny. Příčinou byla asymetrická LAN trasa a ten vzorec stojí za rozpoznání, protože poráží každou opravu založenou na časovačích.

Keepalive dokazuje, že váš hostitel je stále ochoten odesílat. Nemůže přimět zařízení, které vede stav, aby vidělo odpověď, jež přes něj nikdy neprojde.

Mýtus: keepalivy opravují tichý výpadek

Keepalivy SSH existují kvůli jedné věci: aby něco, co počítá ticho, neuklidilo neaktivní relaci. To dělají dobře. Neřeší zařízení se stavem, které vidělo první paket v jednom směru a pak už nikdy nevidělo odpověď, protože nic, co klient posílá, nemění rozhraní, které odpověď používá.

Změna MTU je druhá oblíbená oprava a má stejný způsob selhání. Snížení MTU pomáhá fragmentaci a problémům s MTU cesty a trase neudělá nic. Pokud jsou vaše časovače a MTU už rozumné a výpadek je stále v opakujícím se intervalu, interval vám říká o timeoutu někde jinde, ne o velikosti paketů. Zapište interval a porovnejte ho se stavovými timeauty na každém zařízení na cestě.

Příznakem je pravidelnost spojená s relací, která zůstává v tom intervalu použitelná. Idle timeauty udeří, když se nic neděje; tento udeří, když píšete.

Co vlastně dělá další brána

Umístěte notebook a VPN bránu do stejné LAN, se samostatným LAN firewallem jako výchozí bránou. Notebook posílá provoz směřující do VPN firewallu, firewall ho předává bráně a odpovědi brány jdou přímo zpět přes LAN k notebooku. Ta druhá noha nikdy neprojde firewallem, takže jeho stavová tabulka drží polovinu spojení.

Adresy níže odpovídají tomuto uspořádání:

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

Přesměrování a práce se stavem pak promění fungující handshake ve spojení, které umírá později, ne hned. Zpoždění je stárnutí stavového záznamu nebo selhání přísnější kontroly, a proto interval vypadá tak mechanicky.

Nic z toho se v konfiguraci klienta neobjevuje, a proto hledání obvykle začíná ve špatném souboru.

Vyberte si jednu záměrnou cestu

Pro uspořádání výše odstraní směrování vzdálené podsítě přímo na VPN bránu polovinu spojení:

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

To jsou ukázkové adresy. Další skok musí být dostupný ve vaší LAN, prefix musí být zamýšlená vzdálená síť a druhý příkaz vám ukáže výsledek, než se na něj spolehnete. Pokud brána není ve vaší podsíti, tahle trasa není oprava, kterou chcete.

Pokud má firewall hlídat provoz mezi těmito systémy, směrování kolem něj je špatný návrh. Nechte oba směry projít hranicí a nakonfigurujte trasy na každé straně tak, aby se zpětná cesta shodovala. Cílem je jediná záměrná cesta, ne méně kontrol stavu.

poznámky k asymetrickému směrování od Netgate popisují stejnou asymetrii na úrovni rozhraní a stavové problémy, které vytváří, takže si je přečtěte, než celkově uvolníte práci se stavem. Časované výpadky podobné tomuto případu nejsou samy o sobě důkazem. Berte článek jako popis jednoho způsobu selhání a pak dokažte, že vaše síť mu odpovídá, než změníte globální stavovou politiku.

Otestujte to z obou konců

Přečtěte si trasu notebooku k cíli a trasu cíle zpět k notebooku; jsou to dvě samostatná rozhodnutí a pravděpodobně jen jedno z nich je špatné. Ping, který uspěje z brány samotné, může problém zcela skrýt, protože vychází ze stroje, jehož cesta je už správná. Potřebujete oba směry tak, jak je vidí dva konce skutečné relace.

Po opravě znovu otevřete SSH a držte relaci otevřenou výrazně déle než interval, který dřív selhával. Pak udělejte trasu trvalou ve schválené síťové konfiguraci, protože jednorázový příkaz není plán restartu a problém se vrátí při dalším restartu s novou záhadou.

Kdy je asymetrie v pořádku

Asymetrické směrování je v mnoha sítích normální a není podle definice rozbité. Problémem se stane, když sledování stavu, překlad nebo politika závisí na vidění cesty, kterou nevidí, a každé z toho má jinou nápravu. Zkontrolujte, co prostřední zařízení skutečně vyžaduje, než kolem něj budete redesignovat.

Trvalá odpověď pojmenuje obě cesty, zařízení, které musí vidět obě, a trasu, která to umožňuje. Pokud nedokážete zařízení pojmenovat, ještě jste příčinu nenašli.