Logowanie OpenConnect trafia na niewłaściwą stronę? Najpierw sprawdź ścieżkę

Wklejasz adres z wiadomości powitalnej, klient dociera do bramy, a wyświetlany formularz logowania to portal ogólny, a nie partnerski, który opisał operator. Nic nie zgłasza błędu i właśnie to myli: tunel może nawet wstać, tylko za niewłaściwym punktem wejścia. Ścieżka w tym adresie wykonywała pracę, a cokolwiek ją zastąpiło, tę pracę zgubiło.

Rozdziel dwie rzeczy, które w zgłoszeniu przychodzą jako jeden ciąg: adres, który dociera do usługi, oraz dane wejściowe, które decydują, gdzie zaczyna się uwierzytelnianie. Naprawienie pierwszego przy ignorowaniu drugiego to sposób, w jaki poprawna nazwa hosta wciąż daje błędne logowanie.

Co klient wysyła, zanim zobaczysz formularz

Z adresem takim jak https://vpn.example.net/partners pierwszym działaniem klienta jest żądanie HTTPS do tej ścieżki, a nie do nagiego hosta. W odpowiedzi zwykle przychodzi przekierowanie do punktu logowania albo sam formularz. Klient, który dostaje tylko vpn.example.net, zaczyna od domyślnej strony docelowej, jaka jest, a to może być inny portal, inna lista grup albo strona oczekująca zupełnie innego protokołu. Różnica jest widoczna w nagłówkach odpowiedzi długo przed wpisaniem jakichkolwiek danych uwierzytelniających.

Dlatego działająca karta przeglądarki i niedziałający profil klienta mogą wskazywać tę samą bramę i nadal się nie zgadzać. Przeglądarka podążyła ścieżką; profil nigdy jej nie miał.

Dwa wejścia, które wyglądają na wymienne i nie są

OpenConnect udostępnia początkową ścieżkę HTTPS jako --usergroup, a strona podręcznika traktuje pełny URL z tą ścieżką jako to samo żądanie zapisane inaczej. --authgroup to osobna opcja: wybiera wpis z listy, którą brama prezentuje wewnątrz formularza logowania. Niektóre protokoły nazywają ten wpis grupą, inne domeną lub bramą, i właśnie tam oba przełączniki się mylą.

Usługa może zgodnie z prawem potrzebować obu. Ścieżka może zaprowadzić cię na właściwy portal, podczas gdy formularz wciąż prosi o wybór grupy w jego wnętrzu. Podanie nazwy portalu jako nazwy grupy, albo odwrotnie, daje logowanie, które wygląda na zaakceptowane, a potem nie autoryzuje, bo wartość była składniowo poprawna, a znaczeniowo błędna.

Poproś operatora o każdą wartość w osobnym wierszu: ścieżkę wejścia, wybór w formularzu i to, czy oba są potrzebne. Nie wyprowadzaj jednego z drugiego tylko dlatego, że etykiety brzmią podobnie.

Dlaczego skrócenie ścieżki zmienia wynik

Klienci, którzy akceptują tylko host i port, często i tak się łączą, więc objaw rzadko jest twardym błędem. Zamiast tego dostajesz niewłaściwą stronę logowania, pustą listę grup, nazwę certyfikatu, która nie pasuje już do opublikowanej przez operatora, albo tunel, który wstaje bez trasy do usługi, której chciałeś. Każdy z tych przypadków siedzi w innej warstwie i żadnego nie naprawia wklejenie dłuższego ciągu w pole udokumentowane jako nazwa hosta. Dwa z nich są też nieodróżnialne z zewnątrz, bo oba przychodzą jako formularz logowania, który po prostu nie idzie dalej.

Zastąpienie nazwy hosta adresem IP to osobny błąd, który często podróżuje razem z tym. Wybór usługi oparty na nazwie i walidacja certyfikatu zależą oba od nazwy, więc adres numeryczny może zamienić problem formatu ścieżki w błąd TLS.

Adresy w przeglądarce niosą też więcej niż ścieżki. Identyfikatory sesji, cele przekierowań, prefiksy językowe i tymczasowe parametry logowania pojawiają się wszystkie w pasku adresu, i żaden z nich nie należy do zapisanego profilu klienta.

Potwierdź punkt wejścia, zanim zmienisz cokolwiek innego

Przeczytaj nagłówki dla ścieżki, którą otrzymałeś. Żądanie takie jak curl -sS -o /dev/null -D - https://vpn.example.net/partners wypisuje wiersz statusu i każdy nagłówek Location bez podążania za przekierowaniem. 302 wskazujący nazwany punkt logowania potwierdza, że ścieżka istnieje, i pokazuje, dokąd prowadzi; 404 oznacza, że adres operatora jest nieaktualny.

Następnie odtwórz ten sam punkt wejścia w zatwierdzonym kliencie, na przykład openconnect --usergroup=partners vpn.example.net, i zobacz, który formularz się pojawia. Jeśli formularz jest poprawny, a tunel nadal zawodzi, ścieżka nigdy nie była problemem, a następnym przystankiem jest polityka lub routing.

Zapisz nazwę hosta, port, protokół, ścieżkę wejścia i wybór w formularzu jako pięć osobnych pól w zgłoszeniu. Ta lista pozwala następnemu inżynierowi odróżnić nieosiągalny serwer od odmowy TLS, odrzuconego wyboru i tunelu, który wstał bez potrzebnych tras.