Co polityka routingu zmienia w ruchu VPN, a czego nie

Routing oparty na polityce odpowiada na inne pytanie niż to, które zadaje większość notatek o rozwiązywaniu problemów. Tablica główna mówi, dokąd idzie cel; reguły polityki mówią, która tablica jest w ogóle sprawdzana, i mogą to rozstrzygnąć na podstawie adresu źródłowego, znacznika pakietu, lub interfejsu, na którym pakiet przyszedł. Gdy tunel zachowuje się niespójnie, powodem jest często zbiór reguł, a tablica routingu często nie.

Reguły wybierają tablicę, potem tablica wybiera trasę

Każda reguła niesie priorytet, warunek dopasowania i tablicę docelową. Jądro przechodzi reguły w kolejności priorytetu i zatrzymuje się na pierwszym dopasowaniu, po czym wykonuje zwykłe wyszukiwanie najdłuższego prefiksu w tej tablicy. Reguła wskazująca na pustą tablicę przechodzi do tego, co wybierze następna reguła, i tak starannie napisana reguła może wyglądać, jakby nic nie robiła.

Dlatego zrzut tablicy głównej rzadko wyjaśnia działającego klienta VPN. Klienci zwykle wstawiają reguły pod niskimi numerami priorytetu, długo przed regułą domyślną tablicy głównej, więc pakiet nigdy nie dociera do trasy, na którą patrzyłeś. Obniżenie metryki w tablicy głównej niczego nie zmienia dla ruchu, który został już przekierowany.

Reguła może też celowo uczynić prefiks czarną dziurą lub nieosiągalnym. Niektórzy klienci dodają taką regułę jako wyłącznik bezpieczeństwa, a wtedy odrzucenie wygląda jak zepsuty tunel, a nie skonfigurowany.

Czytaj zbiór reguł jako sekwencję, nie jako listę

Wypisz reguły z ich priorytetami i tablicami, do których się odwołują, a następnie wypisz każdą tablicę, która niesie trasę domyślną lub trasę tunelu. Kolejność jest tą częścią, która ma znaczenie, i to ją zrzut ekranu zwykle pomija:

ip rule show
ip route show table all | sed -n '1,60p'
ip route get 198.51.100.20 from 10.8.0.2
ip route get 198.51.100.20 from 10.8.0.2 mark 0x1

Dwie ostatnie komendy to te, które zamieniają teorię w obserwację, bo pytają co jądro zrobiłoby dla tego źródła i tego znacznika. Jeśli odpowiedź zmienia się wraz ze zmianą znacznika, działa reguła oparta na znaczniku i każdy test, który pomija znacznik, testuje inny pakiet. Połączenie zewnętrzne zasługuje na własną regułę. Tunel, który kieruje cały ruch przez siebie, musi wykluczyć adres punktu końcowego, z którym się łączy, inaczej zaszyfrowane pakiety są odsyłane do tunelu, który właśnie opuściły. Większość klientów wstawia to wykluczenie automatycznie, a ręcznie edytowany zbiór reguł to miejsce, w którym go brakuje.

Znaczniki i sockety: dwa sposoby, w jakie klienci dzielą ruch

Niektórzy klienci oznaczają pakiety w zaporze i dodają regułę pasującą do znacznika. Inni używają routingu na poziomie gniazda i ustawiają trasę na gniazdzie, zanim się połączy. To pierwsze widać w ip rule; drugiego nie, i nie pojawi się w ogólnym wyszukiwaniu.

Jeśli program testowy zachowuje się inaczej niż aplikacja, którą ma reprezentować, sprawdź, czy aplikacja ustawia znacznik albo wiąże się z urządzeniem. Ta różnica nie jest zagadką, gdy mechanizm zostanie nazwany, i wyjaśnia, dlaczego curl z powłoki i karta przeglądarki mogą na tej samej maszynie iść różnymi drogami. Obie techniki to routing oparty na polityce w szerokim sensie: wybierają drogę czymś innym niż cel. Żadna z nich nie autoryzuje ruchu i żadna nie zastępuje reguł zapory ani poświadczeń, których oczekuje partner.

Prześledź własność, zanim dodasz kolejną regułę

Reguły instaluje coś. Klient VPN, menedżer sieci i ręcznie napisany skrypt mogą każdy dodać reguły przy starcie, a logika ponownego połączenia może zostawić poprzedni zbiór. Dwie nieaktualne reguły z wcześniejszego profilu będą dalej kierować ruchem długo po usunięciu profilu.

Ustal, który proces jest właścicielem reguły, po jej priorytecie i kształcie, i sprawdź, czy ten właściciel przepisuje zbiór przy każdym połączeniu. Jeśli tak, ręczna reguła dodana dziś znika jutro, a poprawka należy do konfiguracji klienta, a nie do pliku historii powłoki. Wyczyszczenie całego zbioru reguł do testu to kuszący skrót o przewidywalnym koszcie: usuwa też reguły, których klient potrzebuje, aby jego własny tunel działał. Usuwaj po jednej regule albo testuj na maszynie, którą możesz uruchomić ponownie.

Udowodnij zakres dwoma przepływami, nie jednym

Poprawkę weryfikuje tylko przepływ, który powinien zostać dotknięty, i przepływ, który nie powinien. Wybierz cel, który polityka kieruje do tunelu, i jeden, który musi zostać na zewnątrz, a następnie porównaj wyszukiwania i przechwycenia dla obu:

ip route get 198.51.100.20 from 192.0.2.44
ip route get 198.51.100.21 from 192.0.2.44
tcpdump -ni any host 198.51.100.21 and port 443

Gdy dwa wyszukiwania zwracają różne interfejsy, reguła coś robi. Gdy zwracają ten sam interfejs, reguła pasuje szerzej, niż zamierzano, i to jest usterka, która po cichu wysyła całą podsieć przez tunel przeznaczony dla jednej aplikacji.

Zapisz priorytety reguł i usługę będącą właścicielem w zgłoszeniu, razem z dwoma adresami testowymi. Następna osoba ma wtedy powtarzalną parę zamiast opisu objawu i może w ciągu minuty powiedzieć, czy polityka routingu nadal działa.