Żadna trasa nie naprawi puli VPN, która pokrywa się z twoim LAN

Aplikacja twierdzi, że tunel jest zdrowy, a jednak połowa potrzebnych miejsc docelowych nigdy nie odpowiada. Odruchem jest dodanie trasy albo obniżenie metryki, i właśnie ten odruch jest mitem, który trzeba zabić najpierw. Gdy własny LAN klienta i pula tunelu roszczą sobie ten sam prefiks, tablica routingu trzyma dwa niezgodne fakty, i ani trasa domyślna, ani metryka ich nie rozstrzyga. Naprawa jest decyzją o adresacji, i żadne edytowanie tras jej nie zastąpi.

Dlaczego dodatkowa trasa nie może podzielić jednego prefiksu

Trasa nie rozdzieli dwóch roszczeń do jednego prefiksu, dlatego rozsądnym krokiem jest zaprzestanie szukania właściwej linii trasy. Stos nie umieści identycznego prefiksu przed trasą podłączoną, a bardziej szczegółowy wpis przechwytuje adres, ale czyni lokalnego hosta, który go posiada, nieosiągalnym. To, co wygląda na problem routingu, jest kolizją adresacji, i obie naprawy zmieniają adresy, a nie trasy. Sprawdź to twierdzenie na własnej maszynie, zanim je przyjmiesz.

ip route get 192.168.1.50
route -n get 192.168.1.50
Find-NetRoute -RemoteIPAddress 192.168.1.50

Zapytaj system o jeden adres i zwróć uwagę, który interfejs wymienia. Linux, macOS i Windows odpowiadają wyszukiwaniem tylko do odczytu, które podaje wybrany interfejs i następny skok, nic nie wysyłając. Gdy odpowiedź wskazuje kartę fizyczną, a tunel jest podniesiony, jądro traktuje adres jako lokalny dla łącza, a nie jako coś, co tunel mógłby nieść.

Postaw prefiks przyznany przez dostawcę obok tego, który obsługuje domowy router, i porównaj je jako ciągi. Dokładna zgodność to oczywisty przypadek, a szersza pula dostawcy zawierająca domową podsieć zawodzi tak samo, tylko łatwiej ją przeoczyć. Dwa prefiksy, które tylko wyglądają podobnie, nie są kolizją, więc zapisz oba, zanim cokolwiek zmienisz.

Odczytaj pulę, którą klient faktycznie dostał

Czytaj to, co otrzymał klient, a nie stronę marketingową dostawcy. Zwiększ szczegółowość logu klienta OpenVPN, a trasy wypychane przez serwer pojawią się w nim i ujawnią prefiksy tunelu; gdzie indziej pula widoczna jest w szczegółach połączenia albo na samej karcie. Poproś dostawcę o pełną listę używanych przez niego zakresów prywatnych, bo jedno /24 dziś może być dwa jutro. Unikanie typowych bloków RFC 1918 to nie to samo co unikanie przydziału, który faktycznie dostałeś.

Pula może się też kurczyć lub przenosić między regionami, więc lista potrzebuje daty i właściciela. Każdą odpowiedź dostawcy starszą niż twoja ostatnia zmiana planu traktuj jako domysł, nie fakt. Zapytaj ponownie, zanim zwiążesz się z zakresem, i trzymaj odpowiedź przy notatkach sieciowych, żeby następna osoba odziedziczyła dowód.

Przenumerowanie to naprawa, którą możesz wykonać

Jeśli serwer VPN nie jest twój do zmiany, przeniesienie domowego LAN to jedyna dostępna naprawa, i taka jest zwykła sytuacja u komercyjnego dostawcy. Wybierz zakres poza pulą dostawcy i poza zakresami, których możesz potrzebować później, i sprawdź go wobec każdej innej lokalizacji, do której docierasz przez tunel. Spodziewaj się krótkiej przerwy i dłuższego ogona zapomnianych urządzeń: urządzenie, które nadal ma stary adres, wygląda na działające, dopóki nie potrzebuje bramy.

1. Najpierw inwentaryzacja: własny adres routera, zakres DHCP, rezerwacje, przekierowania portów i każde urządzenie, którego adres wpisano ręcznie.
2. Potem zmień prefiks LAN routera i zakres DHCP razem w oknie serwisowym, i odśwież dzierżawy przewodowe przed bezprzewodowymi.
3. Następnie popraw adresy statyczne: drukarki, pamięć sieciowa, wszystko z twardo wpisaną bramą.
4. Na koniec połącz ponownie klienta VPN i potwierdź, że adres tunelu nie koliduje już z LAN.

Przechodź przez adresy w tej kolejności, a nie wszystkie naraz, i zostaw stary zakres przez jakiś czas udokumentowany, żeby przestarzałe urządzenie było rozpoznawalne, a nie zagadkowe. Urządzenie, które nigdy nie odnawia dzierżawy, zgłasza się tym, że nie dociera do bramy, co jest znacznie lepszą wskazówką niż telefon do wsparcia. Jeśli router rozdaje dzierżawy dłuższe niż dobę, skróć je na czas okna.

Co alias może, a czego nie może

Gdy serwer jest twój, tłumaczenie adresów na kliencie może ujawnić zdalny prefiks w wolnym zakresie lokalnym, tak że ten sam host odpowiada pod drugim adresem. Społecznościowy OpenVPN robi to za pomocą client-nat, i ta dyrektywa jest właściwa właśnie temu klientowi, nie ma jej w klientach komercyjnych i mobilnych, z którymi zwykle się ją porównuje. Układ wymaga trasy zgodnej z tłumaczeniem, wolnego zakresu dla aliasu i serwera gotowego odpowiedzieć na nieprzetłumaczony adres klienta. Nic z tego nie pomaga, gdy klient należy do zarządzanego dostawcy, którego nie możesz skonfigurować.

Gdy zmiana wejdzie w życie, dotrzyj do hosta lokalnego i zdalnego najpierw po adresie, a potem po nazwie, notując trasę, którą system wybiera za każdym razem. Nazwa może wciąż rozwiązywać się w stary zakres, więc adresy i nazwy zasługują na niezależne sprawdzenia. Uruchom ponownie jednego klienta i jedno urządzenie po stronie serwera, jeśli któreś przetrwało zmianę, bo wpisy sąsiadów w pamięci podręcznej żyją dłużej niż edycja.

Zapisz prefiksy, na których stanęło, tam, gdzie ludzie naprawdę patrzą: w notatkach sieciowych, w polu komentarza routera, na stronie wprowadzającej. Ktoś znowu wybierze 192.168.1.0/24, i kolizja wróci razem z nim.