Jak działa IPsec oparty na trasach z interfejsem XFRM

IPsec oparty na trasach przekazuje tabeli routingu decyzję, którą wcześniej podejmowały selektory polityki. W Linuksie elementem, który to umożliwia, jest interfejs XFRM: urządzenie wirtualne, którego ruch jest dopasowywany do stanu IPsec przez identyfikator interfejsu, a nie przez selektor. Utworzenie jednego zajmuje jedno polecenie i niczego nie dowodzi w kwestii istnienia tunelu. Urządzenie jest hakiem między routingiem a polityką bezpieczeństwa i obie strony tego haka muszą być skonfigurowane, zanim cokolwiek zostanie ochronione.

Czym to urządzenie jest, a czym nie jest

Interfejs XFRM to uchwyt routingu. Pakiety routowane do niego są dopasowywane do polityk XFRM, które odwołują się do tego samego identyfikatora interfejsu, a jeśli istnieją polityka i stan, są enkapsulowane. Bez nich interfejs istnieje, liczniki stoją, a ruch idzie donikąd użytecznie.

To pierwszy podział diagnostyczny. Trasa do urządzenia jest faktem routingu, zainstalowany stan jest faktem bezpieczeństwa, a rosnący licznik na urządzeniu nie jest ani jednym, ani drugim. Kiedy ludzie mówią, że tunel jest podniesiony, bo interfejs pokazuje UP, opisują flagi łącza urządzenia wirtualnego, które nie ma własnego peera. Flaga oznacza, że urządzenie zostało utworzone i włączone, nic więcej.

Jeszcze jedna granica: identyfikator interfejsu nie jest nazwą. Dwa urządzenia o podobnych nazwach i różnych identyfikatorach nie dzielą stanu, a połączenie skonfigurowane z błędnym identyfikatorem instaluje stan, którego żadna trasa nigdy nie użyje.

Zbuduj jedno we właściwej kolejności

Zacznij od urządzenia zewnętrznego i liczby, którą umieścisz także w konfiguracji demona. Przykład używa eth0 jako interfejsu zewnętrznego i 42 jako identyfikatora, adresy te należy zastąpić własnymi.

Podnieś urządzenie, a następnie potwierdź identyfikator zapisany przez jądro, zanim dotkniesz konfiguracji VPN:

sudo ip link add xfrm0 type xfrm dev eth0 if_id 42
sudo ip link set xfrm0 up
ip -d link show xfrm0 | grep -o 'if_id [0-9]*'

Teraz skonfiguruj połączenie w strongSwan z tym samym identyfikatorem, ponieważ demon musi zainstalować polityki i stany, które się do niego odwołują. Ustaw lokalne i zdalne selektory ruchu na zakres, który zamierzasz routować, a następnie routuj ten zakres do urządzenia. Konfiguracja demona i tabela routingu muszą się zgadzać zarówno co do identyfikatora, jak i miejsc docelowych, i żadna nie dostarcza drugiej.

Trzymaj IKE i ESP poza trasą tunelu

Trasa domyślna wskazująca do urządzenia XFRM przechwytuje zarówno pakiety enkapsulowane, jak i ruch, który one niosą. Wynikiem jest pętla: brama próbuje wysłać własny ESP przez tunel, który ESP ma zbudować.

Rozwiązaniem jest bardziej szczegółowa trasa dla zewnętrznego adresu peera przez interfejs fizyczny, która wygrywa z trasą domyślną, ponieważ dopasowuje więcej bitów. Routing oparty na znacznikach robi to samo, gdy kilka tuneli dzieli jedną tabelę, a strongSwan dokumentuje oba podejścia dla wdrożeń opartych na trasach.

Cokolwiek wybierzesz, sprawdź, czy pakiet zewnętrzny wychodzi nieenkapsulowany. Szybkim testem jest ping zewnętrznego adresu peera po podniesieniu tunelu; jeśli to zawiedzie, gdy interfejs jest podniesiony, podejrzewaj przechwycenie, a nie osiągalność. To samo rozumowanie dotyczy portu IKE, ponieważ własny ruch UDP demona nie może być routowany do urządzenia, które próbuje on ustanowić.

Sprawdź liczniki w dwóch miejscach, zanim obwinisz szyfrowanie

Liczniki interfejsu i liczniki stanu mierzą różne etapy. Pakiety routowane do urządzenia zwiększają licznik urządzenia nawet wtedy, gdy żaden stan nie pasuje, natomiast liczniki stanu ruszają się tylko dla ruchu, który faktycznie został enkapsulowany.

Przeczytaj oba, a potem przeczytaj widok demona na asocjację potomną:

ip -s link show xfrm0
sudo ip xfrm state list | grep -E 'src|proto|mode'
sudo swanctl --list-sas

Rosnące liczniki urządzenia przy pustym wyjściu stanu oznaczają, że routing działa, a polityka nie pasuje, zwykle błąd identyfikatora lub selektora. Rosnące liczniki stanu, gdy druga strona nic nie zgłasza, oznaczają, że pakiety wychodzą, ale nie docierają lub nie przechodzą uwierzytelnienia, co wskazuje na ścieżkę lub konfigurację peera. Wymieniona asocjacja potomna z zerowym ruchem to problem selektora po jednej stronie, a nie zepsuty szyfr.

Zdecyduj, kto instaluje trasy

Dwóch właścicieli jednej tabeli routingu to zwykłe źródło flappingu. Jeśli demon instaluje trasy automatycznie, twój menedżer sieci nie może także instalować trasy domyślnej przez to samo urządzenie, a trasa ręczna dodana przez skrypt startowy zostanie usunięta przy następnej rekonfiguracji demona.

Wybierz jednego właściciela i zapisz to. Gdy trasy należą do demona, trzymaj skrypt startowy poza tabelą i pozwól definicji połączenia opisać selektory ruchu. Gdy należą do menedżera sieci, wyłącz automatyczną instalację i zaakceptuj, że demon nie naprawi brakującej trasy przy ponownym połączeniu.

Reguły przekazywania i zapory to osobna decyzja ponad tym, ponieważ brama przepuszczająca ruch innych hostów potrzebuje obu. IPsec oparty na trasach czyni ten ruch łatwym do wyrażenia zwykłymi narzędziami routingu; nie czyni warstwy polityki opcjonalną.