Zjišťování MTU cesty přes VPN: dimenzování a mezera v ICMP

Tunel dokončí handshake, malé požadavky se vrátí a první velký přenos se zasekne. Tento vzorec ukazuje na MTU cesty mnohem dřív než na propustnost. Každý spoj na trase omezuje velikost paketu a zapouzdření spotřebuje část tohoto limitu na vnější hlavičky, takže vnitřní paket musí být menší, než by naznačovala holá cesta. Selhání je tiché, a právě proto je diagnostika drahá.

Co MTU cesty skutečně měří

MTU cesty je nejmenší MTU spoje na trase mezi dvěma hostiteli, ne MTU vytištěné na vašem místním rozhraní. Místní hodnota je bod, kde odhad začíná, a cesta rozhoduje, kde musí skončit. Proto může stejný tunel fungovat v jedné přístupové síti a zaseknout se v jiné: změnila se trasa, ne konfigurace. Změřit jednou a předpokládat všude je chyba, která tento problém drží při životě.

U tunelu je důležité číslo vnitřní MTU, tedy limit vnější cesty minus vše, co spotřebuje zapouzdření. WireGuard přidává vnější IP hlavičku a hlavičku UDP; jiné transporty přidávají své vlastní. Nastavte vnitřní velikost příliš vysoko a každý paket plné velikosti bude potřebovat fragmentaci, ke které možná nikdy nedojde.

Proč tunel zmenšuje použitelný paket

Pokud rozhraní tunelu zachová MTU fyzického spoje, každý velký paket závisí na tom, zda je někdo dál po cestě ochoten ho fragmentovat. IPv4 to v zásadě umožňuje, ale router s pokynem nefragmentovat vrátí chybu. Routry IPv6 v tranzitu nikdy nefragmentují, takže stejné nastavení se chová různě podle rodiny adres. V obou případech se odesílatel nic nedozví, dokud někdo nepodá zprávu.

Praktickým důsledkem je velikost, která sedí handshaku, ale ne užitečnému zatížení. TLS ClientHello nebo dotaz DNS jsou dost malé, aby prošly zmenšenou cestou netknutě, zatímco hromadný přenos ne. Příznaky se proto shlukují kolem konkrétních operací, ne konkrétních hostitelů.

Zjišťování funguje jen tehdy, když dorazí zpětná vazba

Zjišťování IPv4 se opírá o bit zákazu fragmentace: router, který paket nemůže předat, vrátí ICMP fragmentation-needed s MTU dalšího skoku a odesílatel sníží svůj odhad. IPv6 místo toho používá zprávy Packet Too Big, protože routry v tranzitu nefragmentují. Oba mechanismy předpokládají, že zpráva najde cestu zpět k odesílateli, skrz tunel a kolem případného firewallu na zpáteční cestě. Když tento předpoklad selže, odesílatel dál zkouší velikost, kterou cesta neunese.

Firewall, který povoluje echo request a echo reply, nemusí nutně povolit tyto typy chyb. ICMP je rodina a členové, na kterých tu záleží, jsou chyby, ne dvojice echo. Zkontrolujte politiku řídicího provozu na obou koncích tunelu a na cestě mezi nimi a řiďte se podporovanými pokyny platformy místo povolení všech typů ICMP všude.

Stejné filtrování může být uvnitř tunelu. Pokud vnitřní cesta chybu zahodí, ale vnější ji nese, může se odesílatel přizpůsobit limitu, který zapouzdřený provoz ve skutečnosti nikdy nevidí.

Otestujte cestu místo hádání čísla

Držte cíl, přístupovou síť a tunel pevné a měňte jen velikost paketu. Sonda zákazu fragmentace, která selže s nápovědou MTU, vám dá limit dalšího skoku; opakujte, dokud velikost neprojde, a zaznamenejte velikost i rodinu adres.

ping -M do -s 1400 10.60.20.10
ping -M do -s 1300 10.60.20.10
ping -6 -M do -s 1300 2001:db8::10

Ping, který projde, nedokazuje, že segmenty plné velikosti skutečné aplikace projdou, takže test zopakujte s přenosem, který skutečně selhal. Porovnejte největší fungující sondu s MTU tunelu, které jste nastavili, a držte ta dvě čísla v poznámkách oddělená. Pokud se liší zhruba o jednu hlavičku, našli jste režii zapouzdření, ne závadu.

PLPMTUD popsaný v RFC 4821 posílá sondy vzhůru a používá potvrzení transportu místo spoléhání na doručené chyby. Pomáhá na cestách, které filtrují ICMP, ale podpora se liší podle zásobníku a aplikace. TCP tok se může zotavit sám, zatímco UDP aplikace s pevnou velikostí datagramu dál selhává.

Zvolte hodnotu a zaznamenejte odůvodnění

Snížení MTU tunelu je zároveň diagnostika i legitimní oprava, jakmile cestu znáte. Nenahrazuje znalost toho, která cesta a který mechanismus zpětné vazby byly zapojeny, protože hodnota vyladěná pro mobilní spoj bude na optickém připojení zbytečně malá. Zaznamenejte zvolenou velikost, sondu, která ji ospravedlnila, a krok vrácení.

Mechanismus IPv4 je popsán v RFC 1191 a pokyny k paketizaci IPv6 v RFC 8201; pojmenování obou ušetří dalšímu inženýrovi znovu odvozovat předpoklad. Pokud se přenos na vámi zvolené velikosti stále zasekává, přestaňte číslo snižovat a podívejte se na další vrstvu. Cesta, která selhává při každé velikosti, není problém MTU.