VPN lokacja-lokacja oparty na trasach a oparty na politykach: co się różni

Oba projekty chronią ten sam ruch tą samą maszynerią IPsec i różnią się tym, co decyduje, który pakiet wchodzi do tunelu. W połączeniu opartym na politykach robią to wynegocjowane selektory ruchu; w połączeniu opartym na trasach robi to trasa wskazująca interfejs tunelu. Pomylenie obu daje znany wątek wsparcia, w którym tunel zgłasza się jako ustanowiony, a aplikacja do niczego nie dociera. Rozróżnienie ma największe znaczenie, gdy dodajesz sieć, uruchamiasz protokół routingu lub debugujesz ścieżkę, która po cichu wychodzi złym wyjściem.

Dwa sposoby decydowania, co wchodzi do tunelu

VPN oparty na politykach buduje politykę bezpieczeństwa dopasowaną do prefiksów źródła i celu, a następnie szyfruje wszystko, co pasuje. Druga strona musi wynegocjować zgodne selektory, więc efektywny zakres ostatecznie staje się przecięciem tego, co zaproponowały obie strony. Nic poza tym przecięciem nie jest chronione, cokolwiek mówi tablica routingu.

VPN oparty na trasach tworzy interfejs reprezentujący tunel i pozwala tablicy routingu wysyłać do niego ruch. Demon IKE nadal instaluje stan i politykę dla każdego interfejsu, i to jest szczegół pomijany, gdy uznaje się, że trasy zastąpiły szyfrowanie. Oba projekty szyfrują przez IPsec; różni się tylko mechanizm wyboru.

Czytaj poniższe porównanie jako zbiór sygnatur awarii, a nie tabelę wyników, bo żadna kolumna nie wygrywa sama z siebie.

Oparty na politykach: selektor jest umową

Selektory są negocjowane, a nie tylko konfigurowane. Zaproponuj 10.10.0.0/16 po jednej stronie i 10.10.1.0/24 po drugiej, a asocjacja obejmie to, na czym zatrzymały się negocjacje, podczas gdy każdy inny host pozostanie poza nią.

Czytaj zainstalowany stan, a nie plik konfiguracji. U partnera Linux własne tabele jądra są podstawową prawdą i pokazują, co przetrwało negocjacje. Polityka, która nazywa właściwe prefiksy bez pasującego stanu, oznacza, że asocjacja nigdy nie została podniesiona. Stan w parze z polityką dla niewłaściwego prefiksu to odwrotny problem i daje tunel, który wygląda zdrowo, podczas gdy jedna podsieć do niczego nie dociera.

sudo ip xfrm state
sudo ip xfrm policy
sudo swanctl --list-sas

Porównaj oba wyniki z prefiksami, które uważasz za chronione. To jedno porównanie rozwiązuje większość zgłoszeń o działającym tunelu z nieosiągalnym serwerem. Wskazuje też, którego partnera zmienić, ponieważ niezgodność zwykle widać tylko w jednym kierunku.

Oparty na trasach: interfejs jest umową

Interfejs XFRM nadaje tunelowi nazwę i tożsamość, a ruch do niego dociera, bo tak mówi tablica routingu. Kilka odległych prefiksów staje się wtedy problemem routingu, a nie problemem selektora, i protokół routingu może je ogłaszać. To jest prawdziwy zysk, nie szyfrowanie.

Interfejs nie usuwa potrzeby polityki. Demon instaluje reguły dla każdego interfejsu powiązane z tożsamością interfejsu, więc pakiet przychodzący na niewłaściwy interfejs nadal zawodzi. Adres źródłowy, którego partner nie zaakceptuje, również zawodzi, nawet przy idealnej trasie. Oparty na trasach znaczy, że trasa decyduje o wejściu, a nie że polityka zniknęła.

sudo ip link add xfrm0 type xfrm dev eth0 if_id 42
sudo ip route add 10.20.0.0/16 dev xfrm0
ip -s link show xfrm0
ip route get 10.20.5.10

Obserwuj liczniki interfejsu, gdy trasa jest już na miejscu. Trasa istnieje, a liczniki stoją na zerze, co oznacza, że nic nie jest dopasowywane do tunelu, i zwykle wskazuje na brakujący stan, a nie brakującą trasę.

Gdzie te dwa projekty naprawdę się rozchodzą

Dodanie sieci to najczystszy test tego, który model ci odpowiada. Projekt oparty na trasach dodaje trasę i najwyżej raz poszerza selektor, podczas gdy projekt oparty na politykach edytuje pary prefiksów u obu partnerów i negocjuje ponownie. Dwie stabilne podsieci czynią tę edycję trywialną, a dwadzieścia czyni z niej projekt.

Żaden model nie zastępuje zapory, a porównania zwykle kończą się przed tym punktem. Szeroki selektor lub szeroka trasa decydują, co jest szyfrowane, a nie co jest dozwolone.

Zachowanie MTU również różni się w praktyce. Enkapsulacja zmniejsza użyteczny ładunek, a interfejs oparty na trasach niesie własne MTU, więc przycinanie MSS na obu bramach pozwala uniknąć objawu czarnej dziury, w którym małe odpowiedzi docierają, a duże znikają. Tunele oparte na politykach napotykają tę samą ścianę z drugiej strony, bo selektor nie mówi nic o rozmiarze pakietu. Ustaw przycinanie świadomie, zamiast obwiniać partnera.

Migracja bez utraty trasy powrotnej

Zapisz istniejące pary prefiksów, zanim cokolwiek zmienisz, potem przenieś jedną ścieżkę aplikacji i obserwuj ją od początku do końca. Ustanowiony tunel to nie tunel, który przekazuje ruch, a różnica pojawia się w kierunku odpowiedzi.

Gdy partnerzy się łączą, ale hosty LAN nie, sprawdź trasę powrotną i adres źródłowy, którego użyje zdalny host. Host z dwoma interfejsami może odpowiedzieć z niewłaściwego, a żadna zmiana selektora tego nie naprawi. Przechwyć ruch na obu końcach, zanim zaczniesz edytować algorytmy.

ip route get 10.20.5.10
sudo tcpdump -ni any host 10.20.5.10 and icmp
sudo swanctl --list-conns

Utrzymuj ścieżkę zarządzania niezależną od tunelu, pracując. Wycofanie jest łatwiejsze, gdy własny dostęp bramy nie jedzie po połączeniu, które debugujesz.