SSTP op Linux mislearret foar oanmelding? Kontrolearje de runtime-ûnderdielen

Jo ynstallearje de SSTP-ynstekker, it radio-knop ferskynt yn 'e netwurk-editor, jo folje in gateway en in brûkersnamme yn, en it profyl mislearret mei in algemiene flater foardat it ea om in wachtwurd freget. Neat oan dy folchoarder is ûngewoan, en neat deryn bewiist dat de tunnelsoftware ynstallearre is. In SSTP-ferbining wurdt gearstald út ûnderdielen dy't apart levere wurde: in VPN-ynstekker dy't NetworkManager starte kin, it SSTP-klientprogramma dat de TLS- en PPP-sesje hat, de PPP-daemon dêrûnder, en in geheimopslach dy't de ferbining lêze mei.

Wat it menú-item tafoeget, en wat net

De ynstekker leveret in tsjinstbeskriuwing dy't NetworkManager fertelt hoe't er it starte moat, en op de measte distribúsjes in lytse editor dy't it formulier tekenet. Dat is de hiele omfang fan it menú-item. It klientprogramma komt út in oar boarnepakket, en de eigen README fan 'e ynstekker seit de splitsing rjochtút: it is in ynstekker, gjin klient.

De klient hat dan PPP nedich, om't SSTP in PPP-sesje yn in TLS-ferbining ferfiert. Sûnder pppd kin de tunnel syn TLS-hânjaan foltôgje en dochs by it earste kontrôleframe stjerre, wat as in probleem mei oanmeldgegevens liket en dat net is. Op Debian en Ubuntu komme de ûnderdielen as network-manager-sstp, sstp-client en ppp, en allinnich it earste ynstallearje is de meast foarkommende reden dat in formulier elk fjild akseptearret wylst de ferbining nea klearkomt.

De kar fan buroblêd foeget noch in splitsing ta. Plasma bewurket profylen fia plasma-nm, dat syn eigen SSTP-ûnderdiel nedich hat en deselde tsjinstbeskriuwing lêst, dus in editor sûnder SSTP-ynstap en in CLI dy't profylen wol makket, is in ûntbrekkende helte fan 'e editor, net in stikken runtime.

Lês de earste mislearjende faze foardat jo wat dan ek opnij ynstallearje

In mislearre SSTP-poging giet troch fazen yn in fêste oarder, en de faze dy't mislearre hat fertelt jo hokker ûnderdiel jo besjen moatte.

It starten fan 'e ynstekker is de earste, en in flater dêr jout in berjocht oer de VPN-tsjinst yn stee fan oer de server. Dêrnei komt in TCP-ferbining nei poarte 443; in wegering of time-out hjir is in berikberensprobleem, gjin TLS-probleem. Dan de TLS-hânjaan en de kontrôle fan serveridentiteit, dan PPP-ûnderhanneling en accountautentikaasje, en as lêste adrestawizing en rûtes. Hâld journalctl -f -u NetworkManager yn 'e gaten wylst jo it profyl ien kear aktivearje, en lês de earste spesifike rigel yn stee fan 'e lêste algemiene.

Dy oarder ferklearret in faak foarkommende ferkearde lêzing. In sertifikaatklacht wurdt melde foardat der ea oanmeldgegevens stjoerd wurde, dus it wachtwurd feroarje kin net helpe; in PPP-autentikaasjeôfwizing komt nei in slagge hânjaan, dus it sertifikaat ferfange kin ek net helpe. Hâld de earste flater en syn faze, en jo hawwe in diagnoaze yn stee fan in symptoom.

Fertrouwen yn it sertifikaat en oanmelding by it akkount binne aparte poarten

De hânjaan kontrolearret dat de server dy is dy't jo berikke woene, mei de útjouwer en namme dy't jo konfigurearre hawwe. Pas dêrnei biedt de PPP-laach jo brûkersnamme en wachtwurd oan 'e autentikaasjemetoade fan 'e gateway. Twa ûnôfhinklike kontrôles dus, beoardiele yn in fêste oarder, mei aparte ynstellings foar elk. Neat dat yn it wachtwurdfjild typt wurdt kin de earste beynfloedzje.

In profyl dat de ferkearde útjouwer fertrout, mislearret by de earste poarte mei in identiteitsflater. In profyl dat him korrekt fertrout mar in ferâldere wachtwurd bewarret, mislearret by de twadde mei in autentikaasjeôfwizing. Beide lykje op in VPN dy't net ferbine sil, en gjinien wurdt makke troch it middel fan 'e oare.

Krij de ferwachte útjouwer en servernamme fan wa't de gateway beheart yn stee fan de standertwearden fan 'e editor te rieden, en skriuw de autentikaasjemetoade op dy't se easkje. As de organisaasje in metoade nedich hat dy't de ynstekker net útdrukke kin, is it earlike antwurd in goedkarde klient dy't dat wol kin, net in profyl mei falidearring útskeakele om de flater ferdwine te litten.

Lit ien eigner it profyl en de geheimmen hâlde

As it profyl bestiet, aktivearje it fia NetworkManager en lit dy behearder de resultearjende rûtes en resolverferoarings besitte. In twadde selsstannige SSTP-klient starte wylst NetworkManager de ferbining al rint, jout jo twa rûtesets, twa DNS-konfiguraasjes en in debugsesje sûnder ien boarne fan wierheid.

Geheimmen hawwe ek in eigner. In ferbining dy't foar systeembreed gebrûk markearre is, bewarret oanmeldgegevens oars as ien dy't beheind is ta jo brûkerssesje, en in profyl dat mei de hân yn in kaai-bestân makke is, is miskien net lêsber foar de geheimagent dy't ferwachtet it wachtwurd ynteraktyf te leverjen. Kontrolearje hokker kontekst it profyl ferwachtet foardat jo in wachtwurd opnij type dat nea it probleem wie. It aktivearjen fan itselde profyl fanôf in terminal mei nmcli is de fluchste test, want in oanfrege dat nea ferskynt fertelt jo dat de agint al neat te bieden hie.

Kontrolearje de tunnel, de rûtes en de resolver apart

In oanfallen-oantsjutting beweart allinnich dat de ferbining omheech kaam. Kontrolearje it doel dat jo echt nedich hawwe, de rûte dy't it draacht, en de resolver dy't brûkt wurdt, ien foar ien; elk kin ferkeard wêze wylst de oare twa goed binne.

Foar in mislearre poging, fêstlizze de ferzje fan elk ûnderdiel en de suvere flatertekst. Diel dy, net it folsleine profyl, om't it profyl it foarôf dielde geheim en jo bewarre oanmeldgegevens befetsje kin.

Ta slot, ferbrek en ferbyn op 'e nij, en start dan ien kear op 'e nij. As it profyl allinnich by de earste poging wurket, sit it probleem yn 'e omgong mei geheimmen of yn it eignerskip fan rûtes, en beide binne no goedkeaper te reparearjen as midden yn in wurkdei.