IPv4 razdrobi med potjo; IPv6 namesto tega pošlje sporočilo o prevelikem paketu

Napake IPv6 se veliko pogosteje pripišejo protokolu kot velikosti paketa, ki jih je povzročila. Družini resnično različno ravnata s prevelikim paketom in prav tunel naredi to razliko pomembno. Usmerjevalniki IPv4 smejo razdrobiti paket, ko pravila to dovoljujejo, medtem ko usmerjevalniki IPv6 med potjo ne smejo razdrobiti sploh. IPv6 namesto tega to pove pošiljatelju in od pošiljatelja se pričakuje odziv. Vse, kar gre nato narobe, izhaja iz tega, ali to sporočilo prispe.

Kaj počne vsaka družina

Tabela je mehanizem v štirih vrsticah in ena vrstica pojasni večino zmede.

IPv6 nima razdrobitve med potjo in nima zastavice DF za počistiti, zato ni ničesar, na kar bi se oprli, ko je paket prevelik. Pošiljatelju je treba povedati in pošiljatelj mora to verjeti.

Tunel tiho zoži pot

VPN doda zunanje glave, v šifriranem primeru pa tudi podatke o celovitosti, preden paket zapusti gostitelja. Notranji paket se lahko prilega MTU vmesnika, ki ga vidi, medtem ko zunanji paket preseže mejo naslednje povezave, in zato se to najprej pokaže v tunelu. Namerno znižajte MTU tunelskega vmesnika ali na poti stisnite TCP MSS in zapišite, katero število ste izbrali in zakaj.

Stroški ESP so odvisni od načina in algoritmov, zato je pravilna MTU tunela izračun in ne dogovor. Karkoli izberete, mora pustiti prostor za celoten notranji paket IPv6 velikosti 1280 bajtov, ker mora vsaka povezava IPv6 toliko prenesti. Tunel, ki ne more prenesti 1280 bajtov IPv6, ni težava z nastavitvami; je zlomljena pot za to družino. Prav ta omejitev izgine, ko se vrednost MTU kopira iz postavitve samo z IPv4.

Zakaj je simptom zataknitev

Napaka ni čista napaka, zato je napačno diagnosticirana. Rokovanje TCP se zaključi, majhni odgovori prispejo, povezava pa se ustavi takoj, ko se začne velik odgovor ali množično nalaganje, ker so to prvi paketi, dovolj veliki, da jih zavržejo. SSH se poveže in nato obtiči na prvem velikem izhodu, glava strani pa se naloži, medtem ko se telo nikoli ne konča.

Če so sporočila ICMPv6 o prevelikem paketu filtrirana, pošiljatelj tega nikoli ne izve in kar naprej poskuša isto velikost. To je črna luknja in ne počasna pot, njen podpis pa je ponovljiva meja velikosti in ne naključna izguba. Dovoliti ustrezni nadzorni promet je del delujoče postavitve IPv6, ne vljudnost.

Ne izklapljajte sporočil, od katerih je odvisna vaša lastna pot, in nato rezultata ne opisujte kot okvaro IPv6. Isti argument velja za sporočila Fragmentation Needed pri IPv4, ki so pri avtorjih požarnih zidov enako nepriljubljena in enako potrebna.

Izmerite mejo in nato popravite plast

Preverjajte, namesto da ugibate: uporabite zastavico don't-fragment pri IPv4 in fiksne velikosti tovora pri IPv6 ter zapišite, kje se odgovori ustavijo. ping -M do -s 1472 in ping -6 -s 1400 zadostujeta za določitev oblike težave, tracepath pa poroča o odkriti MTU poti na poti.

Nato popravite plast, ki ima to število: MTU tunelskega vmesnika, stiskanje MSS za TCP ali pot samo. RFC 8200 je referenca za pravilo IPv6 in bere se krajše kot incident, ki ga preprečuje.

Preizkusite družino, ki jo aplikacija dejansko uporablja, ker ime z dvojnim skladom lahko odgovori na eni družini in ne na drugi, aplikacija pa se lahko po spremembi omrežja preklopi. Zapišite naslov, ki ste ga preizkusili, ker rezultat proti zapisu A ne pove ničesar o zapisu AAAA.

Mejo velikosti obravnavajte kot dokaz

Ponovljiva meja velikosti je ena redkih omrežnih napak, ki se ponovi natančno, pri enakem številu bajtov, iz istega vira, vsakič. Zato je darilo in ne uganka, pomeni pa tudi, da je popravilo mogoče preveriti, namesto da bi upali.

V zahtevek zapišite odkrito MTU, konfigurirano MTU tunela in preizkus, ki je dokazal razliko. Naslednja oseba bo naletela na isto aritmetiko na drugi povezavi.