IPv4 fragmenterer undervegs; IPv6 sender i staden ei melding om for stor pakke

IPv6-feil vert mykje oftare lagde på protokollen enn på pakkestorleiken som førte til dei. Dei to familiane handsamar ein for stor pakke faktisk ulikt, og ein tunnel er det som gjer skilnaden viktig. IPv4-rutarar kan fragmentera ein pakke når reglane tillet det, medan IPv6-rutarar ikkje skal fragmentera undervegs i det heile. IPv6 seier det i staden til avsendaren, og avsendaren er venta å reagera. Alt som går gale etterpå, kjem av om den meldinga kjem fram.

Kva kvar familie gjer

Tabellen er mekanismen på fire linjer, og éi rad forklarer det meste av forvirringa.

IPv6 har ingen fragmentering undervegs og inga DF-flagg å fjerna, så det er ingenting å falla tilbake på når ein pakke er for stor. Avsendaren må få beskjed, og avsendaren må tru på det.

Tunnelen snevrar inn vegen i stillheit

Ein VPN legg til ytre headerar, og i det krypterte tilfellet også integritetsdata, før pakken forlèt verten. Den indre pakken kan passa i MTU-en til grensesnittet han ser, medan den ytre pakken overskrid grensa til neste ledd, og difor dukkar dette først opp i ein tunnel. Senk MTU-en til tunnelgrensesnittet med vilje, eller klem TCP MSS på vegen, og skriv ned kva tal du valde og kvifor.

ESP-overheaden er avhengig av modus og algoritmar, så riktig tunnel-MTU er ei utrekning og ikkje ein konvensjon. Uansett kva du vel, må det gje plass til ein full indre IPv6-pakke på 1280 byte, fordi kvart IPv6-ledd må bera så mykje. Ein tunnel som ikkje kan bera 1280 byte med IPv6, er ikkje eit tuning-problem; det er ein broten veg for den familien. Nettopp den avgrensinga forsvinn når ein MTU-verdi blir kopiert frå ein installasjon med berre IPv4.

Kvifor symptomet er eit hang

Feilen er ikkje ein rein feil, og difor blir han feildiagnostisert. Eit TCP-handtrykk blir fullført, små svar kjem inn, og sambandet stoppar så snart eit stort svar eller ei stor opplasting byrjar, fordi det er dei første pakkane som er store nok til å bli kasta. SSH koplar til og heng deretter på den første store utdataen, og hovudet på ei side blir lasta medan kroppen aldri blir ferdig.

Viss ICMPv6-meldingane om for stor pakke blir filtrerte, lærer avsendaren det aldri og prøver om og om att med same storleik. Det er eit svart hol og ikkje ein treg veg, og signaturen er ei gjentakbar storleiksgrense og ikkje tilfeldig tap. Å halda den relevante kontrolltrafikken tillaten er ein del av ein fungerande IPv6-installasjon, ikkje ei høflegheit.

Ikkje slå av meldingane din eigen veg er avhengig av, og skildra deretter resultatet som ein IPv6-feil. Det same argumentet gjeld IPv4-meldingane Fragmentation Needed, som er like upopulære hos brannmurforfattarar og like naudsynte.

Mål grensa, og reparer deretter laget

Sjekk i staden for å gjetta: bruk don't-fragment-flagget på IPv4 og faste nyttelaststorleikar på IPv6, og noter kvar svara stoppar. ping -M do -s 1472 og ping -6 -s 1400 er nok til å fastslå forma på problemet, og tracepath rapporterer den oppdaga veg-MTU-en undervegs.

Reparer deretter laget som eig talet: MTU-en til tunnelgrensesnittet, MSS-klemmen for TCP, eller sjølve vegen. RFC 8200 er referansen for IPv6-regelen, og han er kortare å lesa enn hendinga han førebyggjer.

Test familien applikasjonen faktisk brukar, fordi eit dobbeltstakka namn kan svara på den eine familien og ikkje den andre, og ein applikasjon kan byta etter ei nettverksendring. Noter adressa du testa, fordi eit resultat mot A-posten seier ingenting om AAAA-posten.

Handsam storleiksgrensa som prov

Ei gjentakbar storleiksgrense er ein av dei få nettverksfeila som reproduserer seg nøyaktig, ved same talet på byte, frå same kjelda, kvar gong. Det gjer henne til ei gåve og ikkje eit mysterium, og det tyder også at ei retting kan verifiserast i staden for å håpast på.

Skriv den oppdaga MTU-en, tunnel-MTU-en du konfigurerte og testen som provde skilnaden, inn i saka. Den neste personen vil møta den same aritmetikken på eit anna ledd.