IPv4 fragmentira u tranzitu; IPv6 umjesto toga šalje poruku o prevelikom paketu

IPv6 kvarovi se mnogo češće pripisuju protokolu nego veličini paketa koja ih je izazvala. Dvije porodice zaista različito postupaju s prevelikim paketom, a tunel je ono zbog čega ta razlika postaje važna. IPv4 ruteri smiju fragmentirati paket kada pravila to dozvoljavaju, dok IPv6 ruteri ne smiju fragmentirati u tranzitu nikako. IPv6 to umjesto toga kaže pošiljaocu, a od pošiljaoca se očekuje da reaguje. Sve što poslije pođe po zlu proizlazi iz toga da li ta poruka stigne.

Šta svaka porodica radi

Tabela je mehanizam u četiri reda, a jedan red objašnjava većinu zabune.

IPv6 nema fragmentaciju u tranzitu niti DF zastavicu koju treba očistiti, pa nema na šta da se vrati kada je paket prevelik. Pošiljaocu se mora reći, a pošiljalac mora u to vjerovati.

Tunel tiho sužava put

VPN dodaje vanjska zaglavlja, a u šifrovanom slučaju i podatke integriteta, prije nego paket napusti host. Unutrašnji paket može stati u MTU interfejsa koji vidi, dok vanjski paket prelazi ograničenje sljedeće veze, i zato se to prvo pojavljuje u tunelu. Namjerno snizite MTU tunelskog interfejsa ili stisnite TCP MSS na putu, i zapišite koji broj ste odabrali i zašto.

ESP trošak zavisi od režima i algoritama, pa je ispravan MTU tunela proračun, a ne konvencija. Šta god odabrali, mora ostaviti mjesta za pun unutrašnji IPv6 paket od 1280 bajtova, jer svaka IPv6 veza mora nositi toliko. Tunel koji ne može nositi 1280 bajtova IPv6 nije problem podešavanja; to je pokvaren put za tu porodicu. Upravo to ograničenje nestaje kada se vrijednost MTU kopira iz postavke samo za IPv4.

Zašto se simptom pokazuje kao zastoj

Kvar nije čista greška, i zato se pogrešno dijagnostikuje. TCP rukovanje se završi, mali odgovori stignu, a veza se zaglavi čim počne veliki odgovor ili veliko prebacivanje, jer su to prvi paketi dovoljno veliki da budu odbačeni. SSH se poveže i zatim se zaglavi na prvom velikom izlazu, a zaglavlje stranice se učita dok tijelo nikada ne završi.

Ako se ICMPv6 poruke o prevelikom paketu filtriraju, pošiljalac nikada ne sazna i stalno ponavlja istu veličinu. To je crna rupa, a ne spor put, i njen potpis je ponovljiva veličinska granica, a ne slučajan gubitak. Dozvoliti odgovarajući kontrolni saobraćaj dio je ispravne IPv6 postavke, a ne usluga.

Ne isključujte poruke od kojih zavisi vaš vlastiti put i zatim rezultat ne opisujte kao IPv6 kvar. Isti argument vrijedi za IPv4 poruke Fragmentation Needed, koje su jednako nepopularne kod autora firewall-a i jednako neophodne.

Izmjerite granicu, a zatim popravite sloj

Provjeravajte umjesto da nagađate: koristite don't-fragment zastavicu na IPv4 i fiksne veličine tereta na IPv6, i zabilježite gdje se odgovori zaustavljaju. ping -M do -s 1472 i ping -6 -s 1400 dovoljni su da utvrde oblik problema, a tracepath prijavljuje otkriveni MTU puta duž trase.

Zatim popravite sloj koji posjeduje broj: MTU tunelskog interfejsa, MSS stiskanje za TCP ili sam put. RFC 8200 je referenca za IPv6 pravilo, i kraće se čita od incidenta koji sprečava.

Testirajte porodicu koju aplikacija stvarno koristi, jer ime s dva steka može odgovoriti na jednoj porodici, a ne na drugoj, a aplikacija može preći nakon promjene mreže. Zapišite adresu koju ste testirali, jer rezultat prema A zapisu ne govori ništa o AAAA zapisu.

Tretirajte veličinsku granicu kao dokaz

Ponovljiva veličinska granica jedna je od rijetkih mrežnih kvarova koji se tačno reprodukuje, pri istom broju bajtova, sa istog izvora, svaki put. To je čini darom, a ne misterijom, i takođe znači da se popravka može provjeriti umjesto da se u nju nada.

Upišite u tiket otkriveni MTU, MTU tunela koji ste konfigurisali i test koji je dokazao razliku. Sljedeća osoba će sresti istu aritmetiku na drugoj vezi.