IPv6 przez tunel OpenVPN: przejście przez router domowy

Laptop ma adres IPv6, tunel działa nad IPv4, a jednak każdy test IPv6 zawodzi. Albo gorzej: test się udaje, a ruch wyszedł ścieżką dostawcy, nigdy nie wchodząc do tunelu. Oba wyniki prowadzą do jednej brakującej decyzji: nikt nie dał routerowi prefiksu, który mógłby trasować do klientów. Przejście ścieżki od klienta na zewnątrz pokazuje, którego elementu brakuje.

Zacznij tam, gdzie siedzi klient

Zajrzyj do klienta, zanim dotkniesz serwera. ip -6 addr powinien pokazać adres tunelu z puli, a ip -6 route powinien pokazać wypchnięty prefiks wskazujący na urządzenie tunelu. Gdy adres jest, a trasy nie ma, brakuje wypchnięcia albo klient je zignorował. Gdy nie ma żadnego z nich, serwer niczego nie przydzielił.

Następnie sprawdź, co klient sądzi o świecie zewnętrznym. Trasa domyślna przez tunel rości sobie cały ruch IPv6, a trasa do 2000::/3 tylko globalny unicast. Obie mogą być poprawne i odpowiadają na różne pytania o wyciek.

Klient bez żadnej domyślnej trasy IPv6 zawodzi w każdym publicznym teście, choć sam tunel jest całkowicie zdrowy. To luka w polityce, a nie zepsuty tunel.

Sprawdź pulę, którą serwer naprawdę potrafi trasować

Serwer może przydzielać tylko z prefiksu, który naprawdę kontroluje. Jeśli dostawca deleguje /56, zarezerwuj jeden /64 dla tunelu, a resztę zostaw dla LAN. Tam, gdzie dostawca przekazuje na WAN tylko jeden /64 i nic więcej nie trasuje, zostaw prefiks LAN w spokoju i daj tunelowi unikalny zakres lokalny, akceptując, że klienci nie będą mieli wyjścia globalnego.

Pula i wypchnięcie idą razem. server-ipv6 2001:db8:80:10::/64 przydziela adresy, a push "route-ipv6 2000::/3" mówi klientom, co wysyłać do tunelu. Wypchnięcie 2000::/3 obejmuje globalny unicast i zostawia zakresy link-local oraz multicast poza tunelem.

Zapisz wybrany prefiks w protokole wdrożenia. Kto następnym razem zmieni przekazanie od dostawcy, musi wiedzieć, który /64 tunel już zajmuje.

Włącz przekazywanie dla drugiej rodziny

Przekazywanie IPv4 nie oznacza przekazywania IPv6. Ustaw net.ipv6.conf.all.forwarding=1 i odwzoruj wszystko, na co polityka FORWARD dla IPv4 już pozwala. Na routerze, którego łańcuch FORWARD domyślnie odrzuca, brakujący zestaw reguł wygląda dokładnie jak martwy tunel.

Uścisk dłoni się udaje, klient dostaje adres, a nic nie wraca. Dodaj reguły dla obu kierunków i dla odcinka WAN, bo tunel, który dociera do LAN, ale nie do internetu, zawodzi w trzecim teście. Po nieudanej próbie zajrzyj do liczników łańcucha, bo reguła, która nigdy nie pasowała, to inny problem niż ta, która pasowała i odrzuciła.

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

Jeden efekt uboczny łapie ludzi, którzy w końcu obwiniają tunel. Włączenie przekazywania powoduje, że jądro pomija konfigurację adresu przez Router Advertisement, jeśli nie powie się inaczej, a trasa domyślna nauczona w ten sposób znika razem z nią. Albo przypnij jawną trasę domyślną na interfejsie WAN, albo ustaw tam świadomie accept_ra na 2. Po każdej zmianie potwierdź, że router nadal ma użyteczną ścieżkę IPv6 na zewnątrz, zanim ponownie przetestujesz klientów.

Odpowiedz na odkrywanie sąsiadów, gdy strona nadrzędna nie trasuje

Sprzęt nadrzędny czasem traktuje delegowany /64 jako należący do jego własnego łącza i odmawia trasowania jakiegokolwiek podprefiksu do skrzynki VPN. Gdy tak się dzieje, coś musi odpowiadać na żądania sąsiadów dla każdego adresu klienta osobno.

OpenVPN udostępnia przydzielony adres hakowi client-connect, więc wpisy mogą podążać za prawdziwą pulą zamiast listy utrzymywanej ręcznie. Hak dodaje ip -6 neigh add proxy $ifconfig_pool_remote_ip6 dev eth0, a pasujący hak client-disconnect go usuwa. Bez usunięcia tabela proxy się starzeje, a późniejszy klient może odziedziczyć wpis dla adresu, którego nigdy nie dostał. Potwierdź stan za pomocą ip -6 neigh show proxy.

Traktuj proxy jako obejście. Trasa statyczna dla /64 tunelu skierowana na router przetrwa zmiany klientów i w ogóle nie wymaga uprzywilejowanego haka powłoki.

Śledź ścieżkę na zewnątrz, skok po skoku

Testuj na zewnątrz w trzech krokach: najpierw adres tunelu routera, potem host w LAN, a trzecie publiczny cel przez traceroute6. Pulę dowodzi pierwszy, przekazywanie i zaporę LAN drugi, a drogę powrotną przez stronę nadrzędną trzeci. Każda porażka zawęża poszukiwania do jednego urządzenia zamiast otwierać cały projekt od nowa.

Uważaj na MTU tunelu, bo routery IPv6 na ścieżce nie będą fragmentować za ciebie. Zbyt duże MTU objawia się błędem packet-too-big i zatrzymanym TLS, a nie czystą porażką. Ustaw je jawnie i testuj z obciążeniem blisko limitu.