VPN-i MTU müüdid: miks teie paketid kahanevad ja kuhu ruum kaob

Keegi ütleb teile, et VPN "kaotab pakette MTU tõttu", te seate tunneliks 1400 ja ülekanne hakkab jälle tööle. See tulemus tundub diagnoosina. Tavaliselt on see aritmeetiline juhus: valisite numbri, mis oli piisavalt väike, et mahtuda piiri alla, mida te kunagi ei tuvastanud, ja kohtute sama piiriga uuesti järgmises võrgus, kus on teine eelarve.

Suuremat osa sellest põhjustavad kaks müüti. Esimene on see, et tunneli liidese MTU on tee MTU. Teine on see, et kapseldamine maksab "ühe päise" ja PPPoE ei maksa midagi, mida tasuks lugeda. Mõlemad on valed viisil, mis teeb teie valitud numbri näiliselt meelevaldseks, kuigi see on tegelikult määratud.

Müüt üks: tunneli MTU on tee MTU

Väärtus, mille te tunneli liidesele seate, on kohalik lubadus suurima sisemise paketi kohta, mille rakendus alla annab. Tee tegelik võimsus on iga lüli omadus teie ja kaugema otsa vahel ning võib muutuda, kui marsruut muutub, kui mobiilühendus edasi antakse või kui liiklus läheb teise peeringu kaudu. Seatud 1500 ütleb, mida teie host ehitab, mitte mida võrk kannab.

Tee-MTU avastamine on olemas nende kahe ühitamiseks ja sõltub tagasisidest. IPv4 puhul peaks ruuter, mis ei saa täissuuruses paketti edasi saata, saatma ICMP teate "fragmentation needed", ja saatja langetab oma hinnangut. IPv6 puhul on vasteks Packet Too Big teade ja ruuterid ei fragmenteeri transiidis üldse. Kui see tagasiside filtreeritakse, jätkab saatja pakettide tootmist, mida tee kanda ei suuda, ja miski ei ütle talle, miks.

Müüt kaks: kapseldamine maksab ühe päise

Loendage väliskihid ausalt. Välimine IP-päis on 20 baiti IPv4 puhul või 40 IPv6 puhul. UDP kapseldamine NAT-i läbimiseks lisab 8. Tunneliprotokoll lisab oma päise, initsialiseerimisvektori või nonce'i, polsterduse šifri ploki või joonduse piirini, lõpuosa ja terviklikkuse kontrollväärtuse. Sõltuvalt protokollist ja šifrist on kogusumma mugavalt kümnetes baitides, enne kui sisemine pakett üldse algab.

Seejärel lahutage uuesti sisemise paketi enda päised. Tunnelis olev TCP-segment kannab oma 20-baidist IP-päist ja 20-baidist TCP-päist ning TCP MSS tuletatakse MTU-st, mitte tunneli nominaalsest kasulikust koormusest. Seetõttu võib ping väiksema koormusega õnnestuda, samal ajal kui failiülekanne takerdub: tööriistad testivad erinevaid asju ja ainult üks neist harjutab täissuuruses TCP-segmenti.

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

Esimene käsk teatab seatud tunneli MTU. Kaks sondi saadavad 1472-baidise koormuse, mis koos 28 baidi IPv4 ja ICMP päistega on 1500-baidine pakett, ja seejärel väiksema. Kui suur sond ebaõnnestub täielikult ja väike õnnestub, on teil suurusest sõltuv viga, mitte üldine marsruutimisprobleem.

Müüt kolm: PPPoE annab teile endiselt puhta 1500

Tavaline PPPoE juurdepääsulüli ei kanna 1500-baidist IP-paketti. PPPoE päis ja PPP protokolli väli võtavad Etherneti kaadri sees 8 baiti, jättes IP-paketile 1492. See on traditsiooniline piir, mida kirjeldab RFC 2516. Kui käitate VPN-i sellise lüli kaudu, tuleb tunneli üldkulu nendest 1492 baidist, mitte 1500-st.

RFC 4638 määratleb viisi, kuidas läbi rääkida suurem PPP koormus, kui nii juurdepääsukontsentraator kui ka kliendi seade seda toetavad, mistõttu "see ühendus kasutab PPPoE-d" üksi ei tõesta kindlat numbrit. Kohalik seade ei saa sundida vahepealset seadet vastu võtma paketti, mille jaoks seda kunagi ei seadistatud, seega kasulik küsimus on, mille üle lüli tegelikult kokku leppis, mitte mida silt ütleb.

Miks rike näib valikuline

Väikeste päringute õnnestumine ja suurte ülekannete takerdumine on tee-MTU musta augu klassikaline tunnus. Käepigistus, DNS-päring ja API-kutse mahuvad kõik ära; hulgisiire tekitab täissuuruses segmente, mis surevad ühel lülil, ja ICMP teade, mis oleks pidanud probleemist teatama, ei jõua kunagi kohale. Ühendus näib korras ja allalaadimine ripub, mis paneb inimesed vaatama serverit, mitte teed.

Teine, seotud viga on kolme numbri segi ajamine: liidese MTU, TCP MSS ja protokolli enda fragmenteerimis- või polsterdusseade. MSS-i klammerdamine ruuteril kirjutab kuulutatud MSS-i ümber, et saatja ehitaks väiksemaid segmente; see ei muuda tunneli MTU-d ega aita UDP-liiklust. Kõigile kolmele sama numbri andmine, sest need näivad seotud, on viis, kuidas hea kavatsusega muudatus töötava seadistuse rikub.

Mida ja mis järjekorras muuta

Alustage tõenditest. Kinnitage ülaltoodud sondidega, et viga sõltub suurusest, ja leidke väikseim suurus, mis läbib, ja suurim, mis ebaõnnestub. Kontrollige juurdepääsulüli tegelikku MTU-d enne, kui tunneli süüdistate; PPPoE lüli piirab eelarvet enne, kui teie VPN seda puudutab. Kirjutage üles algväärtused, et muudatust saaks tagasi pöörata.

Seejärel rakendage väikseim kohandus, mida klient dokumenteerib. Paljud kliendid pakuvad tunneli MTU-d ja MSS-i paranduse valikut ning MSS-i valik on TCP jaoks sageli parem hoob, sest see jõuab saatjani iga paketti vähendamata. Testige uuesti sama sihtkohta ja sama ülekannet ning kirjutage üles numbrid, mille juurde jäite. Tunneli väärtus, mis töötab ühes juurdepääsuvõrgus, ei ole universaalne konstant, ja järgmisel saidil on oma eelarve.