SSH visí přes OpenVPN? Nejprve změřte MTU cesty

SSH se připojí, objeví se prompt a relace umře, jakmile příkaz vrátí něco objemného. Echo ještě chvíli funguje, pak spojení vyprší, zatímco klient stále ukazuje tunel jako nahoru. Relace, která je zdravá až do příchodu dat, obvykle naráží na limit velikosti, ne na vadu SSH. Níže uvedené kontroly jsou seřazeny tak, aby se nejlevnější vysvětlení vyloučilo jako první.

Přečtěte si tvar poruchy, než sáhnete na profil

Malé pakety projdou, plné ne. Prompt, banner nebo jedno stisknutí klávesy se vejdou snadno; výpis adresáře, stahování nebo vložený blok ne. Velikost, při které se chování změní, je stopa, ne fakt, že je to zrovna SSH.

Mechanismus je objevování MTU cesty, které závisí na zpětné vazbě. TCP zvolí velikost segmentu, a když router na cestě nemůže výsledný paket přeposlat, měl by to oznámit zprávou ICMP. Zapouzdření dělá vnější paket větším než vnitřní, takže použitelná velikost uvnitř tunelu je vždy pod fyzickým spojem. Vyfiltrujte ty zprávy ICMP kdekoli a odesílatel nikdy nedostane opravu, posílá dál plné segmenty a vnější paket se zahodí bez upozornění.

Změřte strop z obou stran

Porovnejte MTU tunelu s fyzickým spojem, než změníte kterékoli z nich. Tunel, který zkopíroval fyzickou hodnotu, už vám řekl, kde nesoulad je.

Změřte zevnitř tunelu požadavkem bez fragmentace a snižujte užitečné zatížení, dokud se nevrátí odpovědi. Argument velikosti počítá jen užitečné zatížení, takže funkční číslo je vždy pod MTU rozhraní. Připočtěte zpět velikosti hlaviček, pokud potřebujete číslo rozhraní.

ip link show tun0
ping -M do -s 1380 10.9.0.1

Zopakujte měření proti veřejné adrese serveru zvenku tunelu. Pokud velké sondy selžou i tam, limit sedí na cestě k serveru a žádná volba tunelu s ním nepohne. To srovnání vás ušetří ladění klienta, který nikdy nebyl problém. Zapište oba výsledky, než otevřete konfigurační soubor.

mssfix a fragment dělají různou práci

mssfix omezuje velikost segmentu, kterou TCP spojení uvnitř tunelu inzerují během navazování. Je to správná páka pro SSH, HTTPS a kopírování souborů, proto zaseknutí často zmizí, jakmile se nastaví. UDP užitečného zatížení se vůbec nedotýká.

Tunel, který nese i službu UDP, může po opravě SSH selhávat dál, a ten výsledek mate každého, kdo předpokládá, že jedna volba pokryje všechno.

fragment je jiný mechanismus a jiný nástroj. Rozděluje příliš velké pakety před zapouzdřením, platí jen pro transport UDP, přidává režii na datagram a je dokumentován jako poslední možnost pro rozbité objevování. Obě nastavení se musí shodovat u protějšků, které tunel ukončují. Když jeden konec omezuje a druhý fragmentuje, vznikají varování v logu a chování, které z těch souborů nikdo neodhadne.

Snížení MTU rozhraní je hrubá varianta

Snížit MTU rozhraní na obou koncích je hrubý nástroj. Řekne každému vnitřnímu odesílateli menší číslo, což funguje, a tu cenu naúčtuje veškerému provozu místo TCP tokům, které ji potřebují.

Zvolte ho, když tunel nese provoz, který nemůžete omezit, nebo když je klient zařízení, jehož profil neovládáte. Použijte ho symetricky a zapište hodnotu vedle profilu. Napůl provedená změna je horší než žádná, protože vypadá jako oprava.

Otestujte znovu s přenosem, který se zasekl

Připojte se znovu, aby se nastavení načetlo, otevřete nové spojení a zopakujte příkaz, který zamrzl. Velikost segmentu se vyjednává při navazování, takže relace, která přežila opětovné připojení, stále nese starou hodnotu. Ping je tu špatný test, protože celá porucha spočívá v tom, že malé pakety projdou. Použijte ten výpis, stahování nebo vložení, které se rozbilo.

Pokud zaseknutí přetrvá při menší velikosti, hledejte jinde: stavový firewall, který tok ukončí, duplicitní adresa nebo trasa, která se při opětovném připojení posune. Zapište velikost sondy, která selhala, a nastavení, které jste změnili, protože právě ta dvojice dělá další hlášení užitečným.