Pārāk liels IPv6 pakets: kāpēc lieli VPN pārsūtījumi apstājas

Ping darbojas, pārlūks ielādē mazu lapu, bet faila pārsūtīšana apstājas — tas viss IPv6 ietvaros caur vienu tuneli. Šis modelis parasti nozīmē, ka sūtītājs nekad nav uzzinājis īsto ceļa lielumu, nevis to, ka tunelis ir lēns. IPv6 sagaida, ka maršrutētāji ziņos par problēmu ar Packet Too Big ziņojumu, un iekapsulēšana pievieno papildu izmaksas, pirms pakete vispār sasniedz ārējo tīklu. Ja šis ziņojums tiek filtrēts, sūtītājs turpina atkārtot izmēru, kas nevar iziet cauri.

Mazi pieprasījumi, lieli apstāšanās gadījumi

Tunelis iesaiņo katru paketi vēl vienā galvenē, tāpēc izmantojamais izmērs iekšpusē ir mazāks par izmēru ārpusē. Pakete, kas pirms iekapsulēšanas tika pielāgota fiziskajam posmam, pēc tam kļūst pārāk liela. IPv4 maršrutētāji drīkst fragmentēt ceļā, bet IPv6 maršrutētāji to nedara sūtītāja vārdā, tāpēc sūtītājam pašam jāpielāgojas. Un šī pielāgošanās pilnībā ir atkarīga no atgriezeniskās saites saņemšanas.

Ar vienu pazaudētu ziņojumu pietiek klasiskajai pazīmei: rokas spiedieni un mazas atbildes izdodas, bet direktoriju saraksts vai augšupielāde katru reizi apstājas tajā pašā vietā. Lietotāji to raksturo kā lēnu VPN, un žurnāli neuzrāda neko nepareizu autentifikācijā. Abi novērojumi ir precīzi, un neviens no tiem neatrod kļūmes vietu.

Packet Too Big ir atgriezeniskā saite, nevis plūsma

ICMPv6 Packet Too Big ziņojums nes izmēru, ko var pieņemt nākamais lēciens, un sūtītājs to izmanto, lai samazinātu savu aplēsi. To filtrēt ir tas pats, kas noņemt ceļa zīmi un pēc tam vainot šoferus. Noteikums, kas izmet visu ICMPv6, izskatās stingrs, bet salauž ceļa atklāšanu katrā savienojumā, kuram tas nepieciešams. Ziņojums ir kontroles informācija par ceļu, nevis lietojumprogrammas derīgā slodze.

Selektīva filtrēšana joprojām ir saprātīga. Atbalss pieprasījumi un kaimiņu atklāšana pilda citu lomu nekā kļūdu ziņojumi, un politika var pret tiem izturēties citādi. Ievērojiet platformas dokumentētās filtrēšanas vadlīnijas, nevis pieņemiet vai atmetiet visu protokolu, jo RFC 8201 nosaka, kā šī atgriezeniskā saite virza atklāšanu.

Pārbaudiet abas adrešu saimes atsevišķi

Pārbaudiet IPv6 atsevišķi, jo veiksmīga IPv4 pārsūtīšana neko nepierāda par IPv6 ceļu. Pēc tam ierakstiet kontroles ziņojumus, kamēr lielais pārsūtījums apstājas. Abi ieraksti kopā vai nu parāda, ka atgriezeniskā saite iziet, vai pierāda, ka tā nekad nav ieradusies.

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'

Zonde sūta paketi ar iestatītu do-not-fragment bitu un ziņo par izmēru, kurā tā neizdodas, — tas ir skaitlis, kas tunelim jāietur. Maršruta vaicājums nosauc saskarni, kas nestu galamērķi, tāpēc jūs zināt, kurš posma MTU ir spēkā. Uztveršana filtrē ICMPv6 tipa 2 ziņojumu, Packet Too Big, un parāda, vai tas vispār sasniedz šo resursdatoru. Ja ziņojums parādās uztveršanā un pārsūtīšana joprojām apstājas, sūtītājs to ignorē, kas izmeklēšanu pārceļ uz steku, nevis uz tīklu.

Mainiet tuneļa izmēru tikai pēc pierādījumiem

Tuneļa MTU samazināšana var paslēpt filtrētu ziņojumu un likt pazīmei pazust, taču par cenu — lielākas izmaksas uz katru paketi. Tas ir apietais ceļš, nevis diagnoze, un tam jāseko pēc uztveršanas, nevis jāaizstāj tā. Patvaļīgi zema vērtība arī neko redzami nesalauž, tāpēc tā konfigurācijās izdzīvo gadiem. Mainiet to apzināti, pierakstiet vērtību un atzīmējiet, kurš mērījums to attaisnoja.

Ja jūs pārvaldāt vārteju, pārbaudiet noteikumu, kas izmet ziņojumu, nevis izslēdziet ugunsmūri. Viens labots noteikums ir šaurāks par politikas izņēmumu un vēlāk daudz vieglāk aizstāvams. Tā pati loģika attiecas uz taimautiem: ne katrs apstājums ir izmēra problēma, un tieši uztveršana šos divus atdala.