Które źródło IPv6 wybiera żądanie VPN i dlaczego to ma znaczenie

Dodano adres VPN i oczekiwano, że żądanie go użyje, ale serwer nadal zapisywał stary prefiks. Nic w tunelu nie zawiodło; host dokonał wyboru adresu źródłowego, zanim w ogóle spojrzał na trasę, w którą się wpatrywano. Wybór źródła IPv6 to osobne, uporządkowane współzawodnictwo między adresami kandydującymi hosta, a najdłuższy pasujący prefiks to tylko jedna reguła blisko końca tego współzawodnictwa. Aby uzyskać pożądany wynik, trzeba wiedzieć, która reguła już zwyciężyła. Same reguły są nudne i precyzyjne, i właśnie dlatego należy je czytać po kolei.

Dwa wyszukiwania, nie jedno

Wybór celu określa następny skok i interfejs wyjściowy. Następnie wybór źródła określa, który z adresów hosta pojawi się w nagłówku, a na oba pytania odpowiadają różne mechanizmy, choć oba używają prefiksów. Host z adresem fizycznym, adresem tymczasowym i adresem VPN ma trzech kandydatów dla dowolnego celu, a trasa do VPN nie wyznacza trzeciego automatycznie.

Dlatego poprawna trasa i błędne źródło tak łatwo współistnieją, i dlatego to samo żądanie może zachowywać się inaczej z przeglądarki i z wymuszonego powiązania. Traktuj oba wyszukiwania jako osobne, dopóki nie znajdziesz dowodu, który je łączy.

Czytaj reguły jako uporządkowane współzawodnictwo

RFC 6724 wymienia reguły po kolei, a każda z nich rozstrzyga jedynie remis pozostawiony przez poprzednie. Preferencja interfejsu wyjściowego i zgodność etykiet pojawiają się znacznie przed porównaniem prefiksów, więc adres na interfejsie, którego używa trasa, ma już przewagę, której lepsze dopasowanie prefiksu nie może wymazać. Uczestniczą też starzenie i zakres, i dlatego stary adres czasami przestaje być wybierany, mimo że nikt nie zmienił polityki.

Praktyczny wniosek jest taki, że o zwycięzcy nie można wnioskować wyłącznie z celu. Wypisz kandydatów, przejdź reguły po kolei i zobacz, gdzie naprawdę podjęto decyzję.

Zauważ też, że to źródłowa połowa problemu. Mieszanie dwóch porównań prefiksów daje wyjaśnienia, które brzmią rygorystycznie i przewidują zły adres. Mów, które porównanie masz na myśli, za każdym razem, gdy w zgłoszeniu używasz słowa prefiks.

Powiązanie aplikacji zmienia pytanie

Aplikacja może zażądać konkretnego adresu źródłowego, a prawidłowy jawny wybór przenosi pytanie z „który adres host wolałby” na „czy ten adres może dotrzeć do celu i wrócić”. Narzędzia, które wiążą się ze źródłem lub proszą o dane pomocnicze dotyczące wybranego adresu, ujawniają to bezpośrednio, i są najszybszym sposobem udowodnienia, którego adresu połączenie naprawdę użyło. Ten eksperyment bije trzecie czytanie tabeli tras, ponieważ donosi, co zdecydowało jądro, a nie co skonfigurowano. Powtórz go po zmianie i porównaj obie odpowiedzi.

To czyni powiązanie źródła zarówno narzędziem diagnostycznym, jak i obejściem: powiąż adres VPN i sprawdź, czy żądanie się udaje. Jeśli tak, ścieżka jest w porządku, a problemem był wybór. Jeśli nie, problemem od początku była ścieżka powrotna albo polityka drugiej strony.

Sprawdź, czy druga strona akceptuje to źródło

Cokolwiek wybierze host, musi to pasować do chronionego zakresu VPN oraz do trasy powrotnej i reguł dostępu na drugim końcu. Źródło spoza selektorów może wjechać do tunelu i zostać odrzucone na drugim końcu, co wygląda jak awaria jednokierunkowa i jest zwalane na routing. Porównaj wybrane źródło wewnętrzne z zakresem ochrony, zanim dotkniesz ustawień szyfrowania, bo zmiana trybu nie wybiera spośród adresów kandydujących.

Trzymaj też adres zewnętrznego punktu końcowego osobno w swoim rozumowaniu. Identyfikuje on transport między uczestnikami VPN i nie jest źródłem pakietu aplikacji wewnątrz.

Decyduj na podstawie czterech obserwacji

Zapisz użyty cel, kwalifikujące się źródła lokalne, faktycznie wybrane źródło i skuteczną ścieżkę wyjściową. Cztery wiersze wystarczą, by wyjaśnić niemal każdy przypadek, i można je porównać między działającym a uszkodzonym hostem bez ponownego sporu o teorię. Na etapie wyboru używaj własnego obsługiwanego widoku systemu operacyjnego, a nie nazwy ze standardu, bo implementacje dodają własne lokalne preferencje.

Kiedy odpowiedź wciąż cię zaskakuje, uporządkowanie robi coś, czego nie robi twój model myślowy, a naprawa polega na zmianie danych wejściowych, nie na kłótni z algorytmem. Zapisz cztery obserwacje w zgłoszeniu, a następny czytelnik będzie mógł odtworzyć twój wniosek.