AWS Client VPN: logowanie się udaje, ale podsieć pozostaje nieosiągalna

Klient pokazuje Connected, certyfikat jest ważny, a strona intranetu nadal kończy się przekroczeniem limitu czasu. Ta luka prawie nigdy nie jest uwierzytelnianiem. AWS Client VPN autoryzuje miejsca docelowe osobno od logowania, a dwie typowe przyczyny to wartość grupy niezgodna z tym, co wysłał dostawca tożsamości, oraz bardziej szczegółowa reguła miejsca docelowego, która wygrywa z szeroką. Obie są widoczne w konfiguracji endpointu, gdy wiadomo, gdzie patrzeć.

Logowanie się udało; reguła nie pasowała

Uwierzytelnianie odpowiada, kim jest użytkownik. Reguły autoryzacji odpowiadają, do których prefiksów sieci ta tożsamość może dotrzeć. Użytkownik może przejść pierwsze i nie przejść drugiego, a klient daje niewiele więcej niż połączenie, które się utrzymuje, podczas gdy każde żądanie kończy się przekroczeniem limitu czasu.

Zacznij od potwierdzenia, że endpoint ma regułę autoryzacji, której miejsce docelowe zawiera niedziałający adres. Jeśli nie ma pasującej reguły, połączenie zachowuje się poprawnie; brakuje polityki.

Skąd naprawdę pochodzi wartość grupy

W Active Directory pole access-group zawiera SID grupy, a nie jej nazwę wyświetlaną. W federacji SAML zawiera identyfikator lub nazwę grupy, którą skonfigurowany atrybut grupy SAML faktycznie przenosi. Skopiuj wartość z assertion lub z wyszukiwania w katalogu, a nie ze strony wiki.

Grupa IAM to inna płaszczyzna sterowania. Uprawnienie do administrowania endpointem Client VPN nie czyni grupy IAM grupą VPN użytkownika, a wklejenie nazwy grupy IAM w pole access-group nie tłumaczy jej na SID w AD ani na wartość atrybutu SAML.

Grupa o podobnej nazwie w innym katalogu niczego nie dowodzi. Sprawdź metodę uwierzytelniania endpointu oraz członkostwo lub assertion użytkownika w tym samym systemie.

Wygrywa najdłuższy prefiks, także 0.0.0.0/0

Autoryzacja jest oceniana według najdłuższego dopasowania prefiksu, a reguła dla wszystkich miejsc docelowych jest oceniana na końcu, nie na początku. Dodaj regułę 10.46.0.0/16 dla Engineering i regułę 0.0.0.0/0 dla wszystkich, a użytkownik spoza Engineering nadal nie dotrze do 10.46.20.10 przez szeroką regułę.

Tu poprawka może pójść źle. Usunięcie wąskiej reguły przywraca dostęp użytkownikowi i jednocześnie przyznaje tę podsieć każdej tożsamości objętej szeroką regułą. Zbuduj macierz grup i sieci, zanim cokolwiek usuniesz, i zapisz, które grupy mają docierać do którego zakresu. Te reguły tylko zezwalają; nie ma wpisu odmowy, którym wycięłoby się wyjątek z szerokiego zezwolenia.

Zmiany wymagają też nowego połączenia, aby można je było uczciwie ocenić. Po edycji reguł połącz klienta ponownie, a potem przetestuj jeszcze raz.

Oddziel autoryzację od ścieżki danych

Pasująca reguła nie jest trasą. Endpoint potrzebuje powiązanej podsieci i wpisu w tabeli tras dla miejsca docelowego, a grupa zabezpieczeń zasobu docelowego musi akceptować ruch. Ruch powrotny i DNS też muszą działać.

Przetestuj użytkownika, któremu powinno się udać, oraz użytkownika, który powinien pozostać wykluczony. Obaj mogą się zalogować, a tylko jeden dociera do podsieci, i właśnie ta różnica jest dowodem, którego szukasz.

Jeśli adres IP działa, a nazwa hosta nie, zajrzyj do resolvera, zanim ruszysz autoryzację. Jeśli żadna trasa nie obejmuje adresu, napraw powiązanie lub tabelę tras. Jeśli pakiet dociera, a usługa go odrzuca, następnym przystankiem jest polityka tej usługi. Rozszerzenie macierzy autoryzacji na wszystkich użytkowników ukrywa, która z tych warstw była naprawdę zepsuta.

Zanim zamkniesz zgłoszenie, zapisz źródło tożsamości, dokładną wartość grupy, prefiksy miejsca docelowego i trasę, która przenosi ruch. Taki zapis zamienia następne zgłoszenie połączenia bez dostępu w porównanie na dwie minuty, a nie kolejną rundę zgadywania.