Dzielenie /64 nie kieruje IPv6 do klientów VPN

Klient pokazuje globalny adres IPv6, uzgadnianie zostało zakończone, a z internetu nic nie wraca. Ustawienie puli wygląda poprawnie, ponieważ jest poprawne; adres jest prawidłowy, a tunel go przenosi. Zawodzi dostarczanie, a dostarczanie zależy od decyzji podjętej powyżej serwera VPN, na którą żadna konfiguracja po stronie klienta nie ma wpływu.

Mit: część twojego /64 jest już osiągalna

Historia jest atrakcyjna: serwer ma publiczny /64, przetnij go na pół, oddaj drugą połowę puli VPN, a ci klienci są już w internecie. Podział prefiksu rzeczywiście przydziela adresy bez kolizji. Nie zmienia jednak tego, jak sieć upstream decyduje, dokąd ma trafić pakiet do jednego z tych adresów.

IPv6 nie ma domyślnej warstwy tłumaczenia, na której można by się oprzeć, więc ścieżka powrotna musi istnieć jako routing albo jako dostarczanie na poziomie łącza. Pakiet zaadresowany do adresu tunelu klienta dociera do routera upstream, a ten router podejmuje decyzję o przekazaniu na podstawie własnej tabeli. Jeśli tabela wskazuje łącze fizyczne, pakiet tam trafia, niezależnie od tego, co sądzi twój serwer VPN.

To jest cała awaria: kierunek do przodu działa, bo wysyła go twój serwer, a kierunek powrotny ginie o jedno przeskok dalej, bo upstream nigdy nie dowiedział się, że klient istnieje.

Czego naprawdę wymaga dostarczanie na łączu

Gdy upstream uznaje cały /64 za znajdujący się na łączu fizycznym, rozwiązuje każdy adres docelowy za pomocą wykrywania sąsiadów. Wysyła zapytanie na to łącze i oczekuje, że właściciel adresu odpowie. Klient VPN za tunelem nie znajduje się na tym łączu i nie może odpowiedzieć, więc zapytanie pozostaje bez odpowiedzi, a pakiet jest odrzucany.

Wycięcie /65 nie zmienia tego oczekiwania. Upstream nadal traktuje zakres jako znajdujący się na łączu, bo jedyną rzeczą, która zmieniłaby jego zdanie, jest trasa lub proxy odpowiadające w imieniu klienta. Żadne z nich się nie pojawia, bo edytowałeś konfigurację VPN. Właśnie ta luka wyjaśnia, dlaczego pula może doskonale działać między własnymi klientami i mimo to być nieosiągalna z każdego innego miejsca.

Wykrywanie sąsiadów przez proxy to mechanizm, który może połączyć oba światy. Brama odpowiada na zapytania dotyczące konkretnych adresów klientów, które posiada, i przekazuje ruch do tunelu. Działa, i musi być ograniczone dokładnie do tych adresów z cyklem życia, który podąża za pulą, bo odpowiadanie za adres, którego już nie obsługujesz, zamienia cudzy ruch w czarną dziurę. Niektóre sieci upstream nie przyjmą odpowiedzi proxy, których się nie spodziewały, więc ten projekt wymaga też zgody dostawcy.

Czego wymaga dostarczanie rutowane

Czystszy projekt to przydział, który upstream naprawdę routuje do twojej bramy. Może to być delegowany prefiks albo trasa statyczna dla mniejszego bloku, a wymóg jest w obu przypadkach taki sam: tabela upstream musi wskazywać twój serwer dla zakresu klientów. Wtedy ruch powrotny dociera do bramy, a brama przekazuje go do tunelu.

Dostarczanie rutowane całkowicie usuwa kwestię wykrywania sąsiadów, dlatego warto poprosić o nie dostawcę, zanim zbudujesz coś sprytnego. Poproś o trasę na piśmie i potwierdź, że następny przeskok to adres, który upstream naprawdę może osiągnąć.

Oba projekty nadal wymagają włączonego przekazywania IPv6 na bramie i reguł zapory, które pozwalają na przekazywany strumień w obu kierunkach. Dostarczanie jest warunkiem wstępnym, a nie zamiennikiem, dla reszty ścieżki. Działająca trasa z wyłączonym przekazywaniem daje dokładnie taką samą ciszę jak brakująca trasa, więc sprawdź oba, zanim cokolwiek przeprojektujesz.

Dwie niezależne trasy do ustawienia

Prefiks puli i własna trasa domyślna klienta to osobne ustawienia, a ich pomylenie daje częściową łączność, która wygląda jak zepsuty tunel. Pula mówi serwerowi, które adresy przydzielać. Trasy klienta decydują, do których miejsc docelowych klient w ogóle wysyła ruch do tunelu.

server-ipv6 2001:db8:42:100::/64
push "redirect-gateway ipv6 !ipv4"

Powyższy prefiks to przestrzeń dokumentacyjna, a przekierowanie dotyczy tylko IPv6, co jest dokładnie tym, czego wdrożenie dwustosowe często chce, gdy dostarczanie IPv6 jest jeszcze naprawiane. Przekierowanie IPv4 nie ustanawia pokrycia IPv6 i żadne z ustawień nie implikuje drugiego.

Utrzymuj ruch kontrolny, od którego zależy IPv6, w działaniu przy dowolnej stosowanej polityce. Komunikaty Packet Too Big są klasyczną ofiarą zapory, która dopuszcza tylko TCP i UDP, a ich odrzucanie tworzy połączenia, które się nawiązują, a potem zacinają przy większych transferach.

Ogłoszenia routera to trzeci ruchomy element. Jeśli brama zacznie ogłaszać na łączu nadrzędnym, może to zmienić to, co klienci i sąsiedzi sądzą o prefiksach na łączu, co może po cichu unieważnić właśnie udokumentowany projekt.

Zapisz projekt, aby odbudowa go odtworzyła

Zapisz trzy obiekty osobno: przydział klienta, trasę docelową klienta i metodę dostarczania przydziału przez upstream. Czytelnik, który ma wszystkie trzy, może odbudować wdrożenie; czytelnik, który ma tylko ustawienie puli, odtworzy pierwotny błąd.

Następnie przetestuj jawnie kierunek powrotny, pakietem, który musi wrócić z zewnątrz. Podręcznik openvpn(8) omawia opcje server-ipv6 i redirect, a potwierdzenie routingu od twojego dostawcy obejmuje połowę, której podręcznik nie może.