route-gateway to nie redirect-gateway: co naprawdę się zmienia

Twój tunel wstaje, podsiedź prywatna odpowiada, a zwykłe przeglądanie nadal znika w VPN, choć ktoś usunął wiersz bramy z profilu. Ta kombinacja jest odciskiem palca edycji niewłaściwej dyrektywy. Usunięte dawało klientowi następny skok dla tras, które instaluje; to, co nadal przechwytywało ruch, przyszło skądinąd i zostało wypchnięte przez serwer. Zasięg i następny skok to osobne zadania, a tylko jedno z nich decyduje, czy cele publiczne korzystają z tunelu.

Usunięty wiersz był następnym skokiem, a nie przełącznikiem polityki

Każda trasa instalowana przez klienta potrzebuje adresu bramy, na który ma wskazywać, a dyrektywa bramy jest źródłem tego adresu, gdy trasa sama go nie podaje. Usuń ją, a te trasy nie mają się do czego przyczepić, więc albo się nie instalują, albo trafiają na ścieżkę donikąd. Podsiedź prywatna to dokładnie to, co taka trasa niosła.

Tymczasem ocalałe zachowanie ma innego autora: opcję przekierowania w wypchniętym bloku, która przenosi zwykły ruch wychodzący do tunelu zgodnie ze swoimi flagami. Usunięcie bramy jej nie wyłącza ani nie osłabia. Wynik jest najgorszy z obu stanów: ruch publiczny nadal jest przechwytywany, a cel prywatny, który uzasadniał tunel, jest teraz nieosiągalny. Dlatego druga edycja, dokonana w tym samym duchu, też niczego nie zmienia.

Cztery dźwignie, cztery różne zadania

W tej dyskusji cztery dyrektywy są cytowane zamiennie, a tylko jedna z nich rządzi zasięgiem, czyli tym, które cele w ogóle idą przez tunel. Druga ustawia następny skok używany przez trasy, trzecia instaluje jeden prefiks, a czwarta wyrzuca wszystko, co wypchnął serwer, łącznie z trasami prywatnymi potrzebnymi wdrożeniu. Tabela porządkuje je według tego, co administrator próbuje zmienić, a nie według nazwy, bo to nazwy powodują zamieszanie. Traktuj je jako cztery osobne decyzje i wybierz tę, którą naprawdę chcesz cofnąć.

W praktyce wszystkie cztery często przychodzą w jednym wypchniętym bloku, wiersz po wierszu, co sprawia, że wyglądają jak części jednego ustawienia. Nie są, i odnośnik OpenVPN dokumentuje je jako odrębne mechanizmy właśnie dlatego. Ustalenie, którą decyzję cofasz, jest zadaniem; edycja to jeden wiersz.

Filtruj wypchnięty wiersz, zachowaj następny skok

Jeśli zasięg, przeciwko któremu protestujesz, przychodzi jako wypchnięta opcja, wąską odpowiedzią jest zignorowanie tej opcji po nazwie i pozostawienie reszty wypchniętego bloku nietkniętej. Zapisany jako filtr wygląda jak wiersz poniżej, a jego miejsce jest w profilu dotkniętego klienta, nie w konfiguracji serwera.

pull-filter ignore "redirect-gateway"

Wąskość jest sednem. Ponieważ filtr porównuje prefiks tekstowy, krótszy wzorzec pasuje także do dyrektywy następnego skoku, co zdejmuje dokładnie informację, od której zależą trasy prywatne, i powtarza pierwotny błąd w nowym kostiumie. Filtr działa też tylko na wypchniętych opcjach, więc nigdy nie dotyka równoważnego wiersza zapisanego lokalnie lub narzuconego przez menedżera sieci. Połącz się ponownie, bo aktywna sesja nie ocenia na nowo tego, co wypchnął serwer.

Czytaj wyszukiwanie, nie tabelę

Po ponownym wczytaniu profilu zapytaj jądro, dokąd naprawdę trafiłyby dwa cele: jeden wewnątrz prefiksu prywatnego, drugi w publicznym internecie. Pełny zrzut tabeli głównej jest trudniejszy do czytania i łatwiejszy do błędnego odczytania, bo trasa może istnieć i mimo to przegrać z bardziej szczegółowym dopasowaniem. Przy trasowaniu politycznym reguła, tabela i adres źródłowy też należą do sprawdzenia.

ip route get 10.40.7.25
ip route get 203.0.113.77
ip rule show

Wariant def1 wart jest znajomości, bo pozostawia widoczny stary wpis domyślny, podczas gdy para półdomyślnych wygrywa wyszukiwanie. Dlatego wiersz 0.0.0.0/0 w wyniku sam z siebie niczego nie dowodzi. Wyszukiwanie odpowiada na pytanie, na które lista tylko wydaje się odpowiadać.

DNS, IPv6 i trasa prywatna muszą nadal działać

Odrzucenie jednego przekierowania IPv4 nic nie mówi o resolverze, więc wypchnięta opcja DNS może nadal wysyłać zapytania do tunelu, podczas gdy trasy wyglądają poprawnie. Domyślny IPv6 może zrobić to samo dla rodziny adresów, której sprawdzenie IPv4 nigdy nie dotknęło. Oba wymagają wyraźnej decyzji, a nie założenia. Potem potwierdź, że usługa prywatna nadal odpowiada, bo tunel dzielony, który stracił swoją trasę prywatną, nie jest tunelem dzielonym, jest zepsuty.

Jedno szersze narzędzie zasługuje na ostrzeżenie: route-nopull wyrzuca każdą wypchniętą trasę i każdą wypchniętą opcję DNS, co z pewnością zatrzymuje pełny tunel i równie pewnie psuje trasy prywatne, od których zależy wdrożenie, więc jest to znacznie większy młot niż filtr nazw wycelowany w jedną opcję. Sprawdź cel prywatny, cel publiczny i resolver po każdej zmianie, a ukończony uścisk dłoni traktuj jako dowód niczego poza uściskiem.