Zisťovanie MTU cesty cez VPN: dimenzovanie a medzera ICMP
Tunel zmenšuje paket, ktorý cesta dokáže preniesť, a zisťovanie funguje len vtedy, keď dorazí spätná väzba. Merajte, testujte a overujte cestu namiesto hádania.
Tunel dokončí handshake, malé požiadavky sa vrátia a prvý veľký prenos sa zasekne. Tento vzor ukazuje na MTU cesty oveľa skôr než na priepustnosť. Každý spoj na trase obmedzuje veľkosť paketu a zapuzdrenie minie časť tejto kvóty na vonkajšie hlavičky, takže vnútorný paket musí byť menší, než by naznačovala surová cesta. Zlyhanie je tiché, a práve preto je drahé diagnostikovať.
Čo MTU cesty skutočne meria
MTU cesty je najmenšie MTU spoja na trase medzi dvoma hostiteľmi, nie MTU vytlačené na lokálnom rozhraní. Lokálna hodnota je bod, kde sa odhad začína, a trasa rozhoduje, kde sa musí skončiť. Preto môže rovnaký tunel fungovať v jednej prístupovej sieti a v inej sa zaseknúť: zmenila sa trasa, nie konfigurácia. Zmerať raz a predpokladať všade je chyba, ktorá drží tento problém nažive.
Pre tunel je dôležité číslo vnútorné MTU, teda kvóta vonkajšej trasy mínus to, čo spotrebuje zapuzdrenie. WireGuard pridáva vonkajšiu IP hlavičku a UDP hlavičku; iné transporty pridávajú svoje. Nastavte vnútornú veľkosť príliš vysoko a každý paket plnej veľkosti bude potrebovať fragmentáciu, ktorá sa možno nikdy nestane.
Prečo tunel zmenšuje použiteľný paket
Ak rozhranie tunela zachová MTU fyzického spoja, každý veľký paket závisí od toho, či ho niekto nižšie na trase bude ochotný fragmentovať. IPv4 to v zásade povoľuje, ale router, ktorému bolo povedané, aby nefragmentoval, vráti namiesto toho chybu. Routery IPv6 nikdy nefragmentujú v tranzite, takže to isté nastavenie sa správa inak podľa rodiny adries. V každom prípade sa odosielateľ nič nedozvie, kým niečo neohlási späť.
Praktickým dôsledkom je veľkosť, ktorá sa zmestí do handshake a nie do užitočného zaťaženia. TLS ClientHello alebo dopyt DNS sú dosť malé na to, aby prešli zmenšenou trasou nedotknuté, kým hromadný prenos nie. Preto sa príznaky zhlukujú okolo konkrétnych operácií, nie konkrétnych hostiteľov.
Zisťovanie funguje len vtedy, keď dorazí spätná väzba
Zisťovanie IPv4 sa opiera o bit don't-fragment: router, ktorý nemôže paket poslať ďalej, vráti ICMP fragmentation-needed s MTU nasledujúceho skoku a odosielateľ zníži svoj odhad. IPv6 namiesto toho používa správy Packet Too Big, pretože routery v tranzite nefragmentujú. Oba mechanizmy predpokladajú, že správa nájde cestu späť k odosielateľovi, cez tunel a popri každom firewalle na spiatočnej trase. Keď tento predpoklad zlyhá, odosielateľ naďalej opakuje veľkosť, ktorú trasa nedokáže preniesť.
Firewall, ktorý povoľuje echo request a echo reply, nemusí povoliť tie typy chýb. ICMP je rodina a členovia, na ktorých tu záleží, sú chyby, nie pár ozvien. Skontrolujte politiku riadiacej prevádzky na oboch koncoch tunela a na trase medzi nimi a riaďte sa podporovanými pokynmi platformy namiesto povoľovania každého typu ICMP všade.
Rovnaké filtrovanie môže sedieť vo vnútri tunela. Ak vnútorná trasa chybu zahodí, ale vonkajšia ju prenesie, odosielateľ sa môže prispôsobiť limitu, ktorý zapuzdrená prevádzka nikdy v skutočnosti nevidí.
Testujte trasu namiesto hádania čísla
Držte cieľ, prístupovú sieť a tunel fixné a meňte iba veľkosť paketu. Test don't-fragment, ktorý zlyhá s náznakom MTU, vám dá limit nasledujúceho skoku; opakujte, kým nejaká veľkosť neprejde, a zaznamenajte veľkosť aj rodinu adries.
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, ktorý sa zmestí, nedokazuje, že sa zmestia segmenty plnej veľkosti skutočnej aplikácie, preto test zopakujte s prenosom, ktorý skutočne zlyhal. Porovnajte najväčší fungujúci test s MTU tunela, ktorý ste nakonfigurovali, a držte tieto dve čísla oddelene vo svojich poznámkach. Ak sa líšia približne o jednu hlavičku, našli ste réžiu zapuzdrenia, nie poruchu.
PLPMTUD, opísaný v RFC 4821, testuje nahor a používa potvrdenia transportu namiesto dôvery v doručené chyby. Pomáha na trasách, ktoré filtrujú ICMP, ale podpora sa líši podľa zásobníka a aplikácie. Tok TCP sa môže zotaviť sám, kým aplikácia UDP s pevnou veľkosťou datagramu naďalej zlyháva.
Vyberte hodnotu a zapíšte odôvodnenie
Zníženie MTU tunela je aj diagnostika, aj legitímna oprava, keď už trasu poznáte. Nie je náhradou za vedomosť, ktorá trasa a ktorý mechanizmus spätnej väzby boli zapojené, pretože hodnota vyladená pre mobilný spoj bude na vlákne zbytočne malá. Zapíšte zvolenú veľkosť, test, ktorý ju odôvodnil, a krok vrátenia.
Mechanizmus IPv4 je opísaný v RFC 1191 a usmernenie k paketizácii IPv6 v RFC 8201; uvedenie oboch zabráni ďalšiemu inžinierovi znova odvodiť predpoklad. Ak sa prenos stále zasekáva pri zvolenej veľkosti, prestaňte znižovať číslo a pozrite sa na ďalšiu vrstvu. Trasa, ktorá zlyhá pri každej veľkosti, nie je problém MTU.