Az IPv6 IPv4-es VPN-kiszolgálón át is valódi IPv6-kimenetet igényel

Az alagút feljön, a kliens IPv6-címet kap a poolból, és minden IPv6-cél mégis időtúllépésbe fut. Az alagútban semmi sem romlott el: az IPv6 tökéletesen utazik az IPv4-szállításban, és ez soha nem volt a nehéz rész. A kiosztott cím ígéret, amit a kiszolgáló nem tud betartani, mert a kimenetnek nincs IPv6-upstreamje, ahová küldhetné. A javítás a kimenethez tartozik, nem a kliensprofilba.

A tünet: cím és semmi útvonal

Az ügyféloldali ellenőrzés globálisnak látszó IPv6-címet mutat az alagúteszközön és egy arra mutató útvonalat, ezért ezt tévesen klienshibaként olvassák. A forgalom belép az alagútba, a kiszolgáló kicsomagolja, majd a csomag olyan gazdagépre kerül, amelynek útválasztási táblázatában nincs IPv6-alapértelmezett útvonal egyetlen valódi hely felé sem. A stacktől függően azonnali elérhetetlenséget vagy csendes eldobást kapsz, és mindkét esetben a kliens egy tűzfalszerű időtúllépést lát.

Olvasd el a kiszolgáló saját útválasztási táblázatát, mielőtt a klienshez nyúlsz, mert az útvonal hiányzó fele ott lakik. Egyetlen IPv4-alapértelmezett útvonallal rendelkező kiszolgáló már megadta a választ.

Kövesd a csomagot a kicsomagolás után

Az alagúton belül a csomag közönséges IPv6, forrása pedig a kliens címe. A kiszolgáló lehúzza a szállítási beágyazást, és ekkor egy natív IPv6-csomagot tart, amelyet a következő IPv6-ugrásnak kell továbbítani. Egy IPv4-alapértelmezett útvonal nem tudja elvinni, és IPv4-re fordítani más funkció, amelyet senki nem telepített. Ez az egész hiba, és semmi köze ahhoz, hogy a VPN-figyelő IPv4-en keresztül válaszolt-e.

Az IPv6 IPv4 fölé ágyazásának mechanikáját az RFC 4213 írja le, és az ottani fontos részlet, hogy a végpontoknak továbbra is valódi IPv6-kapcsolat kell az alagút túloldalán. A fejléc beburkolása nem varázsol upstreamet a semmiből.

Két alagútréteg, két független ellenőrzés

Ellenőrizd külön-külön mindegyik réteget, mert egy működő külső alagút elrejti a törött belsőt. Ellenőrizd a külső útvonalat IPv4-pinggel a klienstől a kiszolgálóig, és igazold a használt portot. Utána ellenőrizd a belső útvonalat a kiszolgálón, ahol ip -6 route alapértelmezett vagy valódi upstreamtől tanult konkrét útvonalat kell mutatnia, és ip -6 addr olyan forrás-prefixet kell mutatnia, amelyet az upstream elfogad. Ennél kevesebb csak díszítés az interfészen.

Egy egyedi-helyi cím, vagy egy globálisnak látszó prefix, amelyhez semmi nem irányít vissza, boldogan megjelenik egy interfészen, és sehová nem megy. A nyilvános elérhetőséget az upstream adja, nem a cím alakja.

Ugyanez igaz a kliensnél: ip -6 route get 2001:4860:4860::8888 az alagúteszközt kellene megneveznie, és ha a fizikait nevezi meg, a kliens egyáltalán nem használja a VPN-t IPv6-hoz.

Forrás-prefix, méret és ICMPv6

Kérdezd meg az upstreamet, milyen forrás-prefixeket fogad el továbbításra, és használd egyiküket a klienspoolhoz. Egy szolgáltató, aki /64-et ad a kiszolgáló saját interfészére, nem feltétlenül irányít hozzád egy második /64-et vagy nagyobb blokkot, és a különbség egy délutánnyi hibakeresés, amelyet egy támogatói jegy egyetlen kérdéssel rendez. Kérdezd írásban, és tartsd a választ a konfiguráció mellett.

Számolj a plusz beágyazással, amelyet a stack valóban használ, és tartsd működőképesen az ICMPv6-ot, a Packet Too Big-et is beleértve. Egy második fejléc csökkenti a hasznos terhet, így egy kis pingekre válaszoló útvonal fájlátvitelnél mégis elbukhat, és egy tűzfal, amely minden ICMPv6-ot eldob, javítható mérethatásból fekete lyukat csinál. Tesztelj egy nagy átvitelt, mielőtt bejelented a szolgáltatást.

Mi számít teljesen más problémának

Egy csak IPv4-es alkalmazás elérése csak IPv6-os kliensről fordítás, nem alagutazás, és valami szándékosan telepített NAT64-megoldáshoz hasonló kell hozzá. A cél nem fog megérteni egy plusz alagútfejlécet csak azért, mert hozzátettél egyet. A történelmi átmeneti szolgáltatások ugyanilyen gondosságot érdemelnek: az RFC 7526 megszüntette a 6to4 anycast relay modellt, ezért a köré írt útmutató olyat ír le, aminek már nincs karbantartott nyilvános relayje.

Ha a kiszolgálónak nincs használható IPv6-upstreamje, a választások egy támogatott upstream, egy másik kimenet vagy egy dokumentált döntés arról, hogy az IPv6 az alagúton kívül marad. Az nem elfogadható, hogy azt mondjuk a klienseknek, létezik IPv6-szolgáltatás, miközben a szokásos IPv6-kapcsolatuk csendben megkerüli a VPN-t.