SSTP Linuxis ebaõnnestub enne sisselogimist? Kontrollige käituskomponente
Töölaua redaktor joonistab ainult vormi. SSTP-tunnel vajab ka protokolliklienti, PPP-kihti ja saladuste omanikku ning igaüks neist ebaõnnestub erinevalt.
Paigaldate SSTP pistikprogrammi, võrguredaktorisse ilmub raadionupp, sisestate lüüsi ja kasutajanime ning profiil ebaõnnestub üldise veaga enne, kui see üldse parooli küsib. Selles järjestuses pole midagi ebatavalist ja miski selles ei tõesta, et tunneli tarkvara on paigaldatud. SSTP-ühendus pannakse kokku osadest, mida tarnitakse eraldi: VPN-i pistikprogramm, mille NetworkManager saab käivitada, SSTP kliendiprogramm, mis omab TLS-i ja PPP sessiooni, selle all olev PPP deemon ja saladuste hoidla, mida ühendusel on lubatud lugeda.
Mida menüükirje lisab ja mida mitte
Pistikprogramm annab teenusekirjelduse, mis ütleb NetworkManagerile, kuidas seda käivitada, ja enamikus distributsioonides väikese redaktori, mis vormi joonistab. See on menüükirje kogu ulatus. Kliendiprogramm pärineb teisest lähtepaketist ja pistikprogrammi enda README ütleb selle jaotuse otse: see on pistikprogramm, mitte klient.
Seejärel vajab klient PPP-d, sest SSTP kannab PPP sessiooni TLS-ühenduse sees. Ilma pppd võib tunnel TLS-i kätlemise lõpetada ja ikkagi esimesel juhtkaadril surra, mis näib volituste probleemina, aga ei ole seda. Debianis ja Ubuntus tulevad osad nimega network-manager-sstp, sstp-client ja ppp ning ainult esimese paigaldamine on kõige tavalisem põhjus, miks vorm võtab vastu iga välja, kuid ühendus ei lõpe kunagi.
Töölaua valik lisab veel ühe jaotuse. Plasma redigeerib profiile plasma-nm kaudu, mis vajab oma SSTP komponenti ja loeb sama teenusekirjeldust, seega redaktor ilma SSTP kirjeta ja CLI, mis profiile hästi loob, on puuduv pool redaktorist, mitte katkine käituskeskkond.
Lugege esimest ebaõnnestuvat etappi enne, kui midagi uuesti paigaldate
Ebaõnnestunud SSTP katse läbib etapid kindlas järjekorras ja ebaõnnestunud etapp ütleb, millist komponenti vaadata.
Pistikprogrammi käivitamine on esimene ja sealne tõrge annab sõnumi VPN teenuse, mitte serveri kohta. Järgmisena tuleb TCP-ühendus pordile 443; keeldumine või aegumine on siin kättesaadavuse, mitte TLS-i probleem. Seejärel TLS-i kätlemine ja serveri identiteedi kontroll, siis PPP läbirääkimised ja konto autentimine ning lõpuks aadressi määramine ja marsruudid. Jälgige journalctl -f -u NetworkManager, kui profiili korra aktiveerite, ja lugege esimest konkreetset rida, mitte viimast üldist.
See järjekord selgitab levinud vale lugemist. Sertifikaadi kaebus esitatakse enne, kui ühtegi volitust saadetakse, seega parooli muutmine ei saa aidata; PPP autentimise keeldumine saabub pärast edukat kätlemist, seega ka sertifikaadi vahetamine ei aita. Jätke esimene viga ja selle etapp alles ning teil on diagnoos, mitte sümptom.
Sertifikaadi usaldus ja kontole sisselogimine on eraldi väravad
Kätlemine kontrollib, et server on see, kuhu tegelikult jõuda tahtsite, kasutades teie seadistatud väljastajat ja nime. Alles seejärel pakub PPP kiht teie kasutajanime ja parooli lüüsi autentimismeetodile. Kaks sõltumatut kontrolli, mis hinnatakse kindlas järjekorras ja millel on eraldi seaded. Miski paroolivälja kirjutatu ei saa esimest mõjutada.
Profiil, mis usaldab valet väljastajat, ebaõnnestub esimesel väraval identiteediveaga. Profiil, mis usaldab seda õigesti, kuid hoiab vananenud parooli, ebaõnnestub teisel väraval autentimise keeldumisega. Mõlemad näivad VPN-ina, mis ei ühendu, ja kumbagi ei paranda teise rohi.
Hankige oodatav väljastaja ja serveri nimi sellelt, kes lüüsi haldab, mitte arvake redaktori vaikeväärtusi, ja kirjutage üles nende nõutav autentimismeetod. Kui organisatsioon vajab meetodit, mida pistikprogramm ei suuda väljendada, on aus vastus heakskiidetud klient, mis suudab, mitte profiil, millel on valideerimine välja lülitatud, et viga kaoks.
Laske ühel omanikul hoida profiili ja saladusi
Kui profiil on olemas, aktiveerige see NetworkManageri kaudu ja laske sellel halduril omada tulemuseks olevaid marsruute ja resolveri muudatusi. Teise eraldiseisva SSTP kliendi käivitamine, kui NetworkManager juba ühendust juhib, annab kaks marsruudikomplekti, kaks DNS-i seadistust ja silumissessiooni ilma ühegi tõeallikata.
Ka saladustel on omanik. Süsteemseks kasutuseks märgitud ühendus hoiab volitusi teisiti kui teie kasutajasessiooniga piiratud ühendus, ja käsitsi võtmefaili loodud profiil ei pruugi olla loetav saladusagendile, mis loodab parooli interaktiivselt anda. Kontrollige, millist konteksti profiil eeldab, enne kui sisestate uuesti parooli, mis ei olnud kunagi probleem. Sama profiili aktiveerimine terminalist nmcli abil on kiireim test, sest viip, mis kunagi ei ilmu, ütleb, et agendil polnud juba midagi pakkuda.
Kontrollige tunnelit, marsruute ja resolverit eraldi
Ühendatud indikaator väidab ainult, et link tõusis. Kontrollige sihtkohta, mida tegelikult vajate, seda kandvat marsruuti ja kasutatavat resolverit ükshaaval; igaüks võib olla vale, samal ajal kui teised kaks on korras.
Ebaõnnestunud katse puhul salvestage iga komponendi versioon ja puhastatud veatekst. Jagage neid, mitte kogu profiili, sest profiil võib sisaldada eeljagatud saladust ja teie salvestatud volitusi.
Lõpuks katkestage ühendus ja looge see uuesti, seejärel taaskäivitage korra. Kui profiil töötab ainult esimesel katsel, on probleem saladuste käsitlemises või marsruutide omandis, ja mõlemat on odavam parandada praegu kui keset tööpäeva.