IPsec ESP: co przenosi i jak udowodnić, że płynie
ESP w trybie tunelowym opakowuje wewnętrzny pakiet IP i identyfikuje swoją asocjację przez SPI. Przeczytaj stan, a potem obserwuj, jak jeden przepływ przesuwa liczniki.
ESP przenosi ruch w sieci VPN IPsec, a jego runbook zaczyna się od jednej zasady: przeczytaj asocjację bezpieczeństwa, zanim zmienisz politykę. Większość niewyjaśnionych zachowań ESP sprowadza się do selektora, który nie pasował, trybu, który założono zamiast przeczytać, albo licznika, którego nikt nie sprawdził, gdy wysyłano jeden przepływ. Trzy kroki poniżej ustalają, co co przenosi, dowodzą, że jeden przepływ tego używa, i zostawiają wycofanie, które nie zależy od pamięci. Każdy krok daje jedną obserwację wartą zapisania.
Poznaj pola, zanim je przeczytasz
ESP umieszcza nagłówek przed chronionymi danymi, a końcówkę za nimi. Nagłówek niesie indeks parametrów bezpieczeństwa, który określa, której asocjacji ma użyć odbiorca, numer sekwencyjny do wykrywania powtórzeń, a w końcówce dopełnienie, które utrzymuje ładunek wyrównany dla szyfru. Pole nagłówka następnego w końcówce mówi, co jest chronioną treścią, i tak odbiorca wie, co odszyfrował.
Tryb zmienia to, co jest wewnątrz tej ochrony. W trybie tunelowym chronionym materiałem jest pełny wewnętrzny pakiet IP, a nowy zewnętrzny nagłówek przenosi go między punktami końcowymi. W trybie transportowym ochrona obejmuje ładunek wyższej warstwy istniejącego pakietu, więc nie ma drugiego nagłówka IP do otwarcia. To, który tryb jest używany, jest faktem konfiguracji, a nie kwestią interpretacji. Przeczytaj go z wpisu stanu zamiast wnioskować z diagramu.
Żaden z trybów nie ukrywa zewnętrznego adresowania, które musi dostarczyć pakiet. To cecha projektu, a nie brak, i dlatego obserwator pośrodku nadal widzi, które dwa adresy rozmawiają, nawet gdy ładunek jest nieprzejrzysty.
Krok pierwszy: przeczytaj stan, potem politykę
Wpisy stanu trzymają klucze i liczniki; wpisy polityki trzymają selektory, które decydują, co może ich używać. W systemie Linux oba są widoczne bez przechwytywania pakietów, a czytanie ich w tej kolejności utrzymuje dwa pytania osobno.
ip xfrm state
ip xfrm policy
W wyniku stanu sprawdź źródło i miejsce docelowe asocjacji, tryb oraz to, czy enkapsulacja pokazuje porty UDP. Te porty oznaczają, że używane jest przechodzenie przez NAT, co zmienia to, na co musi pozwolić zapora pośrodku, ale nie to, które selektory lub klucze obowiązują na końcach.
Następnie przeczytaj selektory w polityce. Selektor, który wskazuje węższy prefiks niż testowany ruch, jest najczęstszą przyczyną wrażenia, że działający tunel ignoruje przepływ, a selektor dla niewłaściwego protokołu daje tę samą ciszę.
| Field | Where it appears | What it decides |
|---|---|---|
| Security parameter index | ESP header, and the receiving state entry | Which association and keys the receiver applies |
| Sequence number | ESP header | Replay detection for that association |
| Next header | ESP trailer | What the decapsulated payload contains |
| Inner IP header | Inside tunnel-mode payload only | The original source and destination the endpoints act on |
| Traffic selectors | Policy, not the packet | Which local traffic is allowed to use the association |
Narzędzia producentów drukują te same informacje w wygodniejszej formie. ipsec statusall w strongSwan wymienia asocjacje podrzędne, ich selektory i liczniki bajtów, co często jest szybsze niż czytanie surowego wyjścia xfrm, gdy już wiesz, na którą asocjację podrzędną patrzeć.
Krok drugi: udowodnij, że jeden przepływ przesuwa liczniki
Liczniki mają sens tylko wtedy, gdy wiesz, co powinno je przesunąć, więc wybierz źródło i cel, które selektor na pewno obejmuje, i wyślij jedno nieszkodliwe żądanie. Potem przeczytaj ten sam wpis ponownie i porównaj.
ip -s xfrm state
tcpdump -ni any esp
Dwa odczyty opowiadają różne historie. Pakiety, które rosną po stronie wychodzącej, ale nigdy po stronie przychodzącej, wskazują na problem z przekazywaniem lub drogą powrotną, a nie z kluczem, ponieważ pakiet został zaenkapsulowany i wyszedł. Jeśli żaden licznik się nie zmienia, ruch nigdy nie pasował do polityki, a selektor jest miejscem, w które trzeba patrzeć.
Przechwycenie w tym samym kroku potwierdza enkapsulację na łączu, w tym czy pakiety zewnętrzne są ESP, czy ESP zaenkapsulowanym w UDP. Pokazuje też adresy, które naprawdę przeniosły przepływ, a te czasem różnią się od tych w konfiguracji, którą czytałeś.
Krok trzeci: zmień jedną rzecz i zachowaj wycofanie
Zapisz źródło, cel, tryb, selektory i liczniki asocjacji, zanim cokolwiek edytujesz. Jeśli zmiana pogorszy sytuację, właśnie ten zapis pozwala przywrócić poprzedni stan, zamiast odbudowywać działającą konfigurację ze zgadywania. Zapis zajmuje minutę i oszczędza godzinę później. Jest też jedynym artefaktem, który przeżywa osobę, która dokonała zmiany.
Zmień jeden selektor lub jeden parametr, wczytaj go ponownie i powtórz krok drugi na tym samym przepływie. Usunięcie asocjacji zrywa każdy przepływ, który jej używa, więc ukierunkowana edycja i ponowne wczytanie asocjacji podrzędnej są prawie zawsze lepsze niż opróżnianie stanu, aby zobaczyć, co się stanie.
Wycofanie edycji selektora to przywrócenie poprzedniej polityki i ponowne jej wczytanie, z zastrzeżeniem, że partner może potrzebować odpowiadającej zmiany, jeśli selektor jest negocjowany, a nie lokalny. Zapisz tę zależność, dopóki jest świeża, ponieważ para przywrócona w połowie jest trudniejsza do przemyślenia niż którykolwiek z dwóch stanów końcowych.
Na koniec utrzymuj zakres uczciwie. Płynąca asocjacja ESP dowodzi, że dwie bramy chronią i dostarczają segment, i nie mówi nic o tym, czy aplikacja powyżej uwierzytelnia swoich użytkowników albo szyfruje to, co przechowuje. To osobne kontrole z osobnymi dowodami, a runbook jest gotowy dopiero wtedy, gdy następna osoba potrafi go powtórzyć z notatek.