Pad-MTU-ontdekking deur 'n VPN: grootte en die ICMP-gaping

'n Tonnel voltooi sy handskud, klein versoeke kom terug, en die eerste groot oordrag staak. Daardie patroon dui op pad-MTU lank voordat dit op deurset dui. Elke skakel langs die roete beperk die pakgrootte, en inkapseling spandeer 'n deel van daardie toelating op buitenste koptekste, so die binnepakkie moet kleiner wees as wat die rou pad sou aandui. Die fout is stil, en dit is wat dit duur maak om te diagnoseer.

Wat pad-MTU werklik meet

Pad-MTU is die kleinste skakel-MTU op die roete tussen twee gashere, nie die MTU wat op jou plaaslike koppelvlak gedruk is nie. Die plaaslike waarde is waar die skatting begin, en die pad besluit waar dit moet eindig. Dit is hoekom 'n identiese tonnel op een toegangsnetwerk kan werk en op 'n ander kan staak: die roete het verander, nie die konfigurasie nie. Een keer meet en oral aanvaar is die fout wat hierdie probleem aan die lewe hou.

Vir 'n tonnel is die getal wat saak maak die binneste MTU, wat die buitenste pad se toelating minus alles wat die inkapseling verbruik is. WireGuard voeg 'n buitenste IP-koptekst en 'n UDP-koptekst by; ander vervoerders voeg hul eie by. Stel die binneste grootte te hoog en elke volgrootte pakkie benodig fragmentasie wat dalk nooit gebeur nie.

Hoekom 'n tonnel die bruikbare pakkie verklein

As die tonnelkoppelvlak die fisiese skakel se MTU behou, hang elke groot pakkie daarvan af dat iemand stroomaf bereid is om dit te fragmenteer. IPv4 laat dit in beginsel toe, maar 'n router wat opdrag het om nie te fragmenteer nie, gee eerder 'n fout terug. IPv6-routers fragmenteer glad nooit in transito nie, so dieselfde instelling gedra hom anders per adresfamilie. In albei gevalle leer die sender niks voordat iets terugrapporteer nie.

Die praktiese gevolg is 'n grootte wat by die handskud pas en nie by die nutslading nie. 'n TLS ClientHello of 'n DNS-navraag is klein genoeg om 'n verkleinde pad ongeraak oor te steek, terwyl 'n groot oordrag dit nie is nie. Simptome klomp dus rondom spesifieke bewerkings eerder as spesifieke gashere.

Ontdekking werk net wanneer die terugvoer aankom

IPv4-ontdekking berus op die don't-fragment-bis: 'n router wat nie die pakkie kan aanstuur nie, gee ICMP fragmentation-needed met die volgende-hop-MTU terug, en die sender verlaag sy skatting. IPv6 gebruik eerder Packet Too Big-boodskappe, want routers fragmenteer nie in transito nie. Albei meganismes aanvaar dat die boodskap terug na die sender vind, deur die tonnel en verby enige firewall op die terugpad. Wanneer daardie aanname misluk, hou die sender aan om 'n grootte te probeer wat die pad nie kan dra nie.

'n Firewall wat eggo-versoek en eggo-antwoord toelaat, het nie noodwendig daardie fouttipes toegelaat nie. ICMP is 'n familie, en die lede wat hier saak maak, is die foute, nie die eggo-paar nie. Kontroleer die beheerverkeer-beleid aan albei tonnel-eindpunte en op die pad tussen hulle, en volg die platform se ondersteunde leiding eerder as om elke ICMP-tipe oral toe te laat.

Dieselfde filtering kan binne die tonnel sit. As die binnepad die fout laat val maar die buitenste pad dit dra, kan die sender aanpas by 'n limiet wat die ingekapselde verkeer nooit werklik sien nie.

Toets die pad eerder as om 'n getal te raai

Hou die bestemming, die toegangsnetwerk en die tonnel vas, en verander dan net die pakgrootte. 'n Don't-fragment-toets wat met 'n MTU-wenk misluk, gee jou die volgende-hop-limiet; herhaal totdat 'n grootte slaag, en teken beide die grootte en die adresfamilie aan.

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

'n Ping wat pas, bewys nie dat 'n regte toepassing se volgrootte segmente pas nie, so herhaal die toets met die oordrag wat werklik misluk het. Vergelyk die grootste werkende toets met die tonnel-MTU wat jy gekonfigureer het, en hou die twee getalle apart in jou notas. As hulle met omtrent 'n koptekst se waarde verskil, het jy die inkapselings-oorhoofsheid gevind, nie 'n fout nie.

PLPMTUD, beskryf in RFC 4821, toets opwaarts en gebruik vervoer-bevestigings in plaas daarvan om op afgelewerde foute te vertrou. Dit help op paaie wat ICMP filter, maar ondersteuning wissel per stapel en per toepassing. 'n TCP-stroom kan vanself herstel terwyl 'n UDP-toepassing met 'n vaste datagramgrootte aanhou misluk.

Kies 'n waarde en teken die redenasie aan

Om die tonnel-MTU te verlaag, is beide 'n diagnostikum en 'n wettige oplossing sodra jy die pad ken. Dit is nie 'n plaasvervanger vir die wete watter pad en watter terugvoermeganisme betrokke was nie, want 'n waarde wat vir 'n mobiele skakel ingestel is, sal op 'n veselverbinding onnodig klein wees. Teken die gekose grootte, die toets wat dit geregverdig het en die terugrolstap aan.

Die IPv4-meganisme word in RFC 1191 beskryf en die IPv6-pakketteringsleiding in RFC 8201; om albei te noem, keer dat die volgende ingenieur die aanname herontdek. As die oordrag steeds by die grootte wat jy gekies het, staak, hou op om die getal te verlaag en kyk na die volgende laag. 'n Pad wat by elke grootte misluk, is nie 'n MTU-probleem nie.