strongSwan na EC2: niech VPC kieruje obciążeniem

Tunel działa, instancja bramy może pingować sieć zdalną, a instancja aplikacji obok nie sięga niczego. Nic nie jest zepsute. Test, który się udał, zaczynał się na hoście VPN i nigdy nie zapytał, czy ten host może przenieść inny adres źródłowy przez tę samą relację IPsec. Ten runbook zamyka tę lukę w czterech krokach, w kolejności, która pozostawia każdy błąd widocznym.

Najpierw zapisz cztery adresy

Każdy krok poniżej się do nich odwołuje, więc wypełnij je dla własnego konta, zanim dotkniesz tabeli tras.

VPC:             10.60.0.0/16
Gateway subnet:  10.60.1.0/24, gateway ENI address 10.60.1.10
Workload subnet: 10.60.2.0/24, application address 10.60.2.20
Remote network:  10.90.0.0/24

Przykład zakłada zatwierdzone, działające połączenie IPsec oparte na politykach oraz przepływ zachowujący źródło. To nie jest klient dostępu zdalnego za NAT-em, który pożycza jeden przydzielony adres, i ta różnica decyduje, czy selektory muszą się zmienić.

Krok 1: daj podsieci obciążenia trasę

Tabela tras faktycznie powiązana z podsiecią obciążenia potrzebuje ścieżki do prefiksu zdalnego wskazującej na interfejs sieciowy bramy. Trasa gościa zainstalowana wewnątrz instancji nie jest wpisem w tej tabeli tras AWS i żadna konfiguracja strongSwan jej nie utworzy.

Wskazówki AWS dotyczące routingu przez urządzenie opisują cele interfejsu sieciowego i wymóg sprawdzania źródła/docelowego instancji przekazującej. Ogranicz tę zmianę sprawdzania do roli bramy i zostaw zwykłe instancje aplikacji w spokoju.

Nie zastępuj trasy lokalnej VPC ani każdego istniejącego wpisu, aby zrobić miejsce dla jednej zatwierdzonej sieci. Sprawdź, co jest powiązane i aktywne, a nie to, co pokazuje strona konsoli dla tabeli tras, której nikt nie używa. Dwie podobnie wyglądające tabele mogą mieć różne powiązania. Liczy się ta, do której podłączona jest podsieć obciążenia.

Krok 2: włącz przekazywanie na gościu

sysctl -w net.ipv4.ip_forward=1
# persist in /etc/sysctl.d/ and re-apply after reboot

Jądro musi przekazywać, a firewall hosta musi zezwalać na tranzyt. Dodaj zamierzone reguły przekazywania dla prefiksów obciążenia i zdalnych zamiast akceptować wszystko, i potwierdź, że podsieć bramy zachowuje użyteczną trasę transportową dla własnego ruchu.

Grupy zabezpieczeń to miejsce, w którym ten krok zwykle się zatrzymuje. Urządzenie pośredniczące nie dziedziczy zachowania referencji grup zabezpieczeń bezpośredniej komunikacji instancji, więc reguła skopiowana z przykładu zarządzanego Client VPN może nigdy nie pasować. Sprawdź grupę zabezpieczeń i ACL podsieci na rzeczywistej ścieżce, w obu kierunkach.

Krok 3: rozszerz selektory na rzeczywiste źródła

Polityka obejmująca po stronie AWS tylko 10.60.1.10/32 wyjaśnia sukces rozpoczęty na bramie, nie obejmując 10.60.2.20. Trasa do celu zdalnego nie rozszerza selektora ruchu, i to jest druga połowa tej samej niespodzianki.

swanctl --list-sas
# read the installed CHILD-SA local and remote traffic selectors

Jeśli uzgodniony projekt chroni całą VPC, obie strony muszą akceptować 10.60.0.0/16 i 10.90.0.0/24. Jeśli chroni jedno obciążenie, świadomie użyj tego węższego prefiksu. W każdym razie sprawdź zainstalowaną politykę CHILD-SA, ponieważ konfiguracja, którą edytowałeś, i strona, która zawęziła ją inaczej, to nie ta sama umowa.

Lokalizacja zdalna musi także kierować odpowiedzi dla zachowanych źródeł VPC z powrotem przez zamierzoną bramę IPsec. Zachowaj obsługiwane wyłączenie NAT dla ruchu chronionego tam, gdzie istnieją inne reguły NAT źródła; tłumaczenie niezatwierdzonego obciążenia na dozwolony adres hosta to inny kontrakt tożsamości, a nie skrót do dostępu, którego chciałeś.

Krok 4: zweryfikuj, a potem wycofaj, jeśli trzeba

Przetestuj z samego obciążenia nową dozwoloną operacją aplikacji, a potem powtórz z celem, który powinien być wykluczony. Zapisz adres źródłowy, który widzi usługa zdalna, i ścieżkę powrotną, której używa. Ping bramy lub zielony status IKE nie są tym testem.

Jeśli obciążenie nadal zawodzi, a brama działa, cofaj się po krokach po kolei: selektor, potem przekazywanie i grupy zabezpieczeń, potem powiązana tabela tras. Każdy ma inny objaw, a zgadywanie pomija ten, który jest naprawdę błędny.

Wycofanie odwraca tę samą kolejność. Usuń trasę podsieci obciążenia na końcu, po przywróceniu poprzednich selektorów, żeby nie zostawić podsieci wskazującej na bramę, która nie chroni już jej źródeł. Hostowanie własne może obsłużyć więcej niż host bramy, gdy te kontrakty obowiązują, a Site-to-Site VPN zarządzany przez AWS to inny model działania, w którym strongSwan może siedzieć po stronie bramy klienta.