IPv4 fragmenteerib teel; IPv6 saadab selle asemel liiga suure paketi teate

IPv6 tõrkeid aetakse protokolli süüks palju sagedamini kui nende põhjustanud paketi suuruse arvele. Kaks perekonda käsitlevad ülemõõdulist paketti tõesti erinevalt ja tunnel on see, mis teeb erinevuse oluliseks. IPv4 ruuterid tohivad paketti fragmenteerida, kui reeglid seda lubavad, samas kui IPv6 ruuterid ei tohi teel üldse fragmenteerida. IPv6 ütleb selle selle asemel saatjale ja saatjalt oodatakse reaktsiooni. Kõik, mis hiljem valesti läheb, tuleneb sellest, kas see teade kohale jõuab.

Mida kumbki perekond teeb

Tabel on mehhanism neljas reas ja üks rida selgitab suurema osa segadusest.

IPv6-l pole teel fragmenteerimist ega DF-lippu, mida tühjendada, seega pole millegi juurde tagasi pöörduda, kui pakett on liiga suur. Saatjale tuleb sellest öelda ja saatja peab seda uskuma.

Tunnel kitsendab teed vaikselt

VPN lisab välised päised, krüpteeritud juhul ka terviklikkuse andmed, enne kui pakett hostist lahkub. Sisemine pakett võib mahtuda liidese MTU-sse, mida see näeb, samas kui välimine pakett ületab järgmise lüli piiri, ja seetõttu ilmneb see kõigepealt tunnelis. Kahandage tunneliliidese MTU-d teadlikult või klammerdage teel TCP MSS ja kirjutage üles, millise numbri valisite ja miks.

ESP üldkulud sõltuvad režiimist ja algoritmidest, seega õige tunneli MTU on arvutus, mitte konventsioon. Mida iganes valite, see peab jätma ruumi täielikule sisemisele 1280-baidisele IPv6 paketile, sest iga IPv6 lüli peab nii palju kandma. Tunnel, mis ei suuda kanda 1280 baiti IPv6, pole häälestusprobleem; see on selle perekonna jaoks katkine tee. Just see piirang kaob, kui MTU väärtus kopeeritakse ainult IPv4 kasutavast paigaldest.

Miks sümptom on hangumine

Tõrge ei ole puhas viga ja seetõttu diagnoositakse see valesti. TCP käepigistus lõpeb, väikesed vastused saabuvad ja ühendus takerdub niipea, kui algab suur vastus või mahukas üleslaadimine, sest need on esimesed paketid, mis on küllalt suured, et ära visata. SSH ühendub ja jääb siis esimese suure väljundi juures hanguma ning lehe päis laaditakse, samal ajal kui põhiosa ei lõpe kunagi.

Kui ICMPv6 liiga suure paketi teated filtreeritakse, ei saa saatja sellest kunagi teada ja proovib ikka sama suurust. See on must auk, mitte aeglane tee, ja selle tunnus on korratav suuruspiir, mitte juhuslik kadu. Asjaomase juhtimisliikluse lubamine on toimiva IPv6 paigaldise osa, mitte viisakus.

Ärge lülitage välja teateid, millest teie enda tee sõltub, ja kirjeldage siis tulemust IPv6 rikkena. Sama argument kehtib IPv4 Fragmentation Needed teadete kohta, mis on tulemüüride autorite seas sama ebapopulaarsed ja sama vajalikud.

Mõõtke piir ja parandage siis kiht

Kontrollige, mitte oletage: kasutage IPv4 puhul don't-fragment lippu ja IPv6 puhul fikseeritud kasuliku koormuse suurusi, ning kirjutage üles, kus vastused lakkavad. ping -M do -s 1472 ja ping -6 -s 1400 on piisavad probleemi kuju kindlaksmääramiseks ning tracepath teatab teel avastatud tee MTU.

Seejärel parandage kiht, kellele number kuulub: tunneliliidese MTU, TCP MSS-i klammerdamine või tee ise. RFC 8200 on IPv6 reegli viide ja seda on lühem lugeda kui juhtumit, mida see ära hoiab.

Testige perekonda, mida rakendus tegelikult kasutab, sest kahekihiline nimi võib vastata ühes perekonnas ja mitte teises, ning rakendus võib pärast võrgu muutust ümber lülituda. Kirjutage üles aadress, mida testisite, sest tulemus A-kirje vastu ei ütle midagi AAAA-kirje kohta.

Käsitlege suuruspiiri tõendina

Korratav suuruspiir on üks väheseid võrgutõrkeid, mis taastoodab end täpselt, sama baidiarvu juures, samast allikast, iga kord. See teeb sellest kingituse, mitte mõistatuse, ja tähendab ka, et parandust saab kontrollida, mitte loota.

Kirjutage piletisse avastatud MTU, konfigureeritud tunneli MTU ja test, mis erinevust tõestas. Järgmine inimene kohtab sama aritmeetikat teisel lülil.