Dlaczego wykrywanie sąsiadów IPv6 zawodzi przez trasowany VPN

Wykrywanie sąsiadów IPv6 należy do jednego łącza, a trasowany tunel jest granicą między dwoma łączami. To jedno zdanie wyjaśnia prawie każde zgłoszenie zdalnego hosta, który odpowiada po adresie i nie daje się znaleźć w żaden inny sposób. Zanim sprawdzisz tunel, sprawdź zakres testowanego adresu. Adres lokalny dla łącza ma sens tylko na własnym łączu, a grupa multicast żądanego węzła jest ograniczona w ten sam sposób. Żaden z nich nie przechodzi przez router, dlatego ping do adresu globalnego może się udać, podczas gdy wykrywanie tego samego hosta nie.

Zakres poprzedza konfigurację

Żądanie i ogłoszenie sąsiada mają limit skoków 255 i nie są przekazywane, zgodnie z projektem. Router między twoim tunelem a zdalną siecią LAN przekazuje pakiety IPv6 i nie przekazuje komunikatów sąsiadów w jego imieniu. Tak więc pamięć podręczna sąsiadów na interfejsie tunelu zawiera partnera i niewiele więcej, co jest poprawnym zachowaniem, a nie usterką do naprawy.

Adres lokalny dla łącza, taki jak wpis fe80::, jest też ograniczony strefą, a ten sam tekst może wskazywać inny host na innym łączu. Testowanie takiego adresu z drugiej strony tunelu nie dowodzi niczego poza tym, że adres jest niejednoznaczny.

Pułapką jest założenie, że prefiks jest na łączu

Host, który uważa, że prefiks jest na łączu, wysyła żądanie sąsiada zamiast przekazać pakiet swojemu routerowi, i dotyczy to także /64 trasowanego do zdalnej lokalizacji. Gdy taki prefiks przychodzi jako na-łączu, host pyta lokalne łącze o hosta mieszkającego gdzie indziej, i nic nie odpowiada. Trasuj coś mniejszego do zdalnego hosta albo zakończ prefiks na routerze, który odpowie za niego.

/128 dla jednej usługi to najmniej zaskakujące rozwiązanie i całkowicie usuwa niejednoznaczność. Specyfikacja wykrywania sąsiadów opisuje zestaw komunikatów i flagę na-łączu, która to rozstrzyga.

Mostkowanie zmienia zasady celowo

Gdy tunel przenosi ramki Ethernet, segment zdalny i lokalny stają się jednym łączem, multicast dociera po obu stronach, a wykrywanie sąsiadów zachowuje się jak na przełączniku. Skutki przychodzą razem z tym: powódź broadcastu i multicastu, wykrywanie zduplikowanych adresów przez most oraz ogłoszenia routera przeciekające do segmentu, który nie powinien ich widzieć. Domena awarii obejmuje teraz także dwie lokalizacje. Nic z tego nie przemawia przeciw mostkowaniu, a każdy punkt jest powodem, by mostkować świadomie, a nie przypadkiem.

Zmiana profilu z TUN na TAP, aby wykrywanie się pojawiło, to zła kolejność działań. Serwer, klient i plan adresacji muszą się zgodzić, a klienci mobilni w ogóle nie oferują interfejsu TAP, więc taki projekt działa na laptopie i zawodzi na telefonie. Proxy i przekaźniki sąsiadów to odrębne mechanizmy z własnymi wymaganiami i należą do udokumentowanego układu administratora sieci, a nie do ustawień aplikacji.

Testuj adresem, którego używa aplikacja

Potwierdź trasę za pomocą ip -6 route get, sprawdź wpis sąsiada za pomocą ip -6 neigh, a następnie potwierdź usługę na trasowanej ścieżce. DNS i ścieżka powrotna to osobne kontrole, a zdrowy wpis sąsiada nie dowodzi żadnej z nich.

Jeśli aplikacja nalega na cel lokalny dla łącza lub oparty na wykrywaniu, to rozmowa o projekcie, a nie ćwiczenie z dostrajania, ponieważ żadne ustawienie klienta nie sprawia, że mechanizm ograniczony do łącza działa przez router.

Zapisz, jaki masz projekt

Przed incydentem zapisz, czy jest trasowany, czy mostkowany, ponieważ oba wdrożenia odpowiadają na te pytania różnie, a inżynier dyżurny nie powinien tego wnioskować z profilu.

Jednorazowe przeczytanie zestawu komunikatów usuwa pokusę wyjaśniania właściwości zakresu łącza jako błędu VPN, co jest najdroższą błędną diagnozą w tej dziedzinie.