IPv6-paketti liian suuri: miksi suuret VPN-siirrot pysähtyvät

Ping toimii, selain lataa pienen sivun ja tiedostonsiirto jumittuu — kaikki IPv6:n yli saman tunnelin läpi. Tämä kuvio tarkoittaa yleensä sitä, että lähettäjä ei koskaan oppinut polun todellista kokoa, ei sitä että tunneli olisi hidas. IPv6 odottaa reitittimien ilmoittavan ongelman Packet Too Big -viestillä, ja kapselointi lisää ylimääräistä kuormaa ennen kuin paketti edes saavuttaa ulomman verkon. Jos viesti suodatetaan, lähettäjä toistaa kokoa, joka ei voi mennä läpi.

Pieniä pyyntöjä, suuria pysähdyksiä

Tunneli käärii jokaisen paketin toiseen otsikkoon, joten käyttökelpoinen koko sisällä on pienempi kuin koko ulkona. Paketti, joka mitoitettiin fyysiselle yhteydelle ennen kapselointia, muuttuu sen jälkeen liian suureksi. IPv4-reitittimet voivat pirstoa matkalla, kun taas IPv6-reitittimet eivät tee sitä lähettäjän puolesta, joten lähettäjän on mukauduttava itse. Ja tämä mukautuminen riippuu täysin palautteen vastaanottamisesta.

Yksi kadonnut viesti riittää klassiseen oireeseen: kättelyt ja pienet vastaukset onnistuvat, ja hakemistolistaus tai lataus jumittuu joka kerta samaan kohtaan. Käyttäjät kuvaavat sitä hitaaksi VPN:ksi, eivätkä lokit näytä mitään viallista todentamisessa. Molemmat havainnot pitävät paikkansa, eikä kumpikaan paikanna vikaa.

Packet Too Big on palautetta, ei liikennettä

ICMPv6 Packet Too Big -viesti kantaa koon, jonka seuraava hyppy voi hyväksyä, ja lähettäjä käyttää sitä arvionsa laskemiseen. Sen suodattaminen vastaa tienviitan poistamista ja kuljettajien syyttämistä sen jälkeen. Sääntö, joka pudottaa kaiken ICMPv6:n, näyttää tiukalta mutta rikkoo polun löytämisen jokaisella linkillä, joka sitä tarvitsee. Viesti on polkua koskevaa ohjaustietoa, ei sovelluksen hyötykuormaa.

Valikoiva suodatus on silti järkevää. Kaiutinpyynnöt ja naapureiden löytäminen ovat eri roolissa kuin virheviestit, ja käytäntö voi kohdella niitä eri tavoin. Noudata alustan dokumentoituja suodatusohjeita sen sijaan, että hyväksyisit tai hylkäisit koko protokollan, koska RFC 8201 määrittelee, miten palaute ohjaa löytämistä.

Testaa molemmat osoiteperheet erikseen

Testaa IPv6 erikseen, koska onnistunut IPv4-siirto ei todista mitään IPv6-polusta. Tallenna sitten ohjausviestit, kun suuri siirto jumittuu. Kaksi tallennetta yhdessä joko näyttävät palautteen lähtevän tai todistavat, ettei se koskaan saapunut.

ping -6 -M do -s 1400 host.internal
ip -6 route get 2001:db8:2::10
sudo tcpdump -ni any 'icmp6 and ip6[40] == 2'

Koetin lähettää paketin, jossa do-not-fragment-bitti on asetettu, ja ilmoittaa koon, jolla se epäonnistuu — luku, joka tunnelin on mahduttava. Reittikysely nimeää liitännän, joka kuljettaisi kohteen, joten tiedät, mikä linkin MTU pätee. Kaappaus suodattaa ICMPv6 tyyppiä 2, Packet Too Big -viestiä, ja näyttää, saavuttaako se tämän isännän lainkaan. Jos viesti näkyy kaappauksessa ja siirto jumittuu silti, lähettäjä jättää sen huomiotta, mikä siirtää tutkinnan pinoon verkon sijaan.

Muuta tunnelin kokoa vasta todisteiden jälkeen

Tunnelin MTU:n laskeminen voi piilottaa suodatetun viestin ja saada oireen katoamaan, mutta jokaisen paketin ylimääräisen kuorman kustannuksella. Se on kiertotie eikä diagnoosi, ja sen pitäisi seurata kaappausta sen sijaan, että korvaa sen. Mielivaltaisen matala arvo ei myöskään riko mitään näkyvää, ja siksi se säilyy asetuksissa vuosia. Muuta sitä tietoisesti, kirjaa arvo ja merkitse, mikä mittaus sen oikeutti.

Kun hallitset yhdyskäytävää, tutki sääntöä, joka pudottaa viestin, sen sijaan että kytket palomuurin pois. Yksi korjattu sääntö on kapeampi kuin käytäntöpoikkeus ja paljon helpompi puolustaa myöhemmin. Sama logiikka pätee aikakatkaisuihin: jokainen jumittuminen ei ole kokoon liittyvä ongelma, ja kaappaus on se, mikä erottaa ne kaksi.