Privát IPv6 hozzáadása egy OpenVPN-laborhoz, egyszerre egy ellenőrzési pontot

Már van egy kliense, amely IPv4-en kapcsolódik, és eléri a kiszolgáló mögötti privát IPv4-munkaterhelést. A cél, hogy ugyanazon az alagúton elérjen egy privát IPv6-munkaterhelést anélkül, hogy hozzányúlna a külső szállításhoz. Ez a sorrend számít: a külső útvonal IPv4 marad, és csak a belső címterv, a kliens útvonala és a kiszolgálótól a LAN felé vezető visszaút változik. Öt ellenőrzési pont, mindegyiknél valami konkrét, amit érdemes megnézni, mielőtt továbblép.

Első ellenőrzési pont: a kapcsolat, amely már működik

Csatlakoztassa a klienst, és erősítse meg az IPv4-útvonalat, mielőtt bármit hozzáadna. Egy működő alagút alapvonalat ad, amely elválasztja az új IPv6-hibát a régi kapcsolódási problémától. Azt is megmondja, melyik kiszolgálópéldányt szerkeszti valójában.

Jegyezze fel a poolt, a topológiát és a pusholt útvonalakat, amelyekre már támaszkodik. Az IPv6-munka kiterjeszti ezt a konfigurációt; nem helyettesíti.

Második ellenőrzési pont: válassza ki a belső előtagokat

Válasszon egy ULA /48-at a helyszínnek, és vágjon ki belőle két /64-et: egyet az alagút klienseinek, egyet az IPv6-munkaterhelést hordozó LAN-szegmensnek. Generálja a 40 bites globális ID-t ahelyett, hogy példa-előtagot másolna, és ellenőrizze mindkét alhálózatot minden hálózat ellen, amelyet a helyszín már irányít:

Outer transport: IPv4 OpenVPN UDP
IPv4 pool:       10.90.0.0/24
IPv6 VPN pool:   fd73:93bc:b6e9:77::/64
IPv6 LAN:        fd73:93bc:b6e9:60::/64
Server LAN IPv6: fd73:93bc:b6e9:60::1

Két független /64 megakadályozza, hogy a klienspool kivágódjon a LAN-szegmensből, ami később számít, amikor a visszaútvonalat írja. A fenti értékek egy kidolgozott példa, nem újrahasznosítható előtag.

Harmadik ellenőrzési pont: adja hozzá a segédet és az útvonal-push-t

Olvassa el a kiszolgáló jelenlegi konfigurációját, mielőtt bármit hozzáfűzne. Egy meglévő direktíva második példánya nem olvad össze az elsővel, és a keletkező hiba a direktívát nevezi meg, nem az IPv6-ot. A meglévő IPv4-segéddel két sor bővíti. Mindegyik más kérdésre válaszol:

server-ipv6 fd73:93bc:b6e9:77::/64
push "route-ipv6 fd73:93bc:b6e9:60::/64"

Az első egy kényelmi segéd, amely beállítja az interfészt és a klienspoolt. A második megnevezi a LAN-célt, ahová a kliensnek el kell jutnia. Ha egy kliensnek IPv6-címet adunk, az nem mondja meg, milyen hálózatok vannak a kiszolgáló mögött, ezért mindkét sor kell.

A segéd nem létezik együtt statikus IPv6-pooltal vagy nopool-val. Ha a telepítés szándékosan statikusan oszt ki címeket, tartsa meg ezt a szabályt, és tervezze meg kifejezetten az IPv6-megfelelőt, ahelyett hogy törölné a szabályt, hogy illeszkedjen egy példához.

Negyedik ellenőrzési pont: továbbítás és a válaszútvonal

Kapcsolja be az IPv6-továbbítást a kiszolgálón a rendszer saját konfigurációtulajdonosán keresztül, nem egy egyszeri futásidejű írással, amelyet elfelejt. A futásidejű forma gyors teszthez hasznos. Az állandó konfiguráció egy drop-in fájlba tartozik, amelyet a disztribúció hálózati tulajdonosa olvas:

sysctl -w net.ipv6.conf.all.forwarding=1

A továbbítás a csomagok irányításán túl is megváltoztatja a gazdagép IPv6-viselkedését. Az a gazdagép, amely kliensként elfogadta az útválasztó-hirdetéseket, ugyanúgy abbahagyja, amikor továbbítani kezd. Ezért az a gép, amelynek IPv6-feltöltő kapcsolata RA-któl függ, kifejezett tervet igényel arra a kapcsolatra.

Ezután adjon a LAN-nak visszautat az alagút pooljához. A munkaterhelés IPv6-átjárója a LAN útválasztója, nem a VPN-kiszolgáló, tehát az útvonal azon az útválasztón van, és a kiszolgáló LAN-címére mutat:

ip -6 route add fd73:93bc:b6e9:77::/64 via fd73:93bc:b6e9:60::1

Tartsa meg a linkhez szükséges ICMPv6-típusokat, beleértve az útvonal-MTU visszajelzését. Egy IPv4-es tűzfal-szabály nem jelent IPv6-os szabályt, és az IPv6 teljes blokkolása olyan módon töri meg a szomszédok felderítését, amely útválasztási hibának látszik.

Ötödik ellenőrzési pont: olvassa a klienst, aztán teszteljen

Csatlakoztassa újra a klienst, és olvassa el a ténylegesen kapott címeket ahelyett, hogy a kiszolgáló segédcíméből következtetne rájuk. Az interfészlista mindkét családot ugyanazon az eszközön mutatja:

ip -6 addr show tun0
ip -6 route get fd73:93bc:b6e9:60::20

Az alagutat választó útvonal bizonyítja, hogy a kliens tudja, hová küldje a csomagot. Nem bizonyítja, hogy a kiszolgáló továbbítja, hogy a LAN útválasztóján megvan a visszaútvonal, vagy hogy az alkalmazás válaszolhat.

Tesztelje magát az alkalmazást minden családon sorra, majd ismételje meg újracsatlakozás és gazdagép-újraindítás után. Az az útvonal vagy sysctl, amely csak újraindításig él, teszt, nem terv.

Csak akkor tegyen közzé AAAA-rekordot, ha az IPv6-útvonal végponttól végpontig válaszol. Az IPv4-en kérdezett DNS még mindig visszaadhat IPv6-címet, tehát egy feloldható név nem bizonyítéka annak, hogy valami figyel. Az RFC 4193 ULA-útmutató a globális ID létrehozását tárgyalja, amely ezeket az előtagokat a magáévá teszi, nem másolatként.