IPv6 przez serwer VPN IPv4 nadal wymaga prawdziwego wyjścia IPv6

Tunel wstaje, klient otrzymuje adres IPv6 z puli, a mimo to każde miejsce docelowe IPv6 kończy się przekroczeniem czasu. W tunelu nic nie jest zepsute: IPv6 jedzie zupełnie dobrze wewnątrz transportu IPv4, i to nigdy nie było trudną częścią. Adres, który wydałeś, to obietnica, której serwer nie może dotrzymać, bo wyjście nie ma żadnego upstreamu IPv6, do którego mógłby go wysłać. Naprawa należy do wyjścia, nie do profilu klienta.

Objaw: adres jest, ścieżki nie ma

Sprawdzenie po stronie klienta pokazuje adres IPv6 wyglądający na globalny na urządzeniu tunelowym i trasę wskazującą do niego, dlatego czyta się to błędnie jako błąd klienta. Ruch wchodzi do tunelu, serwer go dekapsuluje, a potem pakiet ląduje na hoście, którego tablica routingu nie ma żadnej domyślnej trasy IPv6 do prawdziwego miejsca. Zależnie od stosu dostajesz natychmiastową nieosiągalność albo ciche odrzucenie, a w obu przypadkach klient widzi limit czasu, który wygląda identycznie jak zapora.

Przeczytaj własną tablicę routingu serwera, zanim dotkniesz klienta, bo tam mieszka brakująca połowa ścieżki. Serwer z jedną domyślną trasą IPv4 już dał ci odpowiedź.

Śledź pakiet po dekapsulacji

Wewnątrz tunelu pakiet jest zwykłym IPv6, a jego źródłem jest adres klienta. Serwer zdejmuje kapsułkę transportową i trzyma wtedy natywny pakiet IPv6, który trzeba przekazać do następnego przeskoku IPv6. Domyślna trasa IPv4 nie może go unieść, a przetłumaczenie go na IPv4 to inna funkcja, której nikt nie wdrożył. To cała awaria i nie ma ona nic wspólnego z tym, czy odbiornik VPN odpowiedział przez IPv4.

Mechanika kapsułkowania IPv6 w IPv4 jest opisana w RFC 4213, a ważny szczegół jest tam taki, że końce nadal potrzebują prawdziwej łączności IPv6 po drugiej stronie tunelu. Owinięcie nagłówka nie wyczarowuje upstreamu.

Dwie warstwy tunelu, dwie niezależne kontrole

Sprawdź każdą warstwę osobno, bo działający tunel zewnętrzny ukrywa zepsuty wewnętrzny. Sprawdź ścieżkę zewnętrzną pingiem IPv4 od klienta do serwera i potwierdź port, którego używasz. Potem sprawdź ścieżkę wewnętrzną na serwerze, gdzie ip -6 route musi pokazać trasę domyślną lub konkretną trasę nauczoną od prawdziwego upstreamu, oraz ip -6 addr musi pokazać prefiks źródłowy, który upstream akceptuje. Cokolwiek mniej to tylko ozdoba na interfejsie.

Adres unikalny-lokalny albo prefiks wyglądający na globalny, do którego nic nie routuje z powrotem, ochoczo pojawi się na interfejsie i nigdzie nie pójdzie. Publiczną osiągalność daje upstream, nie kształt adresu.

To samo dotyczy klienta: ip -6 route get 2001:4860:4860::8888 powinno wskazywać urządzenie tunelowe, a jeśli wskazuje fizyczne, klient w ogóle nie używa VPN do IPv6.

Prefiks źródłowy, rozmiar i ICMPv6

Zapytaj upstream, jakie prefiksy źródłowe przyjmie do przekazywania, i użyj jednego z nich dla puli klientów. Dostawca, który daje ci /64 na interfejs samego serwera, niekoniecznie routuje do ciebie drugi /64 ani większy blok, a różnica to popołudnie debugowania, które zgłoszenie do wsparcia załatwia jednym pytaniem. Zapytaj na piśmie i zachowaj odpowiedź razem z konfiguracją.

Zarezerwuj w budżecie dodatkowe kapsułkowanie, którego twój stos naprawdę używa, i utrzymuj ICMPv6 w działaniu, w tym Packet Too Big. Drugi nagłówek zmniejsza użyteczny ładunek, więc ścieżka, która odpowiada na małe pingi, może mimo to zawieść przy transferze pliku, a zapora, która wyrzuca cały ICMPv6, zamienia naprawialny problem z rozmiarem w czarną dziurę. Przetestuj jeden duży transfer, zanim ogłosisz usługę.

Co jest zupełnie innym problemem

Dotarcie do aplikacji tylko IPv4 z klienta tylko IPv6 to tłumaczenie, nie tunelowanie, i wymaga czegoś w rodzaju świadomie wdrożonego NAT64. Cel nie zrozumie dodatkowego nagłówka tunelu tylko dlatego, że go dodałeś. Historyczne usługi przejściowe zasługują na taką samą troskę: RFC 7526 wycofał model przekaźnika anycast 6to4, więc poradnik napisany wokół niego opisuje coś, co nie ma już utrzymywanego publicznego przekaźnika.

Jeśli serwer nie ma użytecznego upstreamu IPv6, wybory to obsługiwany upstream, inne wyjście albo udokumentowana decyzja, że IPv6 zostaje poza tunelem. Nie do przyjęcia jest mówienie klientom, że usługa IPv6 istnieje, podczas gdy ich zwykłe połączenie IPv6 po cichu omija VPN.