Polun MTU:n selvittäminen VPN:n läpi: mitoitus ja ICMP-aukko

Tunneli saa kättelynsä valmiiksi, pienet pyynnöt palaavat ja ensimmäinen suuri siirto jumittuu. Tämä kuvio viittaa polun MTU:hun paljon ennen kuin se viittaa läpäisyyn. Jokainen linkki reitillä rajoittaa paketin kokoa, ja kapselointi kuluttaa osan tästä kiintiöstä ulkoisiin otsakkeisiin, joten sisäisen paketin on oltava pienempi kuin raaka polku antaisi ymmärtää. Vika on äänetön, ja juuri siksi sen diagnosointi on kallista.

Mitä polun MTU oikeastaan mittaa

Polun MTU on reitin pienin linkin MTU kahden isännän välillä, ei paikalliseen käyttöliittymääsi painettu MTU. Paikallinen arvo on arvion lähtökohta, ja polku päättää, mihin sen on päätyttävä. Siksi sama tunneli voi toimia yhdessä liityntäverkossa ja jumittua toisessa: reitti muuttui, ei kokoonpano. Kerran mittaaminen ja kaikkialla olettaminen on se virhe, joka pitää tämän ongelman hengissä.

Tunnelille ratkaiseva luku on sisäinen MTU eli ulkoisen polun kiintiö miinus kaikki, mitä kapselointi kuluttaa. WireGuard lisää ulkoisen IP-otsakkeen ja UDP-otsakkeen; muut kuljetukset lisäävät omansa. Aseta sisäinen koko liian suureksi, ja jokainen täysikokoinen paketti tarvitsee pirstoutuksen, jota ei ehkä koskaan tapahdu.

Miksi tunneli pienentää käyttökelpoista pakettia

Jos tunnelin käyttöliittymä säilyttää fyysisen linkin MTU:n, jokainen suuri paketti riippuu siitä, että joku alempana on valmis pirstomaan sen. IPv4 sallii sen periaatteessa, mutta reititin, jolle on sanottu, ettei se saa pirstoa, palauttaa sen sijaan virheen. IPv6-reitittimet eivät koskaan pirsto siirtotiellä, joten sama asetus käyttäytyy eri tavalla osoiteperheen mukaan. Kummassakin tapauksessa lähettäjä ei opi mitään ennen kuin jokin raportoi takaisin.

Käytännön seuraus on koko, joka sopii kättelyyn mutta ei hyötykuormaan. TLS ClientHello tai DNS-kysely on tarpeeksi pieni ylittämään pienennetyn polun koskemattomana, kun taas massasiirto ei ole. Siksi oireet keskittyvät tiettyihin toimintoihin eikä tiettyihin isäntiin.

Selvitys toimii vain, kun palaute saapuu perille

IPv4:n selvitys nojaa ei-pirsto-bittiin: reititin, joka ei voi välittää pakettia, palauttaa ICMP fragmentation-needed -viestin seuraavan hypyn MTU:lla, ja lähettäjä laskee arviotaan. IPv6 käyttää sen sijaan Packet Too Big -viestejä, koska reitittimet eivät pirsto siirtotiellä. Molemmat mekanismit olettavat, että viesti löytää tiensä takaisin lähettäjälle, tunnelin läpi ja paluupolun mahdollisen palomuurin ohi. Kun tämä oletus pettää, lähettäjä yrittää yhä uudelleen kokoa, jota polku ei voi kantaa.

Palomuuri, joka sallii echo request- ja echo reply -viestit, ei välttämättä ole sallinut näitä virhetyyppejä. ICMP on perhe, ja tässä ratkaisevat jäsenet ovat virheet, eivät echo-pari. Tarkista ohjausliikenteen käytäntö tunnelin molemmissa päissä ja niiden välisellä polulla ja noudata alustan tuettuja ohjeita sen sijaan, että sallit kaikki ICMP-tyypit kaikkialla.

Sama suodatus voi olla tunnelin sisällä. Jos sisäinen polku pudottaa virheen mutta ulkoinen kantaa sen, lähettäjä voi mukautua rajaan, jota kapseloitu liikenne ei todellisuudessa koskaan näe.

Testaa polkua sen sijaan, että arvaat luvun

Pidä kohde, liityntäverkko ja tunneli kiinteinä ja vaihtele vain paketin kokoa. Ei-pirsto-koe, joka epäonnistuu MTU-vihjeen kanssa, antaa seuraavan hypyn rajan; toista, kunnes jokin koko menee läpi, ja kirjaa sekä koko että osoiteperhe.

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

Sopiva ping ei todista, että todellisen sovelluksen täysikokoiset segmentit sopivat, joten toista koe siirrolla, joka todella epäonnistui. Vertaa suurinta toimivaa koetta määrittämääsi tunnelin MTU:hun ja pidä nämä kaksi lukua erillään muistiinpanoissasi. Jos ne eroavat suunnilleen yhden otsakkeen verran, olet löytänyt kapseloinnin ylimääräisen kulun, et vikaa.

PLPMTUD, jota kuvataan RFC 4821:ssä, koettaa ylöspäin ja käyttää kuljetuksen kuittauksia sen sijaan, että luottaisi toimitettuihin virheisiin. Se auttaa poluilla, jotka suodattavat ICMP:tä, mutta tuki vaihtelee pinon ja sovelluksen mukaan. TCP-virta voi toipua itsestään, kun taas kiinteän datagrammikoon UDP-sovellus epäonnistuu edelleen.

Valitse arvo ja kirjaa perustelut

Tunnelin MTU:n laskeminen on sekä diagnoosi että laillinen korjaus, kun tunnet polun. Se ei korvaa tietoa siitä, mikä polku ja mikä palautemekanismi olivat mukana, koska mobiililinkille viritetty arvo on tarpeettoman pieni kuituyhteydellä. Kirjaa valittu koko, sen perustellut koe ja peruutusvaihe.

IPv4-mekanismi kuvataan kohdassa RFC 1191 ja IPv6:n paketointiohje kohdassa RFC 8201; molempien nimeäminen estää seuraavaa insinööriä johtamasta oletusta uudelleen. Jos siirto jumittuu edelleen valitsemassasi koossa, lopeta luvun laskeminen ja katso seuraavaa kerrosta. Polku, joka epäonnistuu joka koossa, ei ole MTU-ongelma.