Mýty o MTU vo VPN: prečo sa vaše pakety zmenšujú a kam sa stráca miesto

Niekto vám povie, že VPN "stráca pakety kvôli MTU", vy nastavíte tunel na 1400 a prenos znovu funguje. Taký výsledok vyzerá ako diagnóza. Zvyčajne je to náhoda v aritmetike: vybrali ste číslo dosť malé na to, aby sa zmestilo pod limit, ktorý ste nikdy neidentifikovali, a ten istý limit stretnete znova v ďalšej sieti s iným rozpočtom.

Väčšinu toho spôsobujú dva mýty. Prvý je, že MTU rozhrania tunela je MTU cesty. Druhý je, že zapuzdrenie stojí "jednu hlavičku" a PPPoE nestojí nič, čo by stálo za počítanie. Oba sú nesprávne spôsobom, ktorý robí zvolené číslo zdanlivo svojvoľným, hoci je v skutočnosti určené.

Mýtus prvý: MTU tunela je MTU cesty

Hodnota, ktorú nastavíte na rozhraní tunela, je miestny sľub o najväčšom vnútornom pakete, ktorý implementácia odovzdá nadol. Skutočná kapacita cesty je vlastnosťou každého spoja medzi vami a vzdialeným koncom a môže sa zmeniť, keď sa zmení trasa, keď sa mobilné pripojenie odovzdá alebo keď prevádzka pôjde iným peeringom. Nastavených 1500 hovorí, čo zostaví váš hostiteľ, nie čo prenesie sieť.

Objavovanie MTU cesty existuje preto, aby obe zosúladilo, a závisí od spätnej väzby. V IPv4 má router, ktorý nemôže preposlať paket plnej veľkosti, poslať správu ICMP "fragmentation needed", a odosielateľ zníži svoj odhad. V IPv6 je ekvivalentom správa Packet Too Big a routery v tranzite vôbec nefragmentujú. Keď je táto spätná väzba filtrovaná, odosielateľ ďalej vytvára pakety, ktoré cesta neunesie, a nič mu nepovie prečo.

Mýtus druhý: zapuzdrenie stojí jednu hlavičku

Počítajte vonkajšie vrstvy čestne. Vonkajšia IP hlavička má 20 bajtov v IPv4 alebo 40 v IPv6. UDP zapuzdrenie na priechod NAT pridáva 8. Protokol tunela pridáva vlastnú hlavičku, inicializačný vektor alebo nonce, výplň do hranice bloku alebo zarovnania šifry, koncovú časť a hodnotu kontroly integrity. V závislosti od protokolu a šifry je súčet pokojne v desiatkach bajtov, kým vnútorný paket vôbec začne.

Potom znova odpočítajte vlastné hlavičky vnútorného paketu. TCP segment vnútri tunela nesie svoju 20-bajtovú IP hlavičku a 20-bajtovú TCP hlavičku a MSS v TCP sa odvodzuje z MTU, nie z nominálnej užitočnej záťaže tunela. Preto môže ping s menšou záťažou uspieť, kým prenos súboru uviazne: nástroje testujú rôzne veci a iba jeden z nich precvičuje TCP segment plnej veľkosti.

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

Prvý príkaz hlási nastavené MTU tunela. Dve sondy posielajú záťaž 1472 bajtov, čo s 28 bajtmi hlavičiek IPv4 a ICMP je paket 1500 bajtov, a potom menší. Ak veľká sonda úplne zlyhá a malá uspeje, máte poruchu závislú od veľkosti, nie všeobecný problém s routingom.

Mýtus tretí: PPPoE vám stále dáva čistých 1500

Bežný prístupový spoj PPPoE neprenáša IP paket s 1500 bajtmi. Hlavička PPPoE plus pole protokolu PPP zaberajú 8 bajtov v rámci Ethernetu, čo pre IP paket necháva 1492. To je tradičný limit opísaný v RFC 2516. Ak cez taký spoj prevádzkujete VPN, réžia tunela ide z tých 1492, nie z 1500.

RFC 4638 definuje spôsob, ako vyjednať väčšiu PPP užitočnú záťaž, keď to podporuje prístupový koncentrátor aj zariadenie zákazníka, a preto samotné "toto pripojenie používa PPPoE" nepreukazuje konkrétne číslo. Miestne nastavenie nemôže prinútiť medziľahlé zariadenie prijať paket, pre ktorý nikdy nebolo nakonfigurované, takže užitočná otázka je, čo spoj skutočne vyjednal, nie čo hovorí štítok.

Prečo porucha vyzerá selektívne

To, že malé požiadavky uspejú a veľké prenosy uviaznu, je klasický podpis čiernej diery MTU cesty. Podanie ruky, dotaz DNS a volanie API sa všetky zmestia; hromadný prenos vytvára segmenty plnej veľkosti, ktoré zomierajú na jednom spoji, a správa ICMP, ktorá mala problém nahlásiť, nikdy nedorazí. Spojenie vyzerá v poriadku a sťahovanie visí, čo ľudí núti pozerať sa na server namiesto na cestu.

Druhá, súvisiaca chyba je miešať tri čísla: MTU rozhrania, MSS v TCP a vlastné nastavenie fragmentácie alebo výplne protokolu. Zovretie MSS na routeri prepisuje inzerované MSS, aby odosielateľ zostavoval menšie segmenty; nemení MTU tunela a nepomáha prevádzke UDP. Dať všetkým trom rovnaké číslo, pretože vyzerajú súvisiace, je spôsob, akým dobre mienená zmena pokazí fungujúcu konfiguráciu.

Čo zmeniť a v akom poradí

Začnite dôkazmi. Potvrďte sondami vyššie, že porucha závisí od veľkosti, a potom nájdite najmenšiu veľkosť, ktorá prejde, a najväčšiu, ktorá zlyhá. Skontrolujte skutočné MTU prístupového spoja, kým obviníte tunel; spoj PPPoE obmedzuje rozpočet skôr, než sa ho VPN dotkne. Poznačte si pôvodné hodnoty, aby sa zmena dala vrátiť.

Potom použite najmenšiu úpravu, ktorú klient dokumentuje. Mnohí klienti ponúkajú MTU tunela plus možnosť opravy MSS a možnosť MSS je pre TCP často lepšou pákou, pretože dosiahne odosielateľa bez zmenšenia každého paketu. Znova otestujte ten istý cieľ a ten istý prenos a zapíšte čísla, na ktorých ste sa zastavili. Hodnota tunela, ktorá funguje v jednej prístupovej sieti, nie je univerzálna konštanta a ďalšie miesto bude mať vlastný rozpočet.