IPsec w IPsec: jakie adresy musi przenosić tunel zewnętrzny

O zagnieżdżonym IPsec łatwiej myśleć, gdy obie warstwy kończą się na różnych maszynach. Cztery bramy, dwa tunele i jedno pytanie, które decyduje, czy projekt działa: co tunel zewnętrzny naprawdę widzi, gdy tunel wewnętrzny skończy z pakietem? Odpowiedz na to, a selektory, trasy i kolejność rozwiązywania problemów same się ułożą. Pomyl się, a spędzisz dzień na debugowaniu tunelu, który technicznie jest podniesiony.

Model czterech bram

Zewnętrzne bramy A i B budują pierwszy tunel między dwiema lokalizacjami. Za A stoi wewnętrzna brama C z adresem tranzytowym 10.60.0.2; za B stoi wewnętrzna brama D z adresem tranzytowym 10.70.0.2. Sieci aplikacji żyją za C i D, a każdy adres w przykładzie celowo się nie nakłada.

application net -> C -> A == outer IPsec == B -> D -> application net
                       \---------- inner IPsec ----------/

C transit: 10.60.0.2      D transit: 10.70.0.2
A and B:    underlay addresses only

Podział warstw na cztery hosty oznacza, że każda maszyna egzekwuje jedną granicę. Jeden host uruchamiający obie warstwy musi pogodzić dwa zestawy polityk, dwie tablice routingu i dwa tryby awarii na jednej maszynie, co jest możliwe i znacznie trudniejsze do zaobserwowania.

Każda warstwa usuwa tylko własną ochronę

C szyfruje pakiet aplikacji dla D. Wynik jest adresowany z C do D i to dociera do A. Wszystko poniżej zależy od tego przepisania.

A szyfruje go ponownie dla B. B odszyfrowuje warstwę zewnętrzną, widzi pakiet z C do D i przekazuje go nadal zaszyfrowany. D usuwa ochronę wewnętrzną i dostarcza pakiet aplikacji.

Tak więc A i B widzą wewnętrzne punkty końcowe i ich metadane, ale nie są stronami, które odszyfrowują ładunek aplikacji. To rzeczywista właściwość projektu, a nie twierdzenie, że C, D lub hosty aplikacji są godne zaufania.

Zewnętrzne selektory nazywają wewnętrzne bramy

Tu zawodzi większość takich konstrukcji. Dla tunelu zewnętrznego opartego na politykach selektory, które negocjujesz, muszą zawierać adresy, którymi A i B naprawdę się zajmują: 10.60.0.2/32 i 10.70.0.2/32, we właściwej kolejności lokalnej i zdalnej.

Umieszczenie końcowych podsieci aplikacji w selektorach zewnętrznych nie działa, bo zanim pakiet dotrze do A, wewnętrzna enkapsulacja już przepisała to, co A musi chronić. Zewnętrzna polityka nie dopasowałaby wtedy niczego, a tunel podniósłby się, nie przenosząc danych.

Nie zawężaj też zewnętrznego zezwolenia do UDP 500. Połączenie wewnętrzne ma własną ścieżkę danych, która używa ESP lub enkapsulacji UDP w zależności od tego, co wynegocjowano, a polityka zewnętrzna musi zezwalać na ten protokół.

Sprawdź wynik za pomocą swanctl --list-sas na każdej bramie i potwierdź, że skojarzenia bezpieczeństwa potomne zgłaszają zamierzone adresy, a nie te, które założyłeś. Jeśli lista pokazuje podsieci aplikacji, polityka zewnętrzna została napisana dla złej warstwy. Popraw selektory, zanim zaczniesz debugować routing, bo routing będzie wyglądał dobrze, a liczniki się nie ruszą.

Przekazywanie i pułapka rekurencji

Selektory nie zastępują routingu. A i B muszą przekazywać ruch między C i D w obu kierunkach, co oznacza włączone przekazywanie IP, trasy wskazujące na tunel i ścieżkę powrotną istniejącą po drugiej stronie.

Jeśli tunel zewnętrzny używa interfejsów XFRM, trasy wybierają interfejs, podczas gdy wynegocjowane polityki nadal ograniczają to, co on przenosi. Interfejs nie poszerza chronionego obszaru; zmienia tylko sposób, w jaki jądro przejmuje pakiet.

Pułapką jest rekurencja. Trasa A do zewnętrznego punktu końcowego B musi podążać za siecią bazową, a nie za tunelem, który buduje A, inaczej enkapsulacja próbuje podróżować w sobie samej i połączenie nigdy się nie kończy.

Sprawdź translację, zanim dodasz warstwy

Przyjrzyj się każdemu source NAT na A i B, zanim dostroisz cokolwiek innego. Reguła, która przepisuje adres C przed zastosowaniem polityki IPsec, może zepsuć uzgodnione selektory i może też zmienić to, co D odbiera po drugiej stronie.

Szeroki maskarading nie staje się bezpieczniejszy przez dwie warstwy. Ukrywa, który adres widzi strona odległa, a to dokładnie ta informacja, której potrzebujesz, gdy tunel jest podniesiony, a aplikacja nie działa.

Jeśli reguła NAT jest naprawdę konieczna, zapisz, z którym adresem każda strona uważa, że rozmawia. Ta jedna linia rozstrzyga większość sporów o to, czy winny jest tunel, czy translacja. Mówi też następnemu inżynierowi, gdzie patrzeć, gdy reguła zostanie usunięta rok później. Ping nic z tego nie zrobi.

Udowodnij fail-closed i sprawdź MTU

Zniknięcie trasy samo w sobie nie jest polityką fail-closed. Inna tabela, trasa domyślna lub reguła polityki mogą po cichu zapewnić obejście, a jedynym sposobem, by to wiedzieć, jest opuszczenie tunelu zewnętrznego i obserwacja, co robi ruch aplikacji. Zrób to celowo, w oknie serwisowym, zamiast odkrywać to przypadkiem.

Przetestuj trzy stany: tunel zewnętrzny wyłączony, tunel wewnętrzny wyłączony i odzyskanie po powrocie obu. Używaj liczników polityk na każdej bramie, ponieważ dwie ustanowione sesje IKE dowodzą tylko, że negocjacja płaszczyzny sterowania się powiodła.

Zaplanuj obie enkapsulacje. Działający IKE to wynik małych pakietów, a pakiety aplikacji pełnej wielkości nadal mogą zawieść po dodaniu dwóch nagłówków; testuj ze znanym rozmiarem ładunku na rzeczywistej ścieżce, zamiast zakładać, że liczby się sumują. Arytmetyka jest łatwa, ścieżka nie.