AWS Client VPN jest połączony, ale EC2 nadal nie odpowiada

Mój laptop pokazywał połączony. Klient AWS Client VPN pokazywał swój zielony stan, endpoint zapisał sesję, a mimo to nie mogłem otworzyć portu MongoDB na instancji EC2 w prywatnej podsieci. Nic nie było widocznie zepsute: certyfikat był ważny, profil pochodził z konsoli, a tunel przenosił ruch. Błąd był mój, bo czytałem połączony jako autoryzowany.

Logowanie odpowiada dokładnie na jedno pytanie: czy ta tożsamość może ustanowić sesję? Wszystko po tym rozstrzygają osobne reguły, które nigdy nie widzą twojego certyfikatu. Sesja, która się uwierzytelnia, i pakiet, który dociera, to dwa różne sukcesy, a szczelina między nimi to miejsce, w którym żyje większość zgłoszeń typu VPN działa, ale host jest nieosiągalny.

Poniższe kontrole to kolejność, której teraz używam.

Co naprawdę dowodzi połączona sesja

Podczas handshake endpoint weryfikuje certyfikat klienta względem swojego trust store albo przekierowuje przeglądarkę do twojego dostawcy tożsamości, gdy skonfigurowano SAML. Jeśli to przejdzie, klient otrzymuje adres z CIDR klienta endpointu, a konsola pokazuje aktywne połączenie. W żadnym momencie tej wymiany nic nie pyta, czy możesz dotrzeć do 10.0.4.17 na porcie 27017.

Zezwolenie na cel to osobny obiekt na endpoincie. Każdy przepływ jest porównywany z regułami autoryzacji, a każda z nich łączy CIDR celu z grupą, której reguła jest przyznana. Gdy żadna reguła nie obejmuje celu, endpoint akceptuje sesję i odrzuca ruch. Nie ma banera, nie ma pętli ponownego łączenia i niczego w interfejsie klienta, co mówi odmówiono.

Porównaj regułę autoryzacji z zasobem, nie z VPC

Wypisz reguły i połóż je obok adresu, który instancja naprawdę ma:

aws ec2 describe-client-vpn-authorization-rules \
  --client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8

Wyjście pokazuje CIDR celu i identyfikator grupy dla każdej reguły. Kryją się w nim dwa błędy. Reguła może autoryzować 10.0.0.0/16, podczas gdy instancja siedzi w VPC połączonej peeringiem na 10.1.0.0/16; trasa peeringu istnieje, ale nikt nie napisał reguły autoryzacji dla drugiego zakresu. Albo reguła wskazuje grupę katalogową, do której użytkownik należy w katalogu, ale nie w grupie, którą ocenia endpoint.

Napisz najwęższą regułę, która obejmuje cel, a drugą dodaj tylko wtedy, gdy drugi CIDR jest naprawdę potrzebny. Szeroka reguła 0.0.0.0/0 z szybkiego startu działa i właśnie dlatego przeżywa do produkcji i ukrywa model.

Dwie tabele tras decydują, czy pakiet się poruszy

Trasa endpointu mapuje CIDR celu na jedną z podsieci, z którymi endpoint jest powiązany. To połowa drogi. Własna tabela tras podsieci nadal musi wiedzieć, jak przekazać pakiet dalej, i ma to znaczenie w chwili, gdy cel jest za połączeniem peeringowym, bramą tranzytową albo zakresem lokalnym osiągalnym przez tunel site-to-site.

aws ec2 describe-client-vpn-routes \
  --client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8

Szukaj trasy, której cel odpowiada CIDR zasobu, a celem jest powiązana podsieć. Jeśli trasy brakuje, dodaj ją. Jeśli jest, a host nadal milczy, szczelina jest po stronie VPC, więc porównaj z tabelą tras podsieci skojarzenia.

Jedno ustawienie po stronie klienta psuje trasowanie, nie psując tunelu: profil zawierający route-nopull. Dyrektywa każe klientowi opartemu na OpenVPN ignorować trasy wypychane przez serwer, więc interfejs wstaje tylko z własnym adresem endpointu, a cel po prostu nie ma trasy. Sprawdź za pomocą ip route show na Linuksie lub netstat -rn na macOS, czy istnieje trasa przez interfejs tun. Jeśli nie, usuń route-nopull z wyeksportowanego profilu i połącz się ponownie, aby wypchnięte trasy zostały zastosowane.

Grupy zabezpieczeń nie widzą adresu twojego klienta

To jest część, którą przez całe popołudnie miałem błędnie. Dla endpointu IPv4 powiązanego z podsiecią usługa tłumaczy adres źródłowy klienta na adres interfejsu sieciowego endpointu w tej podsieci. Pakiet, który dociera do instancji, nie niesie adresu pokazanego przez twojego klienta, więc reguła grupy zabezpieczeń zezwalająca na pulę klientów, powiedzmy 172.16.0.0/22, nie pasuje do niczego.

Zezwól na port z grupy zabezpieczeń endpointu, która jest przypięta do interfejsu skojarzenia, a nie z CIDR klienta. Odwołanie do grupy jest trwalsze niż zapisany na stałe adres, bo adresem interfejsu nie zarządzasz ty. Sieciowe ACL są bezstanowe, więc tam, gdzie istnieją wpisy niestandardowe, zarówno kierunek wejściowy, jak i wyjściowy muszą przepuszczać przepływ.

Połącz się też z adresem prywatnym instancji. Publiczny IP wyprowadza pakiet z VPC i wprowadza go z powrotem inną drogą z innymi regułami, więc test na adresie publicznym nic nie mówi o drodze prywatnej.

Kolejność izolacji, która zatrzymuje się na pierwszej awarii

Przejdź przez te punkty po kolei i zatrzymaj się tam, gdzie jeden zawiedzie. Każdy krok wyklucza jedną warstwę, a nie wszystkie.

1. Potwierdź, której tożsamości użyła sesja i którą grupę ocenia endpoint. Certyfikat z jednego trust store nie jest tym samym podmiotem co asercja SAML z katalogu.
2. Potwierdź, że reguła autoryzacji obejmuje CIDR zasobu dla tej grupy.
3. Potwierdź, że trasa endpointu istnieje i wskazuje powiązaną podsieć, a następnie że tabela tras podsieci potrafi przekazać dalej.
4. Potwierdź, że grupa zabezpieczeń zezwala na port z interfejsu endpointu, a nie z puli klientów.
5. Przetestuj od wewnątrz VPC, sesją SSM na innej instancji w tej samej podsieci, aby oddzielić problem aplikacji od problemu drogi klienta.

Gdy kroki nie są rozstrzygające, opieram się na tej tabeli:

Dwa szczegóły konta dają objawy wyglądające jak błędy uprawnień. Każdy użytkownik potrzebuje osobnego certyfikatu klienta; dzielenie jednego między dwie maszyny sprawia, że sesje wypychają się nawzajem, a wynikiem jest pętla ponownego łączenia, nie odmowa. Gdy tworzony jest nowy endpoint, konsola pokazuje nazwę DNS, którą niektóre wersje klienta akceptują tylko z losowym prefiksem widocznym na stronie endpointu, więc skopiuj pełną nazwę, zamiast ją odtwarzać.

Jeśli piąty krok cię zablokuje, pobierz dziennik połączeń endpointu i przeczytaj wpisy autoryzacji, zanim cokolwiek zmienisz. Dziennik nazywa sprawdzony cel i regułę, która pasowała lub nie, a to sprowadza pytanie o czterech warstwach do jednej odpowiedzi.