Który klient może dokończyć logowanie SAML w AWS Client VPN

Dwie osoby zadają to samo pytanie o AWS Client VPN i SAML i dostają przeciwne odpowiedzi. Jedna loguje się z laptopa z Ubuntu każdego ranka; druga ma telefon, pobrany profil i klienta, który odrzuca w nim jedną linię. Różnica to nie szczęście i nie ukryty przełącznik w panelu. Wszystko sprowadza się do trzech warunków: czy platforma jest jedną z tych, które AWS wspiera dla własnego klienta, czy narzędzie w Twojej ręce potrafi wykonać federacyjną wymianę w przeglądarce i czy punkt końcowy jest w ogóle skonfigurowany pod SAML. Brak choćby jednego z trzech i logowanie zatrzyma się w innym miejscu.

Trzy warunki decydują, czy logowanie może się udać

Platforma jest pierwsza. AWS dostarcza własnego klienta Client VPN dla Windows, macOS i Ubuntu na AMD64, a pod koniec października 2026 roku strona wymagań Linuksa wymienia Ubuntu 22.04, 24.04 i 26.04. Przepakowana kompilacja, skonwertowany pakiet lub inna dystrybucja mogą działać, ale to nie jest wspierana platforma, a gdy się zepsuje, linią wsparcia jesteś Ty.

Klient jest drugi. Logowanie federacyjne nie jest opcją profilu, którą odczyta każda aplikacja zgodna z OpenVPN. Dostarczony klient otwiera dostawcę tożsamości w przeglądarce, odbiera podpisaną odpowiedź uwierzytelnienia i przekazuje ją do punktu końcowego. Aplikacja, która tylko czyta profil i podnosi tunel, nie wykonuje tego kroku, niezależnie od tego, jak czysty wygląda jej dziennik połączenia.

Punkt końcowy jest trzeci. Punkt końcowy z poświadczeniami Active Directory lub certyfikatami wzajemnymi ma zupełnie inny układ i zmiana klienta tego nie zmieni. Potwierdź tryb uwierzytelniania u tego, kto wydał profil, zanim zaczniesz debugować cokolwiek innego.

Wzięte razem, trzy warunki dają krótką tabelę decyzyjną:

Dlaczego import OpenVPN zatrzymuje się na auth-federate

Wyeksportowany profil AWS Client VPN zawiera dyrektywę, która mówi klientowi, że uwierzytelnianie odbywa się poza tunelem, przez federację. Zwykły klient OpenVPN albo od razu odrzuca tę linię, albo ją ignoruje i wtedy nie ma żadnych poświadczeń do zaproponowania. Tu kończy się większość prób na Androidzie: profil się importuje, aplikacja protestuje albo połączenie umiera z błędem konfiguracji, zanim choć jeden pakiet opuści urządzenie.

Usunięcie auth-federate to kuszący następny krok i zamienia jasną porażkę w mylącą. Usunięcie dyrektywy nie zamienia punktu końcowego SAML w uwierzytelnianie nazwą użytkownika i hasłem. Punkt końcowy nadal oczekuje podpisanej odpowiedzi SAML i odrzuca to, co klient wysyła zamiast niej. Hasło do konta, pobrany profil i skopiowana asercja nie są wymiennymi poświadczeniami.

Zalogowanie się do dostawcy tożsamości w Chrome na telefonie dowodzi tylko, że dostawca tożsamości zaakceptował użytkownika. Nie mówi nic o tym, czy odpowiedź dotrze do klienta, który może odesłać ją do punktu końcowego. wymagania dotyczące uwierzytelniania federacyjnego czynią dostarczonego klienta częścią przepływu właśnie z tego powodu: krok w przeglądarce jest konieczny i niewystarczający.

Jak wygląda wspierana ścieżka dla pulpitu Linuksa

Zainstaluj pakiet, który AWS publikuje dla Ubuntu AMD64, menedżerem pakietów systemu, a następnie otwórz połączenie z tego klienta, zamiast importować profil do uniwersalnej aplikacji VPN. Użyj profilu, który administrator wyeksportował dla tego punktu końcowego; nie podmieniaj adresu URL wywołania zwrotnego ani identyfikatora klienta ze starszego przewodnika, nawet jeśli klient go akceptuje.

Uruchom połączenie, dokończ logowanie i wszelkie żądanie MFA w otwartej przeglądarce i pozwól przepływowi powrotnemu z przeglądarki do klienta się zakończyć. Następnie poproś o adres prywatny, którego naprawdę potrzebujesz, od nowa. Strona ogłaszająca udane logowanie nie jest dowodem, że tunel się podniósł.

Klient Linuksa rezerwuje lokalne porty TCP od 8096 do 8115 dla odpowiedzi SAML. Gdy przekazanie wisi po tym, jak dostawca tożsamości Cię zaakceptował, sprawdź, co już nasłuchuje w tym zakresie:

ss -ltnp | grep -E ":809[6-9]|:81(0[0-9]|1[0-5])"

Zajęty port albo oprogramowanie zabezpieczające punktu końcowego, które blokuje nasłuch loopback, daje logowanie, które wygląda na zakończone, a potem nigdy się nie łączy. Trzymaj ten zakres lokalnie. To droga powrotna po stronie klienta, a nie coś, co otwiera się w grupie zabezpieczeń EC2 albo w regule zapory bramy, a otwarcie jej do internetu dodaje ekspozycję, niczego nie naprawiając.

Przeczytaj etap, który zawodzi, zanim cokolwiek zmienisz

Obwinianie klienta to odruch, ale każdy punkt porażki należy do innego właściciela. Najpierw ustal, gdzie naprawdę jesteś.

• Nie otwiera się żadne okno przeglądarki. Sprawdź tryb uwierzytelniania profilu, wybrane połączenie i integrację z domyślną przeglądarką pulpitu.
• Dostawca tożsamości odrzuca konto. Przydział konta, rejestracja MFA lub konfiguracja aplikacji SAML, wszystko to obszar administratora.
• Przeglądarka się kończy, ale klient nigdy się nie łączy. Wygasła lub bezużyteczna odpowiedź uwierzytelnienia, zablokowany port powrotny lub nieudane przekazanie.
• Tunel jest podniesiony, ale aplikacja jest nieosiągalna. Trasy punktu końcowego, reguły autoryzacji, grupy zabezpieczeń, DNS. Powtarzanie logowania w przeglądarce nie doda brakującego uprawnienia sieciowego.

Zachowaj tekst błędu klienta i czas próby, gdy eskalujesz. Twierdzenie, że SAML jest zepsuty, i twierdzenie, że klient nigdy nie otrzymał poprawnej odpowiedzi uwierzytelnienia, wysyłają ludzi w zupełnie różne miejsca.

Gdy wymaganie mimo to dotyczy Androida

Android nie jest platformą, dla której AWS publikuje swojego klienta, więc uczciwa odpowiedź brzmi: nie ma wspieranego klienta mobilnego do zainstalowania. To ograniczenie projektowe, a nie łamigłówka do rozwiązania na telefonie przez edycję profilu, aż coś się połączy.

Zmienić się może projekt dostępu pod tym, a ta decyzja należy do administratora: zatwierdzona ścieżka dostępu aplikacyjnego do jednej wewnętrznej usługi, której telefon potrzebuje, produkt VPN obsługujący urządzenia mobilne, który organizacja już prowadzi, albo wspierany pulpit dla punktu końcowego używającego tylko SAML. Każda opcja niesie własną konfigurację punktu końcowego, rejestrację tożsamości i reguły autoryzacji, a niczego z tego użytkownik nie stworzy z pobranego profilu.

Narzędzia firm trzecich, które twierdzą, że zamykają tę lukę, wymagają wyraźnego przeglądu wsparcia i bezpieczeństwa obejmującego MFA, obsługę odpowiedzi, politykę urządzeń i tempo aktualizacji. Ich istnienie nie czyni ich klientem Androida dostarczanym przez AWS i nie należy przenosić materiału uwierzytelniającego wielokrotnego użytku na telefon, aby któreś z nich zadziałało.

Daj administratorowi trzy fakty zamiast długiego wątku o dyrektywach: tryb uwierzytelniania punktu końcowego, zasób prywatny, do którego telefon musi dotrzeć, i termin. To wystarczy, by wybrać między pulpitem, ścieżką dostępu aplikacyjnego i nowym produktem VPN.

Sprawdź warunki po kolei, zanim otworzysz kolejne zgłoszenie: platforma na liście dostarczonych klientów, narzędzie, które potrafi dokończyć wymianę w przeglądarce, punkt końcowy naprawdę skonfigurowany pod federację i, w Linuksie, zakres portów loopback. Pierwszy element, który zawiedzie, jest tym do naprawy. Wszystko po nim to domysł.