SSTP Linux sistemoje nepavyksta prieš prisijungimą? Patikrinkite vykdymo dalis

Įdiegiate SSTP papildinį, tinklo redaktoriuje atsiranda radijo mygtukas, įvedate tinklų sietuvą ir naudotojo vardą, o profilis nepavyksta su bendra klaida dar prieš paklausdamas slaptažodžio. Šioje sekoje nėra nieko neįprasto, ir joje niekas neįrodo, kad tunelio programinė įranga įdiegta. SSTP ryšys surenkamas iš dalių, kurios tiekiamos atskirai: VPN papildinys, kurį NetworkManager gali paleisti, SSTP kliento programa, kuri valdo TLS ir PPP sesiją, PPP demonas po ja ir paslapčių saugykla, kurią ryšiui leidžiama skaityti.

Ką prideda meniu elementas, o ko ne

Papildinys pateikia paslaugos aprašą, kuris pasako NetworkManager, kaip jį paleisti, ir daugumoje distribucijų nedidelį redaktorių, kuris piešia formą. Tai yra visas meniu elemento mastas. Kliento programa gaunama iš kito šaltinio paketo, o papildinio README tiesiogiai sako šį atskyrimą: tai papildinys, ne klientas.

Tada klientui reikia PPP, nes SSTP perduoda PPP sesiją TLS ryšio viduje. Be pppd tunelis gali užbaigti TLS rankos paspaudimą ir vis tiek mirti pirmame valdymo kadre, o tai atrodo kaip prisijungimo duomenų problema ir nėra. Debian ir Ubuntu dalys ateina kaip network-manager-sstp, sstp-client ir ppp, o įdiegus tik pirmąją dažniausia priežastis, kodėl forma priima kiekvieną lauką, bet ryšys niekada nebaigiamas.

Darbalaukio pasirinkimas prideda dar vieną atskyrimą. Plasma redaguoja profilius per plasma-nm, kuriam reikia savo SSTP komponento ir kuris skaito tą patį paslaugos aprašą, todėl redaktorius be SSTP elemento ir CLI, kuris gerai kuria profilius, yra trūkstama redaktoriaus pusė, o ne sugedusi vykdymo aplinka.

Perskaitykite pirmą nepavykusį etapą prieš ką nors perinstaliuodami

Nepavykęs SSTP bandymas praeina etapus fiksuota tvarka, o nepavykęs etapas pasako, į kurį komponentą žiūrėti.

Papildinio paleidimas yra pirmas, ir nesėkmė ten pateikia pranešimą apie VPN paslaugą, o ne apie serverį. Toliau ateina TCP ryšys į 443 prievadą; atmetimas arba laiko limitas čia yra pasiekiamumo problema, ne TLS. Tada TLS rankos paspaudimas ir serverio tapatybės patikra, po to PPP derybos ir paskyros autentifikavimas, ir galiausiai adresų priskyrimas bei maršrutai. Stebėkite journalctl -f -u NetworkManager, kai vieną kartą aktyvuojate profilį, ir skaitykite pirmą konkrečią eilutę, o ne paskutinę bendrą.

Ši tvarka paaiškina dažną klaidingą skaitymą. Skundas dėl sertifikato pateikiamas prieš siunčiant bet kokius prisijungimo duomenis, todėl slaptažodžio keitimas negali padėti; PPP autentifikavimo atmetimas ateina po sėkmingo rankos paspaudimo, todėl sertifikato keitimas taip pat nepadeda. Laikykite pirmą klaidą ir jos etapą, ir turėsite diagnozę, o ne simptomą.

Sertifikato pasitikėjimas ir prisijungimas prie paskyros yra atskiri vartai

Rankos paspaudimas patikrina, kad serveris yra tas, kurį norėjote pasiekti, naudodamas jūsų sukonfigūruotą išdavėją ir vardą. Tik po to PPP sluoksnis pasiūlo jūsų naudotojo vardą ir slaptažodį tinklų sietuvo autentifikavimo metodui. Taigi du nepriklausomi patikrinimai, vertinami fiksuota tvarka, su atskirais nustatymais kiekvienam. Niekas, įrašytas slaptažodžio lauke, negali paveikti pirmojo.

Profilis, kuris pasitiki netinkamu išdavėju, nepavyksta pirmuose vartuose su tapatybės klaida. Profilis, kuris juo pasitiki teisingai, bet saugo pasenusį slaptažodį, nepavyksta antruose su autentifikavimo atmetimu. Abu atrodo kaip VPN, kuri neprisijungs, ir nė vieno nepataiso kitos priemonė.

Gaukite laukiamą išdavėją ir serverio vardą iš to, kas valdo tinklų sietuvą, o ne spėliokite redaktoriaus numatytąsias reikšmes, ir užsirašykite jų reikalaujamą autentifikavimo metodą. Jei organizacijai reikia metodo, kurio papildinys negali išreikšti, sąžiningas atsakymas yra patvirtintas klientas, kuris gali, o ne profilis su išjungtu tikrinimu, kad klaida dingtų.

Tegul vienas savininkas laiko profilį ir paslaptis

Kai profilis egzistuoja, aktyvuokite jį per NetworkManager ir leiskite tam valdytojui valdyti gautus maršrutus ir rezolverio pakeitimus. Paleidus antrą savarankišką SSTP klientą, kai NetworkManager jau valdo ryšį, gaunate du maršrutų rinkinius, dvi DNS konfigūracijas ir derinimo sesiją be vieno tiesos šaltinio.

Paslaptys taip pat turi savininką. Ryšys, pažymėtas sisteminiam naudojimui, saugo prisijungimo duomenis kitaip nei ribotas jūsų naudotojo sesijai, o rankiniu būdu raktų faile sukurtas profilis gali būti neperskaitomas paslapčių agentui, kuris tikisi slaptažodį pateikti interaktyviai. Patikrinkite, kokio konteksto tikisi profilis, prieš iš naujo įvesdami slaptažodį, kuris niekada nebuvo problema. To paties profilio aktyvavimas terminale su nmcli yra greičiausias testas, nes raginimas, kuris niekada nepasirodo, pasako, kad agentas jau neturėjo ką pasiūlyti.

Atskirai patikrinkite tunelį, maršrutus ir rezolverį

Prisijungta indikatorius tik teigia, kad jungtis pakilo. Patikrinkite tikslą, kurio iš tikrųjų reikia, jį nešantį maršrutą ir naudojamą rezolverį, po vieną; kiekvienas gali būti neteisingas, kol kiti du tvarkingi.

Nepavykus bandymui, užrašykite kiekvieno komponento versiją ir išvalytą klaidos tekstą. Bendrinkite juos, o ne visą profilį, nes profilyje gali būti iš anksto bendrinama paslaptis ir jūsų saugomi prisijungimo duomenys.

Galiausiai atjunkite ir vėl prisijunkite, tada kartą paleiskite iš naujo. Jei profilis veikia tik pirmu bandymu, problema yra paslapčių tvarkyme arba maršrutų nuosavybėje, ir abi pigiau sutvarkyti dabar nei darbo dienos viduryje.