VPN:n MTU-myytit: miksi pakettisi kutistuvat ja mihin tila katoaa

Joku kertoo sinulle, että VPN "hukkaa paketteja MTU:n takia", asetat tunnelin 1400:aan ja siirto toimii taas. Se tulos tuntuu diagnoosilta. Yleensä se on aritmetiikan sattuma: valitsit luvun, joka oli tarpeeksi pieni mahtuakseen rajan alle, jota et koskaan tunnistanut, ja kohtaat saman rajan seuraavassa verkossa eri budjetilla.

Kaksi myyttiä aiheuttaa suurimman osan tästä. Ensimmäinen on, että tunnelin rajapinnan MTU on polun MTU. Toinen on, että kapselointi maksaa "yhden otsakkeen" ja PPPoE ei maksa mitään laskemisen arvoista. Molemmat ovat väärin tavalla, joka saa valitsemasi luvun näyttämään mielivaltaiselta, vaikka se on oikeastaan määrätty.

Myytti yksi: tunnelin MTU on polun MTU

Arvo, jonka asetat tunnelin rajapinnalle, on paikallinen lupaus suurimmasta sisäisestä paketista, jonka toteutus antaa alaspäin. Polun todellinen kapasiteetti on jokaisen sinun ja kauempana olevan pään välisen linkin ominaisuus, ja se voi muuttua, kun reitti muuttuu, kun mobiiliyhteys luovutetaan tai kun liikenne ottaa toisen peeringin. Asetettu 1500 kertoo, mitä isäntäsi rakentaa, ei mitä verkko kantaa.

Polun MTU:n löytäminen on olemassa näiden kahden sovittamiseksi, ja se riippuu palautteesta. IPv4:ssä reitittimen, joka ei voi välittää täyskokoista pakettia, pitäisi lähettää ICMP-viesti "fragmentation needed", ja lähettäjä laskee arviotaan. IPv6:ssa vastine on Packet Too Big -viesti, eivätkä reitittimet pirsto lainkaan siirron aikana. Kun tämä palaute suodatetaan, lähettäjä tuottaa edelleen paketteja, joita polku ei kanna, eikä mikään kerro sille miksi.

Myytti kaksi: kapselointi maksaa yhden otsakkeen

Laske ulommat kerrokset rehellisesti. Ulompi IP-otsake on 20 tavua IPv4:ssä tai 40 IPv6:ssa. NAT:n läpäisyyn tarkoitettu UDP-kapselointi lisää 8. Tunneliprotokolla lisää oman otsakkeensa, alustusvektorin tai noncen, täytteen salauksen lohkon tai tasauksen rajaan, loppuosan ja eheyden tarkistusarvon. Protokollasta ja salauksesta riippuen summa on mukavasti kymmeniä tavuja, ennen kuin sisempi paketti edes alkaa.

Vähennä sitten taas sisemmän paketin omat otsakkeet. Tunnelissa oleva TCP-segmentti kantaa oman 20 tavun IP-otsakkeensa ja 20 tavun TCP-otsakkeensa, ja TCP:n MSS johdetaan MTU:sta, ei tunnelin nimellisestä hyötykuormasta. Siksi ping pienemmällä hyötykuormalla voi onnistua, kun tiedostonsiirto juuttuu: työkalut testaavat eri asioita, ja vain yksi niistä käyttää täyskokoista TCP-segmenttiä.

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

Ensimmäinen komento ilmoittaa asetetun tunnelin MTU:n. Kaksi koetta lähettävät 1472 tavun hyötykuorman, joka 28 tavun IPv4- ja ICMP-otsakkeiden kanssa on 1500 tavun paketti, ja sitten pienemmän. Jos suuri koe epäonnistuu täysin ja pieni onnistuu, sinulla on koosta riippuva vika, ei yleinen reititysongelma.

Myytti kolme: PPPoE antaa sinulle yhä puhtaan 1500

Tavanomainen PPPoE-liityntälinkki ei kanna 1500 tavun IP-pakettia. PPPoE-otsake ja PPP-protokollakenttä vievät 8 tavua Ethernet-kehyksen sisällä, mikä jättää IP-paketille 1492. Se on RFC 2516:ssa kuvattu perinteinen raja. Jos ajat VPN:ää tällaisen linkin yli, tunnelin ylikuorma tulee noista 1492 tavusta, ei 1500:sta.

RFC 4638 määrittelee tavan neuvotella suuremmasta PPP-hyötykuormasta, kun sekä liityntäkeskitin että asiakkaan laitteet tukevat sitä, minkä vuoksi pelkkä "tämä yhteys käyttää PPPoE:tä" ei todista tiettyä lukua. Paikallinen asetus ei voi pakottaa välissä olevaa laitetta hyväksymään pakettia, jota varten sitä ei koskaan konfiguroitu, joten hyödyllinen kysymys on, mitä linkki todella neuvotteli, ei mitä tarra sanoo.

Miksi vika näyttää valikoivalta

Pienten pyyntöjen onnistuminen ja suurten siirtojen juuttuminen on polun MTU:n mustan aukon klassinen tuntomerkki. Kättely, DNS-kysely ja API-kutsu mahtuvat kaikki; massasiirto tuottaa täyskokoisia segmenttejä, jotka kuolevat yhdellä linkillä, eikä ICMP-viesti, jonka olisi pitänyt ilmoittaa ongelmasta, koskaan saavu. Yhteys näyttää kunnossa olevalta ja lataus jää jumiin, mikä saa ihmiset katsomaan palvelinta polun sijaan.

Toinen, samaan liittyvä virhe on sekoittaa kolme lukua: rajapinnan MTU, TCP:n MSS ja protokollan oma pirstomis- tai täyteasetus. MSS:n puristus reitittimellä kirjoittaa ilmoitetun MSS:n uudelleen, jotta lähettäjä rakentaa pienempiä segmenttejä; se ei muuta tunnelin MTU:ta eikä auta UDP-liikennettä. Saman luvun antaminen kaikille kolmelle, koska ne näyttävät liittyvän toisiinsa, on se tapa, jolla hyväntahtoinen muutos rikkoo toimivan asetelman.

Mitä muuttaa ja missä järjestyksessä

Aloita todisteista. Vahvista yllä olevilla kokeilla, että vika riippuu koosta, ja etsi pienin koko, joka menee läpi, ja suurin, joka epäonnistuu. Tarkista liityntälinkin todellinen MTU ennen kuin syytät tunnelia; PPPoE-linkki rajoittaa budjetin ennen kuin VPN koskettaa sitä. Kirjaa alkuperäiset arvot, jotta muutos voidaan perua.

Käytä sitten pienintä säätöä, jonka asiakasohjelma dokumentoi. Monet asiakasohjelmat tarjoavat tunnelin MTU:n ja MSS-korjausvaihtoehdon, ja MSS-vaihtoehto on TCP:lle usein parempi vipu, koska se tavoittaa lähettäjän kutistamatta jokaista pakettia. Testaa sama kohde ja sama siirto uudelleen ja kirjaa luvut, joihin päädyit. Tunnelin arvo, joka toimii yhdessä liityntäverkossa, ei ole yleispätevä vakio, ja seuraavalla kohteella on oma budjettinsa.