SSTP v Linuxu ne uspe pred prijavo? Preverite izvajalne dele

Namestite vtičnik SSTP, v urejevalniku omrežja se pojavi izbirni gumb, vnesete prehod in uporabniško ime, profil pa ne uspe s splošno napako, še preden zahteva geslo. Nič v tem zaporedju ni nenavadnega in nič v njem ne dokazuje, da je programska oprema tunela nameščena. Povezava SSTP je sestavljena iz delov, ki se dobavljajo ločeno: vtičnik VPN, ki ga NetworkManager lahko zažene, odjemalski program SSTP, ki ima sejo TLS in PPP, demonski proces PPP pod njim in shramba skrivnosti, ki jo povezava sme brati.

Kaj doda element menija in kaj ne

Vtičnik prispeva opis storitve, ki pove NetworkManageru, kako ga zagnati, in v večini distribucij majhen urejevalnik, ki riše obrazec. To je celoten obseg elementa menija. Odjemalski program prihaja iz drugega izvornega paketa, in README vtičnika sam pove to ločitev neposredno: to je vtičnik, ne odjemalec.

Odjemalec nato potrebuje PPP, ker SSTP prenaša sejo PPP znotraj povezave TLS. Brez pppd lahko tunel dokonča rokovanje TLS in vseeno umre na prvem krmilnem okvirju, kar je videti kot težava s poverilnicami in ni. V Debianu in Ubuntuju deli pridejo kot network-manager-sstp, sstp-client in ppp, namestitev samo prvega pa je najpogostejši razlog, da obrazec sprejme vsako polje, povezava pa se nikoli ne konča.

Izbira namizja doda še eno ločitev. Plasma ureja profile prek plasma-nm, ki potrebuje lastno komponento SSTP in bere isti opis storitve, zato sta urejevalnik brez elementa SSTP in CLI, ki dobro ustvarja profile, manjkajoča polovica urejevalnika, ne pokvarjeno izvajalno okolje.

Preberite prvo neuspešno fazo, preden karkoli znova namestite

Neuspešen poskus SSTP gre skozi faze v določenem vrstnem redu, in faza, ki ni uspela, vam pove, katero komponento pogledati.

Zagon vtičnika je prvi, in napaka tam da sporočilo o storitvi VPN, ne o strežniku. Nato pride povezava TCP na vrata 443; zavrnitev ali potek časa je tu težava dosegljivosti, ne TLS. Potem rokovanje TLS in preverjanje identitete strežnika, zatem pogajanja PPP in preverjanje računa, na koncu dodelitev naslovov in poti. Opazujte journalctl -f -u NetworkManager, ko enkrat aktivirate profil, in berite prvo konkretno vrstico, ne zadnje splošne.

Ta vrstni red pojasnjuje pogosto napačno branje. Pritožba glede potrdila se sporoči, preden se pošljejo kakršne koli poverilnice, zato sprememba gesla ne more pomagati; zavrnitev preverjanja PPP pride po uspešnem rokovanju, zato tudi zamenjava potrdila ne pomaga. Obdržite prvo napako in njeno fazo, in imate diagnozo, ne simptom.

Zaupanje v potrdilo in prijava v račun sta ločeni vrati

Rokovanje potrdi, da je strežnik tisti, ki ste ga želeli doseči, z izdajateljem in imenom, ki ste ju nastavili. Šele nato plast PPP ponudi vaše uporabniško ime in geslo metodi preverjanja prehoda. Dve neodvisni preverjanji torej, ocenjeni v določenem vrstnem redu, z ločenimi nastavitvami za vsako. Nič, kar vnesete v polje za geslo, ne more vplivati na prvo.

Profil, ki zaupa napačnemu izdajatelju, ne uspe na prvih vratih z napako identitete. Profil, ki mu zaupa pravilno, a hrani zastarelo geslo, ne uspe na drugih z zavrnitvijo preverjanja. Oba sta videti kot VPN, ki se ne bo povezal, in nobenega ne odpravi zdravilo drugega.

Pridobite pričakovanega izdajatelja in ime strežnika od tistega, ki upravlja prehod, namesto da ugibate privzete vrednosti urejevalnika, in zapišite zahtevano metodo preverjanja. Če organizacija potrebuje metodo, ki je vtičnik ne more izraziti, je pošten odgovor odobren odjemalec, ki jo lahko, ne profil z izklopljenim preverjanjem, da napaka izgine.

Naj en lastnik drži profil in skrivnosti

Ko profil obstaja, ga aktivirajte prek NetworkManager in pustite temu upravitelju, da ima nastale poti in spremembe razreševalnika. Zagon drugega samostojnega odjemalca SSTP, medtem ko NetworkManager že vodi povezavo, vam da dva niza poti, dve konfiguraciji DNS in sejo odpravljanja napak brez enega samega vira resnice.

Tudi skrivnosti imajo lastnika. Povezava, označena za sistemsko uporabo, shranjuje poverilnice drugače kot tista, omejena na vašo uporabniško sejo, in profil, ustvarjen ročno v datoteki s ključi, morda ne bo berljiv agentu za skrivnosti, ki pričakuje, da bo geslo zagotovil interaktivno. Preverite, kakšen kontekst profil pričakuje, preden znova vnesete geslo, ki nikoli ni bilo težava. Aktiviranje istega profila iz terminala z nmcli je najhitrejši test, ker poziv, ki se nikoli ne pojavi, vam pove, da agent ni imel več ničesar ponuditi.

Preverite tunel, poti in razreševalnik ločeno

Indikator povezanosti trdi le, da se je povezava dvignila. Preverite cilj, ki ga zares potrebujete, pot, ki ga nosi, in uporabljeni razreševalnik, eno za drugim; vsak je lahko napačen, medtem ko sta druga dva v redu.

Pri neuspešnem poskusu zabeležite različico vsake komponente in očiščeno besedilo napake. Delite jih, ne celotnega profila, ker lahko profil vsebuje vnaprej skupno skrivnost in vaše shranjene poverilnice.

Nazadnje se odklopite in znova povežite ter enkrat znova zaženite. Če profil deluje samo ob prvem poskusu, je težava v ravnanju s skrivnostmi ali v lastništvu poti, in oboje je zdaj ceneje popraviti kot sredi delovnega dne.