A /64 felosztása nem irányítja az IPv6-ot a VPN-kliensekhez

A kliens globális IPv6-címet mutat, a kézfogás befejeződött, és semmi sem jön vissza az internetről. A pool beállítása helyesnek tűnik, mert helyes; a cím érvényes, és az alagút szállítja. Ami meghiúsul, az a kézbesítés, és a kézbesítés egy olyan döntéstől függ, amelyet a VPN-kiszolgáló felett hoztak, és amelyre semmilyen kliensoldali konfiguráció nem hathat.

A mítosz: a /64 egy darabja már elérhető

A történet vonzó: a kiszolgálónak van egy nyilvános /64, vágja ketté, adja a másik felét a VPN-poolnak, és ezek a kliensek máris az interneten vannak. Az előtag felosztása valóban ütközésmentesen oszt ki címeket. De nem változtat azon, hogyan dönti el az upstream hálózat, hova menjen az egyik ilyen címre szóló csomag.

Az IPv6-nak nincs alapértelmezett fordítási rétege, amelyre támaszkodhatna, ezért a visszaútnak útválasztásként vagy kapcsolatszintű kézbesítésként kell léteznie. Az ügyfél alagút-címére címzett csomag megérkezik az upstream útválasztóhoz, és ez az útválasztó a saját táblájából hoz továbbítási döntést. Ha a tábla a fizikai kapcsolatra mutat, a csomag oda megy, függetlenül attól, mit gondol a VPN-kiszolgálója.

Ez az egész hiba: az előre irány működik, mert a kiszolgálója küldi, a visszirány pedig egy ugrásnyira meghal, mert az upstream soha nem tudta meg, hogy a kliens létezik.

Mit igényel valójában a kapcsolaton történő kézbesítés

Amikor az upstream az egész /64-et a fizikai kapcsolaton lévőnek tekinti, minden célcímet szomszéd-felderítéssel old fel. Egy kérést küld ezen a kapcsolaton, és elvárja, hogy a cím tulajdonosa válaszoljon. Az alagút mögött ülő VPN-kliens nincs ezen a kapcsolaton, és nem tud válaszolni, ezért a kérés válasz nélkül marad, és a csomagot eldobják.

A /65 kivágása nem változtat ezen az elváráson. Az upstream továbbra is kapcsolaton lévőnek tekinti a tartományt, mert az egyetlen dolog, ami meggondolná, egy útvonal vagy egy proxy, amely az ügyfél nevében válaszol. Egyik sem jelenik meg, mert Ön szerkesztett egy VPN-konfigurációt. Pont ez a szakadék magyarázza, hogy egy pool miért működhet tökéletesen a saját kliensei között, és miért maradhat mégis elérhetetlen minden más helyről.

A proxy szomszéd-felderítés az a mechanizmus, amely hidat verhet a két világ között. Az átjáró válaszol azokra a kérésekre, amelyek a birtokában lévő konkrét ügyfélcímekre vonatkoznak, és továbbítja a forgalmat az alagútba. Működik, és pontosan ezekre a címekre kell korlátozni, olyan életciklussal, amely követi a poolt, mert ha olyan címre válaszol, amelyet már nem szolgál ki, valaki más forgalmát fekete lyukká teszi. Egyes upstream hálózatok nem fogadják el azokat a proxy válaszokat, amelyekre nem számítottak, ezért ehhez a tervhez a szolgáltató beleegyezése is kell.

Mit igényel az útválasztott kézbesítés

A tisztább terv egy olyan kiosztás, amelyet az upstream valóban az átjárójához irányít. Ez lehet delegált előtag vagy statikus útvonal egy kisebb blokkhoz, és a követelmény mindkét esetben ugyanaz: az upstream táblájának az Ön kiszolgálójára kell mutatnia az ügyfél-tartományhoz. Ezután a visszirányú forgalom megérkezik az átjáróhoz, és az átjáró továbbítja az alagútba.

Az útválasztott kézbesítés teljesen megszünteti a szomszéd-felderítés kérdését, ezért érdemes ezt kérni a szolgáltatótól, mielőtt bármi ravaszat építene. Kérje írásban az útvonalat, és erősítse meg, hogy a következő ugrás az a cím, amelyet az upstream valóban elér.

Mindkét tervhez továbbra is szükség van az IPv6-továbbítás engedélyezésére az átjárón, valamint tűzfal-szabályokra, amelyek engedélyezik a továbbított folyamot mindkét irányban. A kézbesítés előfeltétel, nem helyettesítője az útvonal többi részének. Egy működő útvonal kikapcsolt továbbítással pontosan ugyanazt a csendet eredményezi, mint egy hiányzó útvonal, ezért mindkettőt ellenőrizze, mielőtt bármit újratervezne.

Két független útvonal, amit jól kell beállítani

A pool előtagja és az ügyfél saját alapértelmezett útvonala külön beállítások, és összekeverésük részleges kapcsolódást eredményez, amely törött alagútnak látszik. A pool megmondja a kiszolgálónak, mely címeket ossza ki. Az ügyfél útvonalai döntik el, hogy az ügyfél mely célokra küld egyáltalán forgalmat az alagútba.

server-ipv6 2001:db8:42:100::/64
push "redirect-gateway ipv6 !ipv4"

A fenti előtag dokumentációs tér, és az átirányítás csak az IPv6-ra vonatkozik, ami pontosan az, amit egy kettős verem telepítés gyakran szeretne, amíg az IPv6-kézbesítés még javítás alatt áll. Az IPv4-átirányítás nem teremt IPv6-lefedettséget, és egyik beállítás sem feltételezi a másikat.

Tartsa működőképesen az IPv6 által igényelt vezérlőforgalmat, bármilyen szabályzatot is alkalmaz. A Packet Too Big üzenetek a csak TCP-t és UDP-t engedélyező tűzfal klasszikus áldozatai, és eldobásuk olyan kapcsolatokat hoz létre, amelyek létrejönnek, majd a nagyobb átviteleknél elakadnak.

Az útválasztó-hirdetések a harmadik mozgó alkatrész. Ha az átjáró elkezd hirdetni a felső kapcsolaton, az megváltoztathatja, hogy mit hisznek a kliensek és a szomszédok a kapcsolaton lévő előtagokról, ami csendesen érvénytelenítheti az imént dokumentált tervet.

Rögzítse a tervet, hogy egy újjáépítés reprodukálja

Írjon le három objektumot külön: az ügyfél kiosztását, az ügyfél célútvonalát és az upstream kézbesítési módszerét a kiosztáshoz. Az az olvasó, aki mindhárommal rendelkezik, újraépítheti a telepítést; az az olvasó, akinek csak a pool beállítása van, az eredeti hibát fogja reprodukálni.

Ezután kifejezetten tesztelje a visszirányt egy olyan csomaggal, amelynek kívülről vissza kell érkeznie. Az openvpn(8) kézikönyv lefedi a server-ipv6 és a redirect opciókat, az Ön szolgáltatójának útválasztási visszaigazolása pedig lefedi azt a felét, amelyet a kézikönyv nem tud.