IPv6 paket prevelik: zašto veliki VPN prenosi zapnu

Ping radi, preglednik učita malu stranicu, a prijenos datoteke zapne — sve preko IPv6 kroz isti tunel. Takav obrazac obično znači da pošiljatelj nikada nije naučio stvarnu veličinu puta, a ne da je tunel spor. IPv6 očekuje da usmjerivači prijave problem porukom Packet Too Big, a enkapsulacija dodaje dodatni teret prije nego paket uopće stigne do vanjske mreže. Ako je ta poruka filtrirana, pošiljatelj stalno ponavlja veličinu koja ne može proći.

Mali zahtjevi, velika zapinjanja

Tunel umotava svaki paket u još jedno zaglavlje, pa je korisna veličina unutra manja od veličine vani. Paket dimenzioniran za fizičku vezu prije enkapsulacije poslije postaje prevelik. IPv4 usmjerivači smiju fragmentirati na putu, dok IPv6 usmjerivači to ne čine u ime pošiljatelja, pa se pošiljatelj mora sam prilagoditi. A ta prilagodba u potpunosti zavisi od primanja povratne informacije.

Jedna izgubljena poruka dovoljna je za klasičan simptom: rukovanja i mali odgovori uspijevaju, a popis direktorija ili prijenos zapinju na istom mjestu svaki put. Korisnici to opisuju kao da je VPN spor, a zapisi ne pokazuju ništa loše u autentifikaciji. Oba zapažanja su tačna i nijedno ne locira kvar.

Packet Too Big je povratna informacija, ne promet

Poruka ICMPv6 Packet Too Big nosi veličinu koju sljedeći skok može prihvatiti, a pošiljatelj je koristi da snizi svoju procjenu. Filtrirati je isto kao ukloniti putokaz i onda kriviti vozače. Pravilo koje odbacuje sav ICMPv6 izgleda strogo, ali kvari otkrivanje puta na svakoj vezi kojoj je potrebno. Poruka je kontrolna informacija o putu, a ne korisni teret aplikacije.

Selektivno filtriranje i dalje je razumno. Zahtjevi za odjek i otkrivanje susjeda igraju drugačiju ulogu od poruka o grešci, a politika ih može tretirati drugačije. Slijedite dokumentirane smjernice platforme za filtriranje umjesto da prihvatite ili odbacite cijeli protokol, jer RFC 8201 određuje kako ta povratna informacija pokreće otkrivanje.

Testirajte obje porodice adresa odvojeno

Testirajte IPv6 zasebno, jer uspješan prijenos preko IPv4 ništa ne dokazuje o putu IPv6. Zatim snimite kontrolne poruke dok veliki prijenos zapinje. Ta dva zapisa zajedno ili pokazuju da povratna informacija odlazi, ili dokazuju da nikada nije stigla.

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'

Sonda šalje paket s postavljenim bitom za zabranu fragmentacije i prijavljuje veličinu na kojoj pada, a to je broj koji tunel mora primiti. Upit rute navodi sučelje koje bi nosilo odredište, pa znate koji MTU veze vrijedi. Snimanje filtrira ICMPv6 tip 2, poruku Packet Too Big, i pokazuje stiže li ona uopće do ovog hosta. Ako se poruka pojavi u snimci, a prijenos i dalje zapinje, pošiljatelj je ignorira, što istragu premješta u stog, a ne u mrežu.

Mijenjajte veličinu tunela samo nakon dokaza

Snižavanje MTU-a tunela može sakriti filtriranu poruku i ukloniti simptom, ali po cijeni većeg tereta na svaki paket. To je zaobilazno rješenje, a ne dijagnoza, i treba slijediti snimku umjesto da je zamijeni. Proizvoljno niska vrijednost također ništa vidljivo ne kvari, zato godinama preživljava u konfiguracijama. Mijenjajte je svjesno, zabilježite vrijednost i navedite koje je mjerenje opravdalo.

Kad kontrolirate pristupnik, pregledajte pravilo koje odbacuje poruku umjesto da isključite vatrozid. Jedno ispravljeno pravilo uže je od iznimke u politici i mnogo se lakše brani kasnije. Ista logika vrijedi i za vremenska ograničenja: nije svako zapinjanje problem veličine, a snimka je ono što razdvaja dvoje.