Az SSTP Linuxon bejelentkezés előtt elbukik? Ellenőrizze a futásidejű elemeket

Telepíti az SSTP bővítményt, a választógomb megjelenik a hálózati szerkesztőben, kitölt egy átjárót és egy felhasználónevet, és a profil általános hibával elbukik, mielőtt egyáltalán jelszót kérne. Ebben a sorrendben semmi sem szokatlan, és semmi sem bizonyítja, hogy az alagút szoftvere telepítve van. Az SSTP-kapcsolat külön szállított részekből áll össze: egy VPN-bővítmény, amelyet a NetworkManager el tud indítani, az SSTP kliensprogram, amely a TLS- és PPP-munkamenetet birtokolja, az alatta lévő PPP-démon, és egy titoktár, amelyet a kapcsolat olvashat.

Mit ad hozzá a menüpont, és mit nem

A bővítmény egy szolgáltatásleírást ad hozzá, amely megmondja a NetworkManagernek, hogyan indítsa el, és a legtöbb disztribúción egy kis szerkesztőt, amely az űrlapot rajzolja. Ez a menüpont teljes hatóköre. A kliensprogram másik forráscsomagból származik, és a bővítmény saját README-je egyenesen kimondja a szétválasztást: ez bővítmény, nem kliens.

A kliensnek ezután PPP-re van szüksége, mert az SSTP PPP-munkamenetet visz egy TLS-kapcsolaton belül. pppd nélkül az alagút befejezheti a TLS-kézfogást, és mégis meghalhat az első vezérlőkeretnél, ami hitelesítési adatok problémájának látszik, de nem az. Debianon és Ubuntu-n a részek network-manager-sstp, sstp-client és ppp néven érkeznek, és csak az első telepítése a leggyakoribb oka annak, hogy az űrlap minden mezőt elfogad, de a kapcsolat soha nem fejeződik be.

Az asztali választás még egy hasadást ad hozzá. A Plasma a plasma-nm-en keresztül szerkeszti a profilokat, amelynek saját SSTP-összetevőre van szüksége, és ugyanazt a szolgáltatásleírást olvassa, tehát az SSTP-bejegyzés nélküli szerkesztő és a profilokat jól létrehozó CLI egy hiányzó szerkesztőfél, nem törött futásidejű környezet.

Olvassa el az első sikertelen szakaszt, mielőtt bármit újratelepítene

A sikertelen SSTP-kísérlet rögzített sorrendben halad át a szakaszokon, és a sikertelen szakasz megmondja, melyik összetevőt nézze.

A bővítmény elindítása az első, és az ottani hiba a VPN-szolgáltatásról szóló üzenetet ad, nem a szerverről. Ezután jön a TCP-kapcsolat a 443-as portra; az elutasítás vagy időtúllépés itt elérhetőségi probléma, nem TLS-probléma. Aztán a TLS-kézfogás és a szerver identitásának ellenőrzése, majd a PPP-tárgyalás és a fiók hitelesítése, végül a címkiosztás és az útvonalak. Figyelje a journalctl -f -u NetworkManager-et, miközben egyszer aktiválja a profilt, és az első konkrét sort olvassa, ne az utolsó általánosat.

Ez a sorrend magyarázza a gyakori félreolvasást. A tanúsítványpanaszt még azelőtt jelentik, hogy bármilyen hitelesítő adat elküldésre kerülne, tehát a jelszó módosítása nem segíthet; a PPP-hitelesítés elutasítása sikeres kézfogás után érkezik, tehát a tanúsítvány cseréje sem segít. Tartsa meg az első hibát és annak szakaszát, és diagnózisa lesz, nem tünete.

A tanúsítványba vetett bizalom és a fiókba való bejelentkezés külön kapuk

A kézfogás ellenőrzi, hogy a szerver az, amelyet el akart érni, a beállított kibocsátó és név alapján. Csak ezután kínálja a PPP-réteg a felhasználónevét és jelszavát az átjáró hitelesítési módszerének. Két független ellenőrzés tehát, rögzített sorrendben kiértékelve, külön beállításokkal mindegyikhez. Semmi, amit a jelszómezőbe írnak, nem befolyásolhatja az elsőt.

A rossz kibocsátóban bízó profil az első kapunál identitáshibával bukik el. A benne helyesen bízó, de elavult jelszót tároló profil a másodiknál hitelesítési elutasítással bukik el. Mindkettő úgy néz ki, mint egy VPN, amely nem fog csatlakozni, és egyiket sem javítja a másik gyógymódja.

A várt kibocsátót és szervernevet attól kérje, aki az átjárót üzemelteti, ne találgassa a szerkesztő alapértékeit, és jegyezze fel az általuk megkövetelt hitelesítési módszert. Ha a szervezetnek olyan módszerre van szüksége, amelyet a bővítmény nem tud kifejezni, az őszinte válasz egy jóváhagyott kliens, amely tud, nem pedig egy profil kikapcsolt ellenőrzéssel, hogy a hiba eltűnjön.

Egy tulajdonos tartsa a profilt és a titkokat

Amint a profil létezik, aktiválja a NetworkManageren keresztül, és hagyja, hogy az a kezelő birtokolja a keletkező útvonalakat és feloldóváltozásokat. Ha második önálló SSTP-klienst indít, miközben a NetworkManager már viszi a kapcsolatot, két útvonalkészletet, két DNS-konfigurációt és egyetlen igazságforrás nélküli hibakeresési munkamenetet kap.

A titkoknak is van tulajdonosa. A rendszerszintű használatra megjelölt kapcsolat másképp tárolja a hitelesítő adatokat, mint a felhasználói munkamenetére korlátozott, és egy kézzel, kulcsfájlban létrehozott profil lehet, hogy nem olvasható a titokügynök számára, amely a jelszót interaktívan kívánja megadni. Ellenőrizze, milyen kontextust vár a profil, mielőtt újra beírna egy jelszót, amely soha nem volt a probléma. Ugyanazon profil terminálból, nmcli-vel való aktiválása a leggyorsabb teszt, mert egy soha meg nem jelenő kérés azt mondja, hogy az ügynöknek már nem volt mit kínálnia.

Ellenőrizze külön az alagutat, az útvonalakat és a feloldót

A csatlakoztatva jelző csak azt állítja, hogy a kapcsolat feljött. Ellenőrizze a ténylegesen szükséges célt, az azt vivő útvonalat és a használt feloldót, egyenként; mindegyik lehet hibás, miközben a másik kettő rendben van.

Sikertelen kísérlet esetén rögzítse az egyes összetevők verzióját és a megtisztított hibaüzenetet. Ezeket ossza meg, ne a teljes profilt, mert a profil tartalmazhatja az előre megosztott titkot és a tárolt hitelesítő adatait.

Végül bontsa a kapcsolatot, csatlakozzon újra, majd indítsa újra egyszer. Ha a profil csak első próbálkozásra működik, a probléma a titkok kezelésében vagy az útvonalak tulajdonjogában van, és mindkettőt most olcsóbb javítani, mint egy munkanap közepén.