Od strongSwan do AWS Site-to-Site: dlaczego Child SA nic nie wybiera

Tunel IKE może być aktywny, podczas gdy skojarzenie potomne wyklucza Twoje podsieci. Najpierw porównaj lokalny i zdalny CIDR w AWS z leftsubnet i rightsubnet.

Konsola pokazuje up, strongSwan zgłasza ustanowione skojarzenie IKE, a pakiety nadal nie docierają. Następną rzeczą do porównania nie jest klucz wstępnie współdzielony, lecz para prefiksów, które każda strona uważa za chronione przez tunel. Przejdź przez poniższe kontrole po kolei, bo pierwsze dwie decydują, czy tunel w ogóle może przenosić Twój ruch.

Przetłumacz nazwy AWS na terminy strongSwan

AWS opisuje połączenie od strony klienta: adres bramy klienta i lokalny CIDR należą do Ciebie, a zdalny CIDR należy do VPC. strongSwan nazywa oba końce left i right, Twój prefiks jest w leftsubnet, a prefiks VPC w rightsubnet. Odwrócenie jednej pary daje tunel, który negocjuje i wybiera niewłaściwy ruch.

Pobierz konfigurację, którą AWS generuje dla połączenia, i traktuj ją jako odniesienie właśnie dla tego połączenia, wraz z adresami i prefiksami tunelu. Jeśli przy tworzeniu oba pola CIDR pozostaną puste, usługa użyje domyślnej wartości 0.0.0.0/0 po każdej stronie. Router skonfigurowany z wąskim prefiksem nigdy wtedy nie będzie pasować, więc albo wypełnij pola, albo świadomie poszerz selektor.

Niezgodność tutaj wygląda jak awaria routingu i nią nie jest.

Ustal adres, który AWS faktycznie widzi

Router za NAT może wysyłać IKE z interfejsu, o którym druga strona nigdy się nie dowiedziała. Adres bramy zapisany w AWS musi być tym, który AWS obserwuje w sieci, a router trzeba przypiąć do tego samego adresu lokalnego, zamiast pozwalać mu iść trasą domyślną.

conn %default
    local_addrs = 203.0.113.10

W strongSwan local_addrs wybiera adres źródłowy dla IKE, a starsze konfiguracje OpenSwan zapisują ten sam pomysł jako left. Skieruj go na interfejs z adresem publicznym, następnie sprawdź na samym urządzeniu NAT, czy UDP 500 i 4500 docierają do tego hosta, bo reguła pozostała po wcześniejszym routerze po cichu je odrzuca. Poprawna para selektorów z błędnym adresem źródłowym nadal zawodzi, a dziennik obwini propozycję. To właśnie owo wprowadzanie w błąd sprawia, że adres źródłowy zasługuje na własną kontrolę.

Potwierdź regułę przekazywania, zamiast ją zakładać, bo reguła, która była poprawna dla poprzedniego routera, często zostaje.

Traktuj fazę 1 i fazę 2 osobno

AWS pokazuje opcje IKE i ESP jako osobne listy. Zestaw IKE akceptowany przez obie strony nic nie mówi o propozycji ESP, bo obie listy są niezależne. Odczytaj oba z wygenerowanej konfiguracji i porównaj je pojedynczo.

conn aws
    ike = aes256-sha1-modp1024
    esp = aes256gcm16

Składnia nie podróżuje między implementacjami. Para działająca w OpenSwan, na przykład phase2alg=aes_gcm z ike=aes256-sha1;modp1024, wymaga przełożenia na formę esp= i ike= strongSwan, a nazwy algorytmów się różnią. Ponieważ GCM uwierzytelnia podczas szyfrowania, nie potrzebuje osobnej transformacji integralności, inaczej niż zestaw CBC zestawiony z SHA. Wiersz fazy 2 wklejony z jednego demona do drugiego bez tłumaczenia daje odrzucenie, które czyta się jak niezgodność selektorów.

Sprawdź skojarzenie potomne, a nie wskaźnik tunelu

Jeśli połączenie się ładuje, ale żadne skojarzenie potomne nie powstaje, odrzucono propozycję albo selektory. Jeśli potomne powstaje, a jego selektory wykluczają Twoje prefiksy, pakiety są filtrowane, zanim dotrą do tunelu. Wskaźnik konsoli obejmuje tylko poziom IKE, więc nie powie Ci, które z dwóch rzeczy się stało.

ipsec statusall

Znajdź skojarzenie bezpieczeństwa potomne i odczytaj wydrukowane obok selektory ruchu, a potem porównaj je z prefiksami z wygenerowanej konfiguracji.

Testuj z hosta w lokalnym prefiksie do hosta w prefiksie VPC i sprawdź drogę powrotną oraz dowolną grupę zabezpieczeń lub sieciową ACL po stronie AWS. Poprawne selektory nie chronią pakietu przed późniejszym odrzuceniem.

Gdy nadal nie działa po dopasowaniu selektorów

Potwierdź, że trasa po obu stronach prowadzi do tunelu, a następnie potwierdź, że urządzenie NAT nie przepisuje ruchu w sposób, którego polityka się nie spodziewa. Tunel oparty na polityce dopasowuje adresy pakietów, więc tłumaczenie zastosowane po decyzji polityki zmienia wynik.

Zarejestruj jeden pakiet przychodzący i jeden wychodzący po każdej stronie, zanim zmienisz kolejną propozycję.

Zapisz selektory, propozycje fazy 1 i fazy 2 oraz adres źródłowy w zgłoszeniu. Te cztery wartości wyjaśniają większość awarii site-to-site bez telefonu.

Powiązane artykuły