IPv6 OpenVPN-alagúton át: körjárat az otthoni routeren

A laptopnak van IPv6-címe, az alagút IPv4 felett fut, és mégis minden IPv6-teszt elbukik. Vagy ami még rosszabb: a teszt sikerül, és a forgalom a szolgáltató útvonalán távozott anélkül, hogy valaha belépett volna az alagútba. Mindkét kimenet egyetlen hiányzó döntésre vezethető vissza: senki nem adott a routernek olyan előtagot, amelyet az ügyfelek felé tudna irányítani. Ha az ügyféltől kifelé haladva bejárjuk az útvonalat, megtaláljuk, melyik darab hiányzik.

Kezdje ott, ahol az ügyfél van

Nézze meg az ügyfelet, mielőtt hozzányúl a szerverhez. A ip -6 addr-nak a poolból származó alagútcímet kell mutatnia, a ip -6 route-nak pedig az alagúteszköz felé mutató, betolt előtagot. Ha a cím megvan, de az útvonal nem, akkor a push hiányzik, vagy az ügyfél figyelmen kívül hagyta. Ha egyik sincs meg, a szerver egyáltalán nem osztott ki semmit.

Ezután ellenőrizze, mit gondol az ügyfél a külvilágról. Az alagúton át vezető alapértelmezett útvonal minden IPv6-forgalmat igényel, míg a 2000::/3 felé vezető útvonal csak a globális unicastot. Mindkettő helyes lehet, és más-más kérdésre válaszolnak a szivárgással kapcsolatban.

Az az ügyfél, amelynek egyáltalán nincs IPv6-os alapértelmezett útvonala, minden nyilvános teszten elbukik, miközben maga az alagút teljesen egészséges. Ez szakpolitikai rés, nem törött alagút.

Ellenőrizze a poolt, amelyet a szerver valóban tud irányítani

A szerver csak olyan előtagból oszthat ki, amelyet valóban ellenőriz. Ha a szolgáltató /56-ot delegál, tartson fenn egy /64-et az alagútnak, a többit pedig hagyja a LAN-nak. Ahol a szolgáltató a WAN-on csak egyetlen /64-et ad át, és semmi mást nem irányít, hagyja békén a LAN előtagját, és adjon az alagútnak egyedi helyi tartományt, elfogadva, hogy az ügyfeleknek nem lesz globális kijáratuk.

A pool és a push együtt jár. A server-ipv6 2001:db8:80:10::/64 címeket oszt ki, a push "route-ipv6 2000::/3" pedig megmondja az ügyfeleknek, mit küldjenek az alagútba. A 2000::/3 betolása lefedi a globális unicastot, és kívül hagyja az alagúton a link-local és multicast tartományokat.

Írja be a választott előtagot az üzembe helyezési jegyzőkönyvbe. A következő, aki módosítja a szolgáltatói átadást, tudni fogja, melyik /64-et foglalja már az alagút.

Kapcsolja be az átirányítást a második családhoz

Az IPv4 átirányítás nem jelenti az IPv6 átirányítását. Állítsa be a net.ipv6.conf.all.forwarding=1-ot, és tükrözze mindazt, amit az IPv4 FORWARD-szabályzat már engedélyez. Egy olyan routeren, amelynek FORWARD-lánca alapértelmezés szerint eldob, a hiányzó szabálykészlet pontosan úgy néz ki, mint egy halott alagút.

A kézfogás sikerül, az ügyfél címet kap, és semmi nem jön vissza. Adjon hozzá szabályokat mindkét irányra és a WAN-szakaszra, mert az az alagút, amely eléri a LAN-t, de az internetet nem, elbukik a harmadik teszten. Sikertelen kísérlet után nézze meg a lánc számlálóit, mert egy soha nem egyező szabály más probléma, mint egy egyező és eldobó.

ip6tables -A FORWARD -i br0 -o tun0 -j ACCEPT
ip6tables -A FORWARD -i tun0 -o br0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
ip6tables -A FORWARD -i tun0 -o wan0 -j ACCEPT

Egy mellékhatás elkapja azokat, akik végül az alagutat hibáztatják. Az átirányítás bekapcsolása után a kernel kihagyja a Router Advertisementen alapuló címkonfigurációt, hacsak nem mondja másképp, és az így tanult alapértelmezett útvonal eltűnik vele együtt. Vagy rögzítsen egy kifejezett alapértelmezett útvonalat a WAN-interfészen, vagy állítsa ott szándékosan 2-re a accept_ra-ot. Bármelyik változtatás után erősítse meg, hogy a routernek még mindig van használható IPv6-os kifelé vezető útja, mielőtt újra teszteli az ügyfeleket.

Válaszoljon a szomszédok felderítésére, ha a felső szakasz nem irányít

A felsőbb berendezés néha úgy kezeli a delegált /64-et, mintha a saját kapcsolatához tartozna, és megtagadja bármely al-előtag átirányítását a VPN-doboz felé. Amikor ez megtörténik, valaminek válaszolnia kell minden ügyfélcímre külön-külön a szomszédkérelmekre.

OpenVPN a kiosztott címet egy client-connect hook elé tárja, így a bejegyzések a valódi poolt követhetik a kézzel karbantartott lista helyett. A hook hozzáadja a ip -6 neigh add proxy $ifconfig_pool_remote_ip6 dev eth0-ot, a megfelelő client-disconnect hook pedig eltávolítja. Eltávolítás nélkül a proxy tábla elavul, és egy későbbi ügyfél örökölhet egy bejegyzést egy olyan címhez, amelyet soha nem kapott meg. Erősítse meg az állapotot a ip -6 neigh show proxy segítségével.

Tekintse a proxyt kerülő megoldásnak. Az alagút /64-éhez a router felé irányított statikus útvonal túléli az ügyfélcseréket, és egyáltalán nem igényel jogosultságokkal rendelkező shell-hookot.

Kövesse az utat kifelé, ugrásról ugrásra

Három lépésben teszteljen kifelé: először a router alagútcímét, aztán egy LAN-gazdát, harmadikként pedig egy nyilvános célállomást traceroute6-tal. A poolt az első bizonyítja, az átirányítást és a LAN tűzfalát a második, a felső szakaszon át vezető visszautat a harmadik. Minden kudarc egyetlen eszközre szűkíti a keresést, ahelyett hogy újra megnyitná az egész tervezést.

Figyelje az alagút MTU-ját, mert az útvonalon lévő IPv6-os routerek nem darabolják helyette. A túl nagy MTU packet-too-big hibaként és elakadt TLS-ként jelenik meg, nem tiszta kudarcként. Állítsa be kifejezetten, és teszteljen a határértékhez közeli terheléssel.