SSTP op Linux misluk voor aanmelding? Kyk na die runtime-onderdele

Jy installeer die SSTP-inprop, die keuseknop verskyn in die netwerkredigeerder, jy vul 'n gateway en 'n gebruikersnaam in, en die profiel misluk met 'n generiese fout voordat dit ooit om 'n wagwoord vra. Niks aan daardie volgorde is ongewoon nie, en niks daarin bewys dat die tonnelprogrammatuur geïnstalleer is nie. 'n SSTP-verbinding word uit dele saamgestel wat afsonderlik verskeep word: 'n VPN-inprop wat NetworkManager kan begin, die SSTP-kliëntprogram wat die TLS- en PPP-sessie besit, die PPP-daemon daaronder, en 'n geheimestoor wat die verbinding mag lees.

Wat die kieslysinskrywing byvoeg, en wat nie

Die inprop lewer 'n diensbeskrywing wat vir NetworkManager sê hoe om dit te begin, en op die meeste distribusies 'n klein redigeerder wat die vorm teken. Dit is die hele omvang van die kieslysinskrywing. Die kliëntprogram kom uit 'n ander bronpakket, en die inprop se eie README sê die verdeling reguit: dit is 'n inprop, nie 'n kliënt nie.

Die kliënt het dan PPP nodig, want SSTP dra 'n PPP-sessie binne 'n TLS-verbinding. Sonder pppd kan die tonnel sy TLS-handdruk voltooi en steeds by die eerste beheerrame sterf, wat na 'n geloofsbrieweprobleem klink en nie een is nie. Op Debian en Ubuntu kom die dele as network-manager-sstp, sstp-client en ppp, en om net die eerste te installeer is die mees algemene rede waarom 'n vorm elke veld aanvaar terwyl die verbinding nooit klaarmaak nie.

Die lessenaarkeuse voeg nog 'n verdeling by. Plasma redigeer profiele deur plasma-nm, wat sy eie SSTP-komponent nodig het en dieselfde diensbeskrywing lees, so 'n redigeerder sonder 'n SSTP-inskrywing en 'n CLI wat profiele goed skep, is 'n ontbrekende redigeerderhelfte eerder as 'n stukkende runtime.

Lees die eerste mislukte stadium voordat jy enigiets herinstalleer

'n Mislukte SSTP-poging gaan deur stadiums in 'n vaste volgorde, en die stadium wat misluk het, sê vir jou na watter komponent jy moet kyk.

Die begin van die inprop is die eerste, en 'n mislukking daar lewer 'n boodskap oor die VPN-diens eerder as oor die bediener. 'n TCP-verbinding na poort 443 kom volgende; 'n weiering of tydsverloop hier is 'n bereikbaarheidsprobleem, nie 'n TLS-een nie. Dan die TLS-handdruk en die bedieneridentiteitskontrole, dan PPP-onderhandeling en rekeningverifikasie, en uiteindelik adrestoewysing en roetes. Kyk na journalctl -f -u NetworkManager terwyl jy die profiel een keer aktiveer, en lees die eerste spesifieke reël eerder as die laaste generiese een.

Daardie volgorde verklaar 'n algemene verkeerde lesing. 'n Sertifikaatklag word gerapporteer voordat enige geloofsbrief gestuur word, so om die wagwoord te verander kan nie help nie; 'n PPP-verifikasieverwerping kom ná 'n suksesvolle handdruk, so om die sertifikaat te vervang kan ook nie help nie. Hou die eerste fout en sy stadium, en jy het 'n diagnose eerder as 'n simptoom.

Sertifikaatvertroue en rekeningaanmelding is afsonderlike hekke

Die handdruk bevestig dat die bediener die een is wat jy wou bereik, met die uitreiker en naam wat jy opgestel het. Eers daarna bied die PPP-laag jou gebruikersnaam en wagwoord aan die gateway se verifikasiemetode. Twee onafhanklike kontroles dus, in 'n vaste volgorde geëvalueer, met afsonderlike instellings vir elk. Niks wat in die wagwoordveld getik word, kan die eerste een beïnvloed nie.

'n Profiel wat die verkeerde uitreiker vertrou, misluk by die eerste hek met 'n identiteitsfout. 'n Profiel wat dit korrek vertrou maar 'n verouderde wagwoord stoor, misluk by die tweede met 'n verifikasieverwerping. Albei lyk soos 'n VPN wat nie sal koppel nie, en nie een word deur die ander se oplossing reggemaak nie.

Kry die verwagte uitreiker en bedienernaam by wie die gateway bestuur eerder as om die redigeerder se verstekte te raai, en teken die verifikasiemetode aan wat hulle vereis. As die organisasie 'n metode nodig het wat die inprop nie kan uitdruk nie, is die eerlike antwoord 'n goedgekeurde kliënt wat dit kan, nie 'n profiel met validering afgeskakel om die fout te laat verdwyn nie.

Laat een eienaar die profiel en die geheime hou

Sodra die profiel bestaan, aktiveer dit deur NetworkManager en laat daardie bestuurder die gevolglike roetes en resolwerveranderinge besit. Om 'n tweede selfstandige SSTP-kliënt te begin terwyl NetworkManager reeds die verbinding bestuur, gee jou twee roetestelle, twee DNS-opstellings en 'n ontfoutingsessie sonder een enkele bron van waarheid.

Geheime het ook 'n eienaar. 'n Verbinding wat vir stelselwye gebruik gemerk is, stoor geloofsbriewe anders as een wat tot jou gebruikersessie beperk is, en 'n profiel wat met die hand in 'n sleutellêer geskep is, is dalk nie leesbaar deur die geheime-agent wat verwag om die wagwoord interaktief te verskaf nie. Kyk watter konteks die profiel verwag voordat jy 'n wagwoord hertik wat nooit die probleem was nie. Om dieselfde profiel met nmcli in 'n terminal te aktiveer, is die vinnigste toets, want 'n opdrag wat nooit verskyn nie, sê die agent het reeds niks gehad om te bied nie.

Verifieer die tonnel, die roetes en die resolwer afsonderlik

'n Gekoppelde aanduiding sê net dat die skakel opgekom het. Kontroleer die bestemming wat jy werklik nodig het, die roete wat dit dra, en die resolwer wat gebruik word, een op 'n keer; elkeen kan verkeerd wees terwyl die ander twee reg is.

Vir 'n mislukte poging, teken die weergawe van elke komponent en die gesuiwerde foutteks aan. Deel dit, nie die volledige profiel nie, want die profiel kan die voorafgedeelde geheim en jou gestoorde geloofsbriewe bevat.

Laastens, ontkoppel en koppel weer, en herbegin dan een keer. As die profiel net met die eerste poging werk, sit die probleem in geheimehantering of in roetebesit, en albei is nou goedkoper om reg te maak as in die middel van 'n werksdag.