SSTP w Linuksie zawodzi przed logowaniem? Sprawdź elementy środowiska

Instalujesz wtyczkę SSTP, przycisk opcji pojawia się w edytorze sieci, wpisujesz bramę i nazwę użytkownika, a profil zawodzi z ogólnym błędem, zanim jeszcze poprosi o hasło. Nic w tej sekwencji nie jest niezwykłe i nic w niej nie dowodzi, że oprogramowanie tunelu jest zainstalowane. Połączenie SSTP składa się z części dostarczanych osobno: wtyczki VPN, którą NetworkManager może uruchomić, programu klienta SSTP, który posiada sesję TLS i PPP, demona PPP pod nim oraz magazynu sekretów, który połączenie może czytać.

Co dodaje pozycja menu, a czego nie

Wtyczka dostarcza opis usługi, który mówi NetworkManagerowi, jak ją uruchomić, a w większości dystrybucji mały edytor, który rysuje formularz. To cały zakres pozycji menu. Program klienta pochodzi z innego pakietu źródłowego, a README samej wtyczki mówi o tym podziale wprost: to wtyczka, nie klient.

Klient potrzebuje następnie PPP, ponieważ SSTP przenosi sesję PPP wewnątrz połączenia TLS. Bez pppd tunel może ukończyć uzgadnianie TLS i mimo to umrzeć na pierwszej ramce kontrolnej, co wygląda jak problem z danymi logowania i nim nie jest. W Debianie i Ubuntu części przychodzą jako network-manager-sstp, sstp-client i ppp, a zainstalowanie tylko pierwszej to najczęstsza przyczyna, że formularz przyjmuje każde pole, ale połączenie nigdy się nie kończy.

Wybór pulpitu dodaje jeszcze jeden podział. Plasma edytuje profile przez plasma-nm, który potrzebuje własnego komponentu SSTP i czyta ten sam opis usługi, więc edytor bez pozycji SSTP i CLI, które dobrze tworzy profile, to brakująca połowa edytora, a nie zepsute środowisko uruchomieniowe.

Przeczytaj pierwszy nieudany etap, zanim cokolwiek przeinstalujesz

Nieudana próba SSTP przechodzi przez etapy w ustalonej kolejności, a etap, który zawiódł, mówi, na który komponent patrzeć.

Uruchomienie wtyczki jest pierwsze, a błąd tam daje komunikat o usłudze VPN, nie o serwerze. Następnie pojawia się połączenie TCP do portu 443; odmowa lub przekroczenie czasu jest tu problemem osiągalności, nie TLS. Potem uzgadnianie TLS i sprawdzenie tożsamości serwera, następnie negocjacja PPP i uwierzytelnianie konta, a na końcu przydział adresów i trasy. Obserwuj journalctl -f -u NetworkManager, gdy raz aktywujesz profil, i czytaj pierwszy konkretny wiersz, a nie ostatni ogólny.

Ta kolejność wyjaśnia częste błędne odczytanie. Skarga na certyfikat jest zgłaszana, zanim zostaną wysłane jakiekolwiek dane logowania, więc zmiana hasła nie może pomóc; odrzucenie uwierzytelnienia PPP przychodzi po udanym uzgadnianiu, więc wymiana certyfikatu też nie pomoże. Zachowaj pierwszy błąd i jego etap, a masz diagnozę, a nie objaw.

Zaufanie do certyfikatu i logowanie na konto to dwie osobne bramy

Uzgadnianie sprawdza, że serwer jest tym, do którego chciałeś dotrzeć, na podstawie skonfigurowanego wystawcy i nazwy. Dopiero potem warstwa PPP oferuje nazwę użytkownika i hasło metodzie uwierzytelniania bramy. Dwie niezależne kontrole, więc, oceniane w ustalonej kolejności, z osobnymi ustawieniami dla każdej. Nic wpisane w pole hasła nie może wpłynąć na pierwszą.

Profil, który ufa niewłaściwemu wystawcy, zawodzi przy pierwszej bramie z błędem tożsamości. Profil, który ufa mu poprawnie, ale przechowuje nieaktualne hasło, zawodzi przy drugiej z odrzuceniem uwierzytelnienia. Oba wyglądają jak VPN, która się nie połączy, i żadnego nie naprawia lekarstwo drugiego.

Uzyskaj oczekiwanego wystawcę i nazwę serwera od osoby zarządzającej bramą, zamiast zgadywać domyślne wartości edytora, i zapisz wymaganą metodę uwierzytelniania. Jeśli organizacja potrzebuje metody, której wtyczka nie umie wyrazić, uczciwą odpowiedzią jest zatwierdzony klient, który potrafi, a nie profil z wyłączoną weryfikacją, żeby błąd zniknął.

Niech jeden właściciel trzyma profil i sekrety

Gdy profil istnieje, aktywuj go przez NetworkManager i pozwól temu menedżerowi posiadać wynikowe trasy i zmiany resolvera. Uruchomienie drugiego samodzielnego klienta SSTP, gdy NetworkManager już prowadzi połączenie, daje dwa zestawy tras, dwie konfiguracje DNS i sesję debugowania bez jednego źródła prawdy.

Sekrety też mają właściciela. Połączenie oznaczone do użytku systemowego przechowuje dane logowania inaczej niż ograniczone do sesji użytkownika, a profil utworzony ręcznie w pliku klucza może być nieczytelny dla agenta sekretów, który oczekuje interaktywnego podania hasła. Sprawdź, jakiego kontekstu oczekuje profil, zanim ponownie wpiszesz hasło, które nigdy nie było problemem. Aktywacja tego samego profilu z terminala przez nmcli to najszybszy test, bo monit, który nigdy się nie pojawia, mówi, że agent nie miał już nic do zaoferowania.

Sprawdź tunel, trasy i resolver osobno

Wskaźnik połączenia stwierdza tylko, że łącze wstało. Sprawdź cel, którego naprawdę potrzebujesz, trasę, która go niesie, i używany resolver, jedno po drugim; każde może być błędne, gdy pozostałe dwa są w porządku.

W przypadku nieudanej próby zapisz wersję każdego komponentu i oczyszczony tekst błędu. Udostępniaj je, a nie cały profil, ponieważ profil może zawierać wstępnie współdzielony sekret i zapisane dane logowania.

Na koniec rozłącz się i połącz ponownie, a następnie raz uruchom ponownie. Jeśli profil działa tylko przy pierwszej próbie, problem tkwi w obsłudze sekretów lub we własności tras, a oba są tańsze do naprawy teraz niż w środku dnia pracy.