Który pakiet musi dopasować polityka VPN z dwoma WAN?

Żądania kierowania VPN przez drugie łącze opisują co najmniej dwa różne zadania, a polityka, która naprawia jedno, nie dotyka drugiego. W pierwszym zadaniu szyfrowany transport między dwoma punktami końcowymi przenosi się na inny adres WAN. W drugim odszyfrowany przepływ aplikacji podłączonego użytkownika wychodzi w stronę innego następnego skoku. Oba są uzasadnione, oba korzystają z routingu, a każde potrzebuje dopasowania do pakietu, który istnieje w punkcie podejmowania decyzji. Przejdź przez poniższe kontrole po kolei, bo pierwsza decyduje, który pakiet mają nazwać późniejsze reguły.

Nazwij obie rozmowy

Wyobraź sobie zdalnego pracownika podłączonego do bramy biurowej, który otwiera HTTPS do wewnętrznego serwera aplikacji. Na łączu są dwie niezależne rozmowy i mają różne adresy na każdym końcu. Zewnętrzna rozmowa biegnie między dwoma punktami końcowymi VPN: od adresu bramy do adresu peera, w tym protokole i porcie, które wynegocjowało wdrożenie. Wewnętrzna rozmowa biegnie od adresu przydzielonego klientowi do adresu serwera aplikacji na porcie 443.

Port docelowy aplikacji to nie port transportowy VPN i żadna ilość polityki na TCP 443 nie przesunie tunelu. Podobnie reguła przekierowująca adres transportowy peera nic nie mówi o tym, dokąd trafia żądanie HTTP tego użytkownika po odszyfrowaniu. Zapisz obie rozmowy z ich rzeczywistymi adresami, zanim dotkniesz reguły, bo większość zamieszania w tej dziedzinie bierze się z nazywania jednej i konfigurowania drugiej.

Znajdź, gdzie Twoja polityka naprawdę widzi pakiet

Dopasowanie musi być oceniane w tym łańcuchu i przestrzeni nazw, w których pakiet jest jeszcze w opisanej przez Ciebie postaci. Reguła podpięta do wejścia LAN widzi pakiet wewnętrzny niezaszyfrowany, zanim zostanie skierowany do tunelu. Reguła zastosowana do ruchu generowanego lokalnie widzi pakiety, które tworzy sama brama, i nie obejmuje automatycznie ruchu, który brama tylko przekazuje. Zaszyfrowane wyjście to znów trzeci przypadek, zwykle obsługiwany na interfejsie niosącym tunel, a nie po stronie LAN.

Dlatego ten sam fragment konfiguracji zachowuje się różnie na dwóch platformach: punkty podpięcia są inne, a hak polityki dostawcy może znajdować się przed krokiem szyfrowania lub po nim. Czytaj ścieżkę pakietu dla konkretnego produktu, zamiast zakładać kolejność z diagramu innego dostawcy.

Potwierdź wynegocjowany transport

Dla IPsec zaszyfrowanego w UDP, RFC 3948 umieszcza ESP wewnątrz UDP i używa znacznika, który nie jest ESP, aby IKE pozostał rozróżnialny na współdzielonym porcie. Zwykły ESP to protokół IP, a nie port TCP lub UDP, więc reguła zapory napisana pod numer portu w ogóle go nie dopasuje. Ta różnica decyduje, czy Twoja polityka WAN potrzebuje reguły UDP, reguły protokołu, czy obu.

Wynegocjowane wartości biją zapamiętane. Odczytaj bieżące porty i adresy asocjacji z urządzenia, zamiast dodawać TCP 4500 lub stary port dostawcy na wszelki wypadek, co przechwytuje niepowiązany ruch i ukrywa rzeczywisty problem klasyfikacji.

Sprawdź drogę powrotną, zanim się zobowiążesz

Sukces na wyjściu dowodzi połowy projektu. Pakiet wracający do puli zdalnych klientów nie jest już widoczny pod adresem klienta, gdy enkapsulacja go zastąpi: zewnętrznym celem jest adres transportowy peera. Jeśli drugie łącze osiąga tego peera przez innego operatora, jego translacja i filtrowanie mogą się nie zgadzać z pierwszym, a asocjację może trzeba będzie raczej odtworzyć niż przenieść.

Stan translacji adresów sieciowych jest zwykłą ofiarą zmiany WAN. Zanotuj wybrane łącze, oczekiwany zewnętrzny adres źródłowy, używaną translację i osiągalność peera z powrotem, a potem utrzymuj transport osiągalny, nie wysyłając go do tunelu, który niesie.

Zweryfikuj obie warstwy dwoma przechwyceniami

Jedno przechwycenie na interfejsie WAN i jedno wewnątrz tunelu rozstrzygają pytanie szybciej niż jakiekolwiek porównanie konfiguracji. Uruchom je z bramy, gdy zatwierdzony klient wykonuje jedno żądanie, i zachowaj oba pliki.

sudo tcpdump -ni wan1 'udp port 4500' -c 20
sudo tcpdump -ni tun0 'tcp port 443 and host 203.0.113.10' -c 20
ip route get 203.0.113.10 from 10.8.0.6

Pierwsze przechwycenie powinno pokazać rozmowę zewnętrzną opuszczającą zamierzony interfejs, z oczekiwanym adresem źródłowym. Drugie powinno pokazać rozmowę wewnętrzną raz, bez duplikacji, z adresem klienta jako źródłem i serwerem aplikacji jako celem. Wyszukanie trasy potwierdza, której tablicy router użyłby dla tej pary źródło i cel, i właśnie tam zwykle ujawnia się błąd w polityce. Jeśli któregokolwiek przechwycenia nie widać, punkt decyzyjny jest gdzie indziej niż miejsce podpięcia reguły, a poprawka należy tam, a nie do szerszego dopasowania.