SSTP v Linuxu selhává před přihlášením? Zkontrolujte běhové části
Editor na ploše kreslí jen formulář. Tunel SSTP potřebuje také klienta protokolu, vrstvu PPP a vlastníka tajemství a každý z nich selhává jinak.
Nainstalujete doplněk SSTP, v editoru sítě se objeví přepínač, vyplníte bránu a uživatelské jméno a profil selže s obecnou chybou, než se vůbec zeptá na heslo. Na této posloupnosti není nic neobvyklého a nic v ní nedokazuje, že je software tunelu nainstalovaný. Spojení SSTP se skládá z částí, které se dodávají odděleně: doplněk VPN, který NetworkManager umí spustit, klientský program SSTP, který vlastní relaci TLS a PPP, démon PPP pod ním a úložiště tajemství, které smí spojení číst.
Co položka nabídky přidává a co ne
Doplněk přispívá popisem služby, který říká NetworkManageru, jak ji spustit, a na většině distribucí malým editorem, který kreslí formulář. To je celý rozsah položky menu. Klientský program pochází z jiného zdrojového balíčku a vlastní README doplňku to říká přímo: je to doplněk, ne klient.
Klient pak potřebuje PPP, protože SSTP přenáší relaci PPP uvnitř spojení TLS. Bez pppd může tunel dokončit handshake TLS a přesto zemřít na prvním řídicím rámci, což vypadá jako problém s přihlašovacími údaji a není. Na Debianu a Ubuntu přicházejí části jako network-manager-sstp, sstp-client a ppp a instalace jen první z nich je nejčastějším důvodem, proč formulář přijme všechna pole, ale spojení nikdy nedokončí.
Volba plochy přidává další rozdělení. Plasma upravuje profily přes plasma-nm, který potřebuje vlastní komponentu SSTP a čte stejný popis služby, takže editor bez položky SSTP a CLI, které profily vytváří bez problémů, znamená chybějící polovinu editoru, ne rozbité běhové prostředí.
Přečtěte si první neúspěšnou fázi, než cokoli přeinstalujete
Neúspěšný pokus o SSTP prochází fázemi v pevném pořadí a fáze, která selhala, vám řekne, na kterou komponentu se dívat.
První je spuštění doplňku a selhání tam dává zprávu o službě VPN, ne o serveru. Následuje TCP spojení na port 443; odmítnutí nebo časový limit je zde problém dosažitelnosti, ne TLS. Pak handshake TLS a kontrola identity serveru, potom vyjednávání PPP a ověření účtu a nakonec přidělení adresy a trasy. Sledujte journalctl -f -u NetworkManager, když profil jednou aktivujete, a čtěte první konkrétní řádek, ne poslední obecný.
Toto pořadí vysvětluje časté chybné čtení. Stížnost na certifikát se hlásí dřív, než se odešlou jakékoli přihlašovací údaje, takže změna hesla nepomůže; odmítnutí ověření PPP přichází po úspěšném handshaku, takže výměna certifikátu také nepomůže. Podržte první chybu a její fázi a máte diagnózu, ne symptom.
Důvěra v certifikát a přihlášení k účtu jsou oddělené brány
Handshake ověřuje, že server je ten, kterého jste chtěli dosáhnout, pomocí vydavatele a jména, které jste nastavili. Teprve potom vrstva PPP nabídne vaše uživatelské jméno a heslo metodě ověření brány. Dvě nezávislé kontroly tedy, vyhodnocované v pevném pořadí, s odděleným nastavením pro každou. Nic napsané do pole hesla nemůže ovlivnit tu první.
Profil, který důvěřuje špatnému vydavateli, selže na první bráně s chybou identity. Profil, který mu důvěřuje správně, ale ukládá zastaralé heslo, selže na druhé s odmítnutím ověření. Oba vypadají jako VPN, která se nepřipojí, a ani jeden se neopraví lékem toho druhého.
Získejte očekávaného vydavatele a jméno serveru od toho, kdo bránu provozuje, místo hádání výchozích hodnot editoru, a poznamenejte si požadovanou metodu ověření. Pokud organizace potřebuje metodu, kterou doplněk neumí vyjádřit, poctivá odpověď je schválený klient, který to umí, ne profil s vypnutým ověřováním, aby chyba zmizela.
Ať jeden vlastník drží profil i tajemství
Jakmile profil existuje, aktivujte jej přes NetworkManager a nechte toho správce vlastnit výsledné trasy a změny resolveru. Spuštění druhého samostatného klienta SSTP, když NetworkManager už spojení vede, vám dá dvě sady tras, dvě konfigurace DNS a ladění bez jediného zdroje pravdy.
Tajemství mají také vlastníka. Spojení označené pro systémové použití ukládá přihlašovací údaje jinak než spojení omezené na vaši uživatelskou relaci a profil vytvořený ručně v souboru klíčů nemusí být čitelný pro agenta tajemství, který očekává interaktivní dodání hesla. Zkontrolujte, jaký kontext profil očekává, než znovu napíšete heslo, které nikdy nebylo problémem. Aktivace stejného profilu z terminálu pomocí nmcli je nejrychlejší test, protože výzva, která se nikdy neobjeví, vám řekne, že agent už neměl co nabídnout.
Ověřte tunel, trasy a resolver odděleně
Indikátor připojení tvrdí jen to, že se link zvedl. Zkontrolujte cílové umístění, které skutečně potřebujete, trasu, která ho nese, a používaný resolver, jedno po druhém; každé může být špatně, zatímco ostatní dvě jsou v pořádku.
U neúspěšného pokusu zaznamenejte verzi každé komponenty a očištěný text chyby. Sdílejte je, ne celý profil, protože profil může obsahovat předem sdílené tajemství a vaše uložené přihlašovací údaje.
Nakonec se odpojte a znovu připojte, pak jednou restartujte. Pokud profil funguje jen na první pokus, problém je v zacházení s tajemstvími nebo ve vlastnictví tras, a obojí se teď opravuje levněji než uprostřed pracovního dne.