Túl nagy IPv6-csomag: miért akadnak meg a nagy VPN-átvitelek

A ping működik, a böngésző betölt egy kis oldalt, a fájlátvitel pedig megakad — mindez IPv6-on keresztül, ugyanazon az alagúton. Ez a minta általában azt jelenti, hogy a küldő soha nem tanulta meg az útvonal valódi méretét, nem pedig azt, hogy az alagút lassú. Az IPv6 elvárja, hogy az útválasztók Packet Too Big üzenettel jelentsék a problémát, és a beágyazás többletterhet ad, mielőtt a csomag egyáltalán elérné a külső hálózatot. Ha ezt az üzenetet szűrik, a küldő továbbra is olyan méretet ismétel, amely nem tud átjutni.

Kis kérések, nagy akadások

Az alagút minden csomagot egy újabb fejlécbe csomagol, ezért a belül használható méret kisebb, mint a kívüli méret. Egy csomag, amelyet a fizikai kapcsolathoz méreteztek a beágyazás előtt, utána túl naggyá válik. Az IPv4-útválasztók töredezhetnek az útvonalon, az IPv6-útválasztók viszont nem teszik ezt a küldő helyett, ezért a küldőnek kell alkalmazkodnia. És ez az alkalmazkodás teljesen a visszajelzés megérkezésétől függ.

Egyetlen elveszett üzenet is elég a klasszikus tünethez: a kézfogások és a kis válaszok sikerülnek, a könyvtárlista vagy a feltöltés pedig minden alkalommal ugyanazon a ponton akad meg. A felhasználók lassú VPN-ként írják le, a naplók pedig semmi hibát nem mutatnak a hitelesítésnél. Mindkét megfigyelés pontos, és egyik sem találja meg a hibát.

A Packet Too Big visszajelzés, nem forgalom

Az ICMPv6 Packet Too Big üzenet azt a méretet hordozza, amelyet a következő ugrás elfogadhat, és a küldő ezzel csökkenti a becslését. Szűrni olyan, mintha eltávolítanánk egy útjelző táblát, majd a sofőröket hibáztatnánk. Az a szabály, amely minden ICMPv6-ot eldob, szigorúnak tűnik, miközben megtöri az útvonalfelfedezést minden kapcsolaton, amelynek szüksége van rá. Az üzenet az útvonalra vonatkozó vezérlőinformáció, nem alkalmazási adat.

A szelektív szűrés továbbra is ésszerű. Az echo-kérések és a szomszédfelfedezés más szerepet játszanak, mint a hibaüzenetek, és egy szabályzat másképp kezelheti őket. Kövesse a platform dokumentált szűrési útmutatását, ahelyett hogy a teljes protokollt elfogadná vagy eldobná, mert az RFC 8201 határozza meg, hogyan vezérli ez a visszajelzés a felfedezést.

Tesztelje a két címcsaládot külön-külön

Tesztelje külön az IPv6-ot, mert a sikeres IPv4-átvitel semmit sem bizonyít az IPv6-útvonalról. Ezután rögzítse a vezérlőüzeneteket, miközben a nagy átvitel megakad. A két felvétel együtt vagy azt mutatja, hogy a visszajelzés kifelé tart, vagy azt bizonyítja, hogy soha nem érkezett meg.

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'

A próba egy csomagot küld beállított do-not-fragment bittel, és jelenti azt a méretet, amelynél meghiúsul — ez az a szám, amelyet az alagútnak el kell viselnie. Az útvonal-lekérdezés megnevezi azt az interfészt, amely a célt szállítaná, így tudja, melyik kapcsolat MTU-ja érvényes. A rögzítés az ICMPv6 2-es típusát, a Packet Too Big üzenetet szűri, és megmutatja, hogy eljut-e egyáltalán erre a gazdagépre. Ha az üzenet megjelenik a felvételen, és az átvitel továbbra is megakad, a küldő figyelmen kívül hagyja, ami a vizsgálatot a verembe tereli a hálózat helyett.

Csak a bizonyítékok után módosítsa az alagút méretét

Az alagút MTU-jának csökkentése elrejthet egy szűrt üzenetet, és eltüntetheti a tünetet, cserébe minden csomag nagyobb többletterhéért. Ez megkerülő megoldás, nem diagnózis, és a felvételt kell követnie, nem helyettesítenie. Az önkényesen alacsony érték sem tör el semmi láthatót, ezért él túl évekig a konfigurációkban. Szándékosan módosítsa, jegyezze fel az értéket, és írja le, melyik mérés indokolta.

Amikor Ön kezeli az átjárót, vizsgálja meg azt a szabályt, amely eldobja az üzenetet, ahelyett hogy kikapcsolná a tűzfalat. Egy javított szabály szűkebb, mint egy szabályzati kivétel, és később sokkal könnyebb megvédeni. Ugyanez a gondolatmenet érvényes az időtúllépésekre: nem minden akadás méretprobléma, és a felvétel az, ami kettéválasztja őket.