Dlaczego logowanie openfortivpn zawodzi po wklejeniu adresu URL portalu

Błąd wygląda jak problem z poświadczeniami: openfortivpn pyta o hasło, wysyła je, a brama odpowiada odrzuceniem lub przekierowaniem z powrotem na stronę logowania. Użytkownicy wpisują wtedy hasło ponownie, próbują nazwy konta z domeną i w końcu wklejają adres URL portalu z przeglądarki do pola hosta. Właśnie ten ostatni krok zamienia drobny błąd konfiguracji w mylący.

Adres portalu Fortinet, taki jak https://vpn.example.com/ext, niesie kilka informacji naraz, i tylko niektóre z nich należą do klienta VPN.

Punkt końcowy i realm to osobne dane wejściowe

openfortivpn oczekuje punktu końcowego w postaci host lub host:port, a także konta i, jeśli wdrożenie go używa, wartości realm. Realm mówi bramie, jaką politykę uwierzytelniania zastosować przed oceną konta. To osobne pole, a nie przyrostek, który klient wyciąga z adresu URL.

Dla wdrożenia, którego operator potwierdza, że realm to ext, wywołanie bez tajemnic wygląda tak: openfortivpn vpn.example.com:443 --username=alice --realm=ext. Te same wartości trafiają do pliku konfiguracyjnego jako wpisy host, port, username i realm. Zostaw hasło poza obiema formami i pozwól klientowi o nie zapytać, aby nie trafiło do historii powłoki ani do pliku czytelnego dla wszystkich. Druga próba, gdy pierwszy klient wciąż trzyma tunel, zakończy się niepowodzeniem z powodu, który nie ma nic wspólnego z realm.

podręcznik openfortivpn wymienia obie opcje, więc dokładną pisownię łatwo potwierdzić przed telefonem do pomocy technicznej. Nie powie ci jednak, jaki realm jest skonfigurowany na twojej bramie.

Segment ścieżki nie jest automatycznie realm

Adresy URL portalu zbierają po nazwie hosta różne rzeczy: aplikację logowania, wybór języka, cel przekierowania, identyfikator sesji. Odcięcie ostatniego segmentu ścieżki i nazwanie go realm działa wystarczająco często, by było niebezpieczne. Zapytaj operatora o skonfigurowaną wartość albo odczytaj ją z profilu, który rozprowadza twoja organizacja.

Realm to także nie to samo co przyrostek domeny w nazwie użytkownika ani region, w którym znajduje się brama. Niektóre wdrożenia chcą alice, inne chcą alice@corp, a realm decyduje, który z nich brama zaakceptuje. Zmiana formatu konta w celu zrekompensowania błędnego realm zwykle daje drugie, mniej informacyjne odrzucenie.

Nie naprawiaj błędu realm, zmieniając hosta

Zastąpienie nazwy hosta adresem IP wygląda jak usunięcie warstwy, a psuje więcej, niż naprawia. Walidacja nazwy w TLS porównuje certyfikat z nazwą używaną przez klienta, a adres IP rzadko pojawia się w alternatywnych nazwach podmiotu certyfikatu. Wskaźnik nazwy serwera zmienia się wraz z adresem, więc brama hostująca kilka portali pod jednym adresem może odpowiedzieć niewłaściwym. Zachowaj nazwę hosta i konfigurację zaufania bez zmian, poprawiając parametr uwierzytelniania.

Jeśli certyfikat nie jest zaufany w twoim środowisku, napraw magazyn zaufania lub świadomie przypnij oczekiwany certyfikat. Wyłączenie weryfikacji, by ominąć błąd realm, wymienia problem z logowaniem na ryzyko cichego przechwycenia.

Oddziel odrzucone logowanie od nieudanego tunelu

Błędy uwierzytelniania i błędy tunelu pojawiają się w różnych momentach, a komunikaty się różnią. Błąd rozwiązywania nazwy występuje przed jakimkolwiek uściskiem dłoni TLS. Odrzucenie TLS występuje przed wysłaniem poświadczeń. Odrzucenie realm lub konta wraca jako odpowiedź na poziomie HTTP z portalu. Dopiero po tych etapach zaczyna się negocjacja PPP i dopiero wtedy pojawiają się problemy z routingiem i DNS.

Poprawny realm nie tworzy brakującej trasy i nie sprawia, że nieobsługiwana metoda logowania zaczyna działać. Jeśli portal nalega na przepływ oparty na przeglądarce, użyj obsługiwanej przez klienta ścieżki dla tego przepływu, zamiast powtarzać wymianę hasła i liczyć, że sesja się zgodzi.

Przechowuj wartości tam, gdzie znajdzie je następne uruchomienie

Gdy połączenie się powiedzie, zapisz bramę, port, konto i realm w zarządzanym profilu, a nie w aliasie powłoki. Profile przechowywane w repozytorium lub systemie zarządzania konfiguracją nie pozwalają następnemu uruchomieniu po cichu przejąć realm innego profilu.

Przetestuj ponownie jedno połączenie od początku do końca i potwierdź zarówno zastosowaną politykę, jak i dostęp do zasobu, którego naprawdę potrzebujesz. Powodzenie uwierzytelniania to początek tego sprawdzenia, a nie jego koniec.