Mýty o MTU u VPN: proč se vaše pakety zmenšují a kam se podívá místo

Někdo vám řekne, že VPN "ztrácí pakety kvůli MTU", vy nastavíte tunel na 1400 a přenos zase funguje. Takový výsledek vypadá jako diagnóza. Obvykle je to náhoda v aritmetice: vybrali jste číslo dost malé, aby se vešlo pod limit, který jste nikdy neidentifikovali, a stejný limit potkáte znovu na další síti s jiným rozpočtem.

Většinu toho způsobují dva mýty. První je, že MTU rozhraní tunelu je MTU cesty. Druhý je, že zapouzdření stojí "jednu hlavičku" a PPPoE nestojí nic, co by stálo za počítání. Oba jsou špatné tak, že zvolené číslo vypadá svévolné, i když je ve skutečnosti určené.

Mýtus první: MTU tunelu je MTU cesty

Hodnota, kterou nastavíte na rozhraní tunelu, je místní slib o největším vnitřním paketu, který implementace předá dolů. Skutečná kapacita cesty je vlastnost každého spoje mezi vámi a vzdáleným koncem a může se změnit, když se změní trasa, když mobilní spojení předá spojení jiné síti nebo když provoz půjde jiným peeringem. Nastavených 1500 říká, co sestaví váš hostitel, ne co síť přenese.

Zjišťování MTU cesty existuje, aby tyto dvě věci sladilo, a závisí na zpětné vazbě. U IPv4 má router, který nemůže předat paket plné velikosti, poslat zprávu ICMP "fragmentation needed" a odesílatel sníží svůj odhad. U IPv6 je ekvivalentem zpráva Packet Too Big a routery v tranzitu vůbec nefragmentují. Když je tato zpětná vazba filtrována, odesílatel dál vytváří pakety, které cesta neunese, a nic mu neřekne proč.

Mýtus druhý: zapouzdření stojí jednu hlavičku

Počítejte vnější vrstvy poctivě. Vnější IP hlavička má 20 bajtů u IPv4 nebo 40 u IPv6. UDP zapouzdření pro průchod NAT přidává 8. Protokol tunelu přidává vlastní hlavičku, inicializační vektor nebo nonce, výplň do bloku šifry nebo zarovnání, závěrečný blok a hodnotu kontroly integrity. Podle protokolu a šifry je součet klidně v desítkách bajtů, než vnitřní paket vůbec začne.

Pak znovu odečtěte vlastní hlavičky vnitřního paketu. TCP segment uvnitř tunelu nese svou 20bajtovou IP hlavičku a 20bajtovou TCP hlavičku a MSS v TCP se odvozuje z MTU, ne z nominálního užitečného zatížení tunelu. Proto může ping s menším zatížením uspět, zatímco přenos souboru uvázne: nástroje testují různé věci a jen jeden z nich procvičuje TCP segment plné velikosti.

ip link show tun0
ping -M do -s 1472 192.0.2.10
ping -M do -s 1400 192.0.2.10

První příkaz hlásí nastavené MTU tunelu. Dvě sondy posílají zatížení 1472 bajtů, což je s 28 bajty hlaviček IPv4 a ICMP paket o 1500 bajtech, a potom menší. Pokud velká sonda úplně selže a malá uspěje, máte závadu závislou na velikosti, ne obecný problém směrování.

Mýtus třetí: PPPoE vám stále dává čistých 1500

Běžný přístupový spoj PPPoE nenese IP paket o 1500 bajtech. Hlavička PPPoE plus pole protokolu PPP zabírají 8 bajtů uvnitř rámce Ethernet, což pro IP paket nechává 1492. To je tradiční limit popsaný v RFC 2516. Pokud přes takový spoj provozujete VPN, režie tunelu jde z těch 1492, ne z 1500.

RFC 4638 definuje způsob, jak vyjednat větší užitečné zatížení PPP, když to podporuje jak přístupový koncentrátor, tak zařízení zákazníka, a proto samotné "toto připojení používá PPPoE" konkrétní číslo nedokazuje. Místní nastavení nemůže přinutit mezilehlé zařízení přijmout paket, pro který nikdy nebylo nakonfigurováno, takže užitečná otázka je, co spoj skutečně vyjednal, ne co říká štítek.

Proč porucha vypadá selektivně

Malé požadavky, které projdou, a velké přenosy, které uvazují, jsou klasickým podpisem černé díry MTU cesty. Navázání spojení, dotaz DNS i volání API se vejdou; hromadný přenos vytváří segmenty plné velikosti, které na jednom spoji umírají, a zpráva ICMP, která měla problém nahlásit, nikdy nedorazí. Spojení vypadá v pořádku a stahování visí, což lidi posílá dívat se na server místo na cestu.

Druhá, související chyba je zaměnit tři čísla: MTU rozhraní, TCP MSS a vlastní nastavení fragmentace nebo výplně protokolu. Sevření MSS na routeru přepisuje inzerovanou MSS, aby odesílatel sestavoval menší segmenty; nemění MTU tunelu a nepomáhá provozu UDP. Nastavit všem třem stejné číslo, protože vypadají související, je způsob, jak dobře míněná změna rozbije fungující konfiguraci.

Co změnit a v jakém pořadí

Začněte důkazy. Pomocí sond výše potvrďte, že závada závisí na velikosti, a pak najděte nejmenší velikost, která projde, a největší, která selže. Než obviníte tunel, zkontrolujte skutečné MTU přístupového spoje; spoj PPPoE omezuje rozpočet dřív, než se ho VPN dotkne. Poznamenejte si původní hodnoty, aby se změna dala vrátit.

Pak použijte nejmenší úpravu, kterou klient dokumentuje. Mnoho klientů nabízí MTU tunelu plus volbu opravy MSS a volba MSS je pro TCP často lepší pákou, protože dosáhne na odesílatele, aniž by zmenšila každý paket. Znovu otestujte stejný cíl a stejný přenos a zapište čísla, na kterých jste se zastavili. Hodnota tunelu, která funguje v jedné přístupové síti, není univerzální konstanta a příští lokalita bude mít vlastní rozpočet.