Ruch IPv6 omijający VPN: znaleźć przeciekającą trasę

Dwie strony testowe nie zgadzają się: jedna podaje adres dostawcy przez tunel, druga podaje prefiks domowy, a oczywisty wniosek jest taki, że VPN przecieka. Ten wniosek pomija jeden krok, bo oba raporty uruchomiły dwie różne decyzje trasowania i tylko jedna z nich miała trafić do tunelu. Luka zwykle jest prawdziwa i jest problemem pokrycia, a nie zepsutym tunelem. Trzy pytania to rozstrzygają: który przepływ faktycznie wyszedł, którą trasę wybrał dla niego kernel i jakie zachowanie zamierzał klient.

Pracuj w tej kolejności. Odpowiadanie na nie w innej kolejności daje długą dyskusję o tym, czy klient jest wadliwy, gdy prawdziwą odpowiedzią jest to, że nigdy nie zainstalowano trasy IPv6.

Który przepływ faktycznie wyszedł i przez którą kartę sieciową

Zacznij od testu, który nazywa używaną rodzinę, a potem zapisz aplikację, sieć dostępową, obowiązujący profil i to, czy połączenie w ogóle oferuje IPv6. Te cztery fakty czynią dwa przebiegi porównywalnymi, a czwarty ludzie zapominają: sieć bez prefiksu v6 nie może przeciec v6, a sieć, która doda go później, zmienia odpowiedź.

Wyślij jedno żądanie na rodzinę, zamiast wczytywać stronę i czytać jej wynik. Jedna strona może mieszać zasoby v6 i v4, proces w tle może zachowywać się inaczej niż karta przed tobą, a odpowiedź z pamięci podręcznej może przeżyć zmianę sieci, którą próbujesz sprawdzić. Ustal testowany cel i zapisz go, aby powtórzony przebieg mierzył to samo.

Odczytywanie trasy wybranej przez kernel

Tablica tras odpowiada na pytanie, na które przeglądarka nie potrafi. Zapytaj system, dokąd pójdzie konkretny cel, i uwzględnij zarówno reguły polityki, jak i widoczną trasę domyślną, bo każde z nich może ją nadpisać:

ip -6 route get 2606:4700:4700::1111
ip -6 rule show
ip -6 route show table all

Bardziej szczegółowy prefiks to zwykły powód, dla którego jeden cel zostaje poza tunelem, a wszystko inne w środku, a reguła polityki może zrobić to samo z wyższym priorytetem niż jakakolwiek trasa. Czytaj też metrykę, bo dwa wpisy dla tego samego prefiksu rozstrzyga metryka, a nie ich kolejność na ekranie. W Windows odpowiednia lista to Get-NetRoute -AddressFamily IPv6, posortowana według metryki, aby odpowiadała kolejności decyzji. Reguła, która w tabeli wygląda poprawnie, może jednak przegrać z regułą polityki o niższym numerze, dlatego lista reguł należy do tego samego oddechu co lista tras.

Skąd bierze się polityka IPv6 klienta

Klient może być zbudowany tak, aby prowadził v6 przez tunel, aby go odrzucał albo aby dopuszczał nazwany wyjątek, i te trzy intencje dają trzy różne poprawne wyniki. Przeczytaj profil i dokumentację samego klienta, zanim nazwiesz obserwację przeciekiem, bo klient, który blokuje v6, gdy system operacyjny nadal wysyła wykrywanie sąsiadów po łączu fizycznym, zachowuje się zgodnie z projektem.

Aplikacja celowo wyłączona z tunelu to inny przypadek niż rodzina, której tunel nigdy nie przenosił. Pierwsze jest decyzją o jednym programie, drugie luką w pokryciu, a naprawa różni się odpowiednio. Przeczytaj listę wykluczonych programów klienta, zanim zaczniesz szukać trasy, której nigdy nie powinno być.

Wąska obserwacja, gdy tablica się nie zgadza

Gdy wyszukiwanie trasy jest niejednoznaczne, jedna obserwacja interfejsu na hoście może to rozstrzygnąć, ale tylko wtedy, gdy jest wymierzona w pytanie. Ruch do samego punktu końcowego VPN przejdzie przez kartę fizyczną z założenia; liczy się to, czy przepływ aplikacji, adresowany zupełnie gdzie indziej, także się tam pojawia. Filtruj przechwytywanie do testowanego celu, zamiast zbierać wszystko.

Szerokie przechwytywanie ujawnia znacznie więcej ruchu osobistego, niż wymaga tego jedno pytanie. Odpowiada też mniej jasno, bo interesujący cię przepływ przychodzi zakopany w strumieniu niepowiązanych połączeń. Filtruj do sprawdzonego celu, zatrzymaj się po kilku pakietach i usuń przechwytywanie.

Trzy sposoby zamknięcia luki

Przeprowadź rodzinę przez tunel, zablokuj ją w kliencie, gdy tunel nie może jej przenieść, albo zapisz świadomy wyjątek z właścicielem i datą przeglądu. Każdy jest do obrony, a jedyną rzeczą nie do obrony jest pozostawienie wyboru domyślnym, bo domyślny wybór to dokładnie to, czym jest przeciek. Jeśli tunel w ogóle nie ma wyjścia v6, odmowa v6 w kliencie jest i uczciwa, i testowalna. Liczy się to, że wybór jest zapisany tam, gdzie znajdzie go następna osoba, a nie wywnioskowany z zachowania pół roku później.

Powtórz kontrolę po ponownym połączeniu i po przejściu między sieciami, bo trasa zainstalowana dla poprzedniego łącza może przeżyć zmianę. Potem zapisz cel, wybraną trasę, politykę klienta i rodzinę używaną w teście, aby następna osoba przeczytała decyzję, zamiast wyprowadzać ją od nowa. RFC 7359 dokumentuje przeciek podwójnego stosu jako problem projektowy, a nie błąd, i to jest odniesienie, które się cytuje, gdy ktoś twierdzi, że działający tunel v4 obejmuje wszystko.