Ping do partnera tunelu IPv6 nie działa? Sprawdź adres ::

Jeden koniec tunelu IPv6 pinguje drugi, a odpowiada zawsze tylko jeden kierunek. Interfejs jest włączony, trasa wygląda poprawnie, a nic w logu tego nie wyjaśnia. Adres, który przydzieliłeś, to adres anycast routera podsieci, który wcale nie jest adresem hosta, a na łączu z dwoma punktami końcowymi ma dokładnie jeden cel dostarczenia: nadawcę. Żadna wartość limitu czasu tego nie naprawi, bo adres nie robi tego, co myślisz.

Objaw, który wskazuje na adres

Każdy host na łączu odpowiada oprócz tego, którego identyfikator interfejsu to same zera. Pakiet zaadresowany do tej postaci jest z definicji dostarczany do routera w podsieci, więc w tunelu punkt-punkt wraca do maszyny, która go wysłała. Z dalekiego końca czyta się to jako nieosiągalny partner; z bliskiego jako cisza. Podmień na inny identyfikator z tego samego prefiksu, a objaw znika bez żadnej innej zmiany, i to jest potwierdzenie, które trzeba uzyskać przed dotknięciem tras.

Identyfikator z samych zer jest zarezerwowany jako anycast

RFC 4291 zachowuje identyfikator interfejsu z samych zer jako adres anycast routera podsieci, więc /64 taki jak 2001:db8:4a::/64 nie zawiera żadnego użytecznego hosta pod adresem 2001:db8:4a::. Rezerwacja zasługuje na swoje miejsce: komunikaty routera i wykrywanie sąsiadów adresują tę postać, a router odpowiada za prefiks, któremu służy. Przydzielenie tej wartości końcowi tunelu daje liściowi rolę routera, i dlatego nic nie wraca. Każdy inny identyfikator w prefiksie działa jako host, więc naprawa to zwykle jedna cyfra.

Traktuj rezerwację jako rolę, której nie masz prawa zajmować z końca tunelu, a nie jako osobliwość do obejścia trasą.

Przydziel adresy hostów i routuj prefiks

Wybierz ::1 i ::2 dla obu końców, dodaj jeden poleceniem ip -6 addr add 2001:db8:4a::2/64 dev tun0, a następnie routuj odległy prefiks zamiast próbować go zaadresować. Trasa do 2001:db8:4a::/64 przez tunel czyni daleką stronę osiągalną; sam adres tylko konfiguruje lokalny interfejs.

Dla pełnego tunelu jest trzeci krok, trasa domyślna dla globalnego unicastu przez urządzenie, czyli IPv6-owy odpowiednik wysłania wszystkiego do tunelu. Pomiń go, a IPv6 nadal będzie używać łącza fizycznego, podczas gdy IPv4 podróżuje wewnątrz tunelu, więc host wycieka dokładnie ten ruch, który uważałeś za objęty. Potwierdź poleceniem ip -6 route get 2001:4860:4860::8888 i przeczytaj, które urządzenie wymienia, zamiast zakładać odpowiedź.

Multicast jest odrzucany przed routingiem

Android waliduje adresy i trasy dla VpnService.Builder przez LinkAddress, a ten konstruktor odrzuca multicast wprost. Daj mu prefiks multicast jako trasę, a wynikiem będzie błąd złych parametrów LinkAddress, a nie trasa, co jest odpowiedzią walidacji, a nie sieci. Odmowa pasuje do medium: urządzenie tun punkt-punkt nie ma multicasting na warstwie łącza, więc trasa grupowa na nim nie ma modelu dostarczania do zainstalowania. Adresy grupowe są tworzone i zużywane przez sam stos, a nie konfigurowane ręcznie.

Adresy IPv6 all-nodes i solicited-node podlegają tej samej regule. Interfejs je nosi, bo stos je tam umieścił, a nie dlatego, że jakaś polityka ich zamierzała.

Co tunel może nieść zamiast tego

przenoszenie wykrywania multicast przez tunel wymaga warstwy rozumiejącej przynależność do grup: mostka TAP prezentującego segment Ethernet, przekaźnika na poziomie aplikacji albo protokołu routingu, któremu wprost powiedziano, do których partnerów replikować. Niczego z tego nie ma w modelu VpnService, gdzie aplikacja czyta i pisze pakiety i nie ma wywołania, które dołącza do grupy dla tunelu. Albo dodaj komponent rozumiejący grupy, albo usuń wymaganie z projektu.

Unicast natomiast nie wymaga niczego ponad adresy i trasy powyżej, dlatego zwykle oczekuje się, że tunele go uniosą, a potem obwinia się je, gdy protokół wykrywania zawiedzie.

Trzy sprawdzenia przed przydzieleniem czegokolwiek

Potwierdź, że adres nie jest postacią anycast, że nie jest multicast i że prefiks jest routowany, a nie tylko przydzielony urządzeniu. Następnie wyślij test do celu, który jest prawdziwym hostem, bo ping skierowany na adres anycast mierzy nadawcę i nic nie mówi o ścieżce. Trzymaj te trzy sprawdzenia w zapisie zmian, żeby następne wdrożenie ich nie odkrywało ponownie.

Trasy, której platforma nigdy nie zainstalowała, nie da się zdebugować dłuższym czekaniem, a adresu, który nigdy nie był hostem, nie da się naprawić lepszym pingiem.