IPv6-pakket te grut: wêrom grutte VPN-oerdrachten fêstslaan

Ping wurket, de browser laadt in lyts side, en de bestânoerdracht bliuwt hingjen, allegear oer IPv6 troch deselde tunnel. Dat patroon betsjut meast dat de stjoerder nea de wiere grutte fan it paad leard hat, net dat de tunnel stadich is. IPv6 ferwachtet dat routers it probleem mei in Packet Too Big-berjocht melde, en ynpakking foeget oerheid ta foardat in pakket ea it bûtenste netwurk berikt. Wurdt dat berjocht filtere, dan bliuwt de stjoerder in grutte werhelje dy’t net troch kin.

Lytse fersiken, grutte fêstslagen

In tunnel ynpakt elk pakket yn noch in kop, dus de brûkbere grutte binnen is lytser as de grutte bûten. In pakket dat foar de fysike keppeling mjitten wie foar ynpakking, wurdt dêrnei te grut. IPv4-routers meie ûnderweis fragmintearje, wylst IPv6-routers dat net foar de stjoerder dogge, dus de stjoerder moat sels oanpasse. En dy oanpassing hinget folslein ôf fan it ûntfangen fan de weromkeppeling.

Ien ferlern berjocht is genôch foar it klassike symptoom: hânskudden en lytse antwurden slagje, en in mapylisting of in upload bliuwt elke kear op itselde punt hingjen. Brûkers beskriuwe it as in stadige VPN, en de logs litte neat ferkeard sjen by de autentikaasje. Beide waarnimmings binne krekt, en gjinien fan beide fynt de fout.

Packet Too Big is weromkeppeling, gjin ferkear

In ICMPv6 Packet Too Big-berjocht draacht de grutte dy’t de folgjende hop oannimme kin, en de stjoerder brûkt it om syn skatting te ferleegjen. It filterje is itselde as in weiboard fuorthelje en dan de bestjoerders de skuld jaan. In regel dy’t alle ICMPv6 fuortsmyt liket strang, mar brekt paadûntdekking op elke keppeling dy’t it nedich hat. It berjocht is kontrôle-ynformaasje oer it paad, net applikaasje-fracht.

Seleksje filterje is noch altyd ridlik. Echo-fersiken en buorûntdekking spylje oare rollen as flaterberjochten, en in belied kin se oars behannelje. Folgje de dokumintearre filterrjochtlinen fan it platfoarm ynstee fan it hiele protokol te akseptearjen of fuort te smiten, want RFC 8201 bepaalt hoe’t dy weromkeppeling de ûntdekking stjoert.

Test beide adresfamyljes apart

Test IPv6 apart, want in slagge IPv4-oerdracht bewiist neat oer it IPv6-paad. Fange dan kontrôleberjochten op wylst de grutte oerdracht hinget. De twa opnamen sjen mei-inoar of de weromkeppeling fuortgiet, of bewiize dat it nea oankaam.

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'

De sonde stjoert in pakket mei de do-not-fragment-bit set en meldt de grutte wêrop’t it mislearret, it getal dat de tunnel hâlde moat. De rûtesykjefraach neamt de ynterface dy’t de bestimming drage soe, sadat jo witte hokker MTU fan ‘e keppeling jildt. De opname filteret ICMPv6 type 2, it Packet Too Big-berjocht, en lit sjen oft it dit host oait berikt. As it berjocht yn ‘e opname ferskynt en de oerdracht hinget noch, dan negearret de stjoerder it, wat it ûndersyk nei de stack ferpleatst ynstee fan it netwurk.

Feroarje de tunnengrutte pas nei de bewizen

It ferleegjen fan de MTU fan ‘e tunnel kin in filtere berjocht ferbergje en it symptoom ferdwine litte, tsjin de kosten fan mear oerheid op elk pakket. Dat is in omwei en gjin diagnoaze, en it moat de opname folgje ynstee fan dy te ferfangen. In willekeurich lege wearde brekt ek neat sichtbaars, en dêrom oerlibbet it jierren yn konfiguraasjes. Feroarje it bewust, skriuw de wearde op, en notearje hokker mjitting it rjochtfeardige.

As jo it gateway beheare, ûndersykje dan de regel dy’t it berjocht fuortsmitet ynstee fan de firewall út te skeakeljen. Ien korrizjearre regel is smeller as in beliedsútsûndering en folle makliker om letter te ferdigenjen. Deselde redenearring jildt foar time-outs: net elke hingjen is in grutteprobleem, en in opname is wat de twa skiedt.