Dodaj prywatny IPv6 do laboratorium OpenVPN, jeden punkt kontrolny naraz

Masz już klienta, który łączy się przez IPv4 i dociera do prywatnego obciążenia IPv4 za serwerem. Celem jest dotarcie do prywatnego obciążenia IPv6 tym samym tunelem bez dotykania transportu zewnętrznego. Ta kolejność ma znaczenie: ścieżka zewnętrzna zostaje IPv4, a zmieniają się tylko wewnętrzny plan adresów, trasa klienta i droga powrotna z serwera do LAN. Pięć punktów kontrolnych, każdy z czymś konkretnym do sprawdzenia przed przejściem dalej.

Punkt kontrolny pierwszy: połączenie, które już działa

Podłącz klienta i potwierdź ścieżkę IPv4, zanim cokolwiek dodasz. Działający tunel daje linię bazową, która oddziela nowy błąd IPv6 od starego problemu z łącznością. Mówi też, którą instancję serwera naprawdę edytujesz.

Zanotuj pulę, topologię i wypchnięte trasy, na których już polegasz. Praca nad IPv6 rozszerza tę konfigurację; nie zastępuje jej.

Punkt kontrolny drugi: wybierz prefiksy wewnętrzne

Wybierz ULA /48 dla witryny i wytnij z niej dwa /64: jedno dla klientów tunelu, jedno dla segmentu LAN z obciążeniem IPv6. Wygeneruj 40-bitowy globalny ID zamiast kopiować przykładowy prefiks, i sprawdź obie podsieci wobec każdej sieci, którą witryna już routuje:

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

Dwa niezależne /64 nie pozwalają wyciąć puli klientów z segmentu LAN, co ma znaczenie później, gdy piszesz trasę powrotną. Powyższe wartości to jeden rozpracowany przykład, a nie prefiks do ponownego użycia.

Punkt kontrolny trzeci: dodaj pomocnika i wypchnięcie trasy

Przeczytaj bieżącą konfigurację serwera, zanim coś dopiszesz. Druga kopia istniejącej dyrektywy nie scala się z pierwszą, a powstały błąd nazywa dyrektywę, nie IPv6. Przy istniejącym pomocniku IPv4 dwie linie go rozszerzają. Każda odpowiada na inne pytanie:

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

Pierwsza to wygodny pomocnik, który ustawia interfejs i pulę klientów. Druga nazywa cel w LAN, do którego klient ma dotrzeć. Przydzielenie klientowi adresu IPv6 nie mówi mu, jakie sieci są za serwerem, więc potrzebne są obie linie.

Pomocnik nie współistnieje ze statyczną pulą IPv6 ani z nopool. Jeśli wdrożenie celowo przydziela adresy statycznie, zachowaj tę politykę i zaprojektuj odpowiednik IPv6 wprost, zamiast usuwać politykę, by dopasować się do przykładu.

Punkt kontrolny czwarty: przekazywanie i trasa odpowiedzi

Włącz przekazywanie IPv6 na serwerze przez właściwego właściciela konfiguracji systemu, a nie jednorazowym zapisem w czasie działania, który zapomnisz. Forma w czasie działania jest przydatna do szybkiego testu. Trwała konfiguracja należy do pliku drop-in, który czyta właściciel sieci dystrybucji:

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

Przekazywanie zmienia zachowanie IPv6 hosta bardziej niż samo routowanie pakietów. Host, który jako klient przyjmował ogłoszenia routera, przestaje to robić w ten sam sposób, gdy zaczyna przekazywać. Dlatego maszyna, której łącze IPv6 zależy od RA, potrzebuje wyraźnego planu dla tego łącza.

Następnie daj sieci LAN trasę powrotną do puli tunelu. Bramą IPv6 obciążenia jest router LAN, nie serwer VPN, więc trasa należy do tego routera i wskazuje adres LAN serwera:

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

Zachowaj typy ICMPv6 potrzebne łączu, w tym informację zwrotną o MTU ścieżki. Reguła zapory IPv4 nie oznacza reguły IPv6, a całkowite blokowanie IPv6 psuje wykrywanie sąsiadów w sposób wyglądający jak awaria routingu.

Punkt kontrolny piąty: przeczytaj klienta, potem testuj

Podłącz klienta ponownie i odczytaj adresy, które naprawdę otrzymał, zamiast wnioskować je z adresu pomocniczego serwera. Lista interfejsów pokazuje obie rodziny na tym samym urządzeniu:

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

Trasa wybierająca tunel dowodzi, że klient wie, gdzie wysłać pakiet. Nie dowodzi, że serwer go przekazuje, że router LAN ma trasę powrotną ani że aplikacja może odpowiedzieć.

Testuj samą aplikację po kolei przez każdą rodzinę, a potem powtórz po ponownym połączeniu i po restarcie hosta. Trasa lub sysctl, które przetrwają tylko do restartu, to test, nie projekt.

Opublikuj rekord AAAA dopiero gdy ścieżka IPv6 odpowiada od końca do końca. DNS pytany przez IPv4 wciąż może zwrócić adres IPv6, więc rozwiązywalna nazwa nie jest dowodem, że coś nasłuchuje. Wskazówki RFC 4193 dla ULA obejmują generowanie globalnego ID, które czyni te prefiksy twoimi, a nie kopią.