Monitorowanie interfejsu tunelu IPsec: co czytać

Projekt IPsec oparty na trasach instaluje interfejs wirtualny, a ten interfejs daje monitorowaniu konkretny obiekt: coś z nazwą, licznikami i przypisaną do niego trasą. Sam w sobie nie jest sygnałem kondycji. Interfejs może istnieć, gdy nie jest zainstalowane żadne użyteczne skojarzenie, a skojarzenie może być zdrowe, gdy żadna trasa nie kieruje do niego ciekawego ruchu. Dopiero wspólne odczytanie czterech stanów zamienia licznik pakietów w diagnozę.

Przejdź je po kolei i zatrzymaj się na pierwszym, które zawiedzie.

Co interfejs wnosi do obrazu

W projekcie opartym na politykach wybór mieszka w tabeli polityk IPsec, a jądro decyduje, co jest chronione, na podstawie selektorów ruchu. Projekt oparty na trasach dodaje interfejs i trasę, więc tcpdump i liczniki interfejsu widzą jedną granicę zamiast zbioru selektorów. To realna korzyść dla diagnostyki i dla protokołów routingu, które potrzebują interfejsu do peeringu.

Korzyść jest administracyjna, nie kryptograficzna. Interfejs raportuje ruch, który przenosi, i nie mówi nic o tym, czy ochrona po stronie partnera jest obecnie użyteczna.

Odczytaj cztery stany, zanim obwinisz tunel

Zacznij od interfejsu i trasy, potem od skojarzenia, potem od aplikacji. Każde ma własne polecenie i własną sygnaturę awarii. Czysty wynik na jednej warstwie nie jest czystym wynikiem na następnej. Wykonaj wszystkie cztery, zanim wyciągniesz wniosek. Jedna zielona linia rzadko coś rozstrzyga.

ip -s link show xfrm0
ip route get 10.20.30.40
ip xfrm state
ip xfrm policy
swanctl --list-sas
tcpdump -ni xfrm0 -c 20 host 10.20.30.40

Interfejs z rosnącym licznikiem, ale bez pasującego wpisu stanu, opisuje ruch wchodzący na ścieżkę, na której nic go nie chroni, co jest gorsze niż tunel, który po prostu padł. Wpis stanu bez trasy wybierającej interfejs oznacza, że kryptografia jest gotowa i niewykorzystana.

Test aplikacji przychodzi ostatni i celowo: udany ping na drugą stronę tunelu nie dowodzi, że usługa za nim przyjmuje połączenia.

Porównaj liczniki wewnętrzne z zewnętrznymi

Liczniki na interfejsie tunelu mierzą ruch wewnętrzny; liczniki i przechwycenia na interfejsie fizycznym pokazują wymianę enkapsulowaną. Te dwa nie będą zgodne jeden do jednego, bo enkapsulacja dodaje nagłówki, retransmisje duplikują niektóre pakiety, a rozliczanie w implementacji rządzi się własnymi zasadami. Oczekuj proporcji, nie równości.

Miejsce przechwycenia decyduje też, jakie dane prywatne zbierasz, więc używaj wąskich filtrów i nieszkodliwego adresu testowego zamiast pełnego przechwycenia ruchu produkcyjnego.

Jeśli liczniki wewnętrzne rosną, a zewnętrzne nie, brakującym krokiem jest zwykle trasa lub polityka, która wysyła pakiety do tunelu, a nie sam tunel.

Obserwuj to podczas wymiany kluczy i przełączenia

Obserwuj wymianę kluczy, zdarzenie wykrycia martwego partnera i przełączenie łącza, śledząc te same cztery stany. Interfejs może pozostać obecny podczas wymiany kluczy, która nigdy się nie kończy, a przełączenie może zostawić wpis stanu wskazujący na adres partnera, który nie jest już osiągalny.

Alarmuj o ścieżce usługi, od której naprawdę zależysz, ze stanem skojarzenia jako kontekstem, a nie o pojedynczej fladze góra lub dół. Zachowaj nazwę interfejsu, adres partnera i trasę w ładunku alarmu, aby reagujący nie musiał ich odtwarzać.

strongSwan dokumentuje własny model interfejsu XFRM, a inne platformy inaczej nazywają i implementują równoważny obiekt. Przeczytaj porównanie oparte na trasach dla urządzenia, które masz przed sobą, zanim przeniesiesz założenia z innej implementacji. Szablon monitorowania dopasowany do liczników jednego dostawcy po cichu wprowadzi w błąd przy innym.