SSTP Linux-en saio-hasieraren aurretik huts egiten du? Egiaztatu exekuzio-piezak

SSTP plugina instalatzen duzu, aukera-botoia sare-editorean agertzen da, ataka eta erabiltzaile-izena betetzen dituzu, eta profileak huts egiten du errore generiko batekin, pasahitza eskatu aurretik. Sekuentzia horretan ez dago ezer ezohikorik, eta ez dago ezer tunelaren softwarea instalatuta dagoela frogatzen duenik. SSTP konexioa bereiz bidaltzen diren zatietatik muntatzen da: NetworkManager-ek abian jar dezakeen VPN plugina, TLS eta PPP saioa duen SSTP bezeroaren programa, haren azpiko PPP deabrua, eta konexioari irakurtzeko baimena duen sekretuen biltegia.

Zer gehitzen duen menu-sarrerak, eta zer ez

Pluginak zerbitzu-deskribapen bat gehitzen du, NetworkManager-i nola abiarazi esaten diona, eta banaketa gehienetan formularioa marrazten duen editore txiki bat. Hori da menu-sarreraren esparru osoa. Bezeroaren programa beste iturburu-pakete batetik dator, eta pluginaren README-ak berak zuzenean esaten du banaketa: plugina da, ez bezeroa.

Orduan bezeroak PPP behar du, SSTP-k TLS konexio baten barruan PPP saioa garraiatzen duelako. pppd gabe tunelak TLS esku-ematea amaitu dezake eta oraindik lehen kontrol-markoan hil, kredentzialen arazoa dirudiena eta ez dena. Debian eta Ubuntu-n zatiak network-manager-sstp, sstp-client eta ppp gisa iristen dira, eta lehenengoa bakarrik instalatzea da formularioak eremu guztiak onartzen dituen baina konexioa inoiz amaitzen ez den arrazoi ohikoena.

Mahaigainaren aukerak beste banaketa bat gehitzen du. Plasma-k profileak plasma-nm bidez editatzen ditu, zeinak bere SSTP osagaia behar duen eta zerbitzu-deskribapen bera irakurtzen duen, beraz SSTP sarrerarik gabeko editore bat eta profileak ongi sortzen dituen CLI bat editorearen erdia falta dela da, ez exekuzio-ingurune hondatua.

Irakurri huts egiten duen lehen etapa, ezer berrinstalatu aurretik

SSTP saiakera huts batek etapa jakin batean zehar egiten du ordena finkoan, eta huts egin zuen etapek zein osagairi begiratu esaten dizu.

Plugina abiaraztea da lehena, eta han huts eginez gero VPN zerbitzuari buruzko mezua ematen da, ez zerbitzariari buruzkoa. Ondoren 443 atakako TCP konexioa dator; hemen ukapena edo denbora-muga irisgarritasun arazoa da, ez TLSarena. Gero TLS esku-ematea eta zerbitzariaren identitatearen egiaztapena, gero PPP negoziazioa eta kontuaren autentifikazioa, eta azkenik helbide-esleipena eta ibilbideak. Egiaztatu journalctl -f -u NetworkManager profila behin aktibatzen duzun bitartean, eta irakurri lehen lerro zehatza, azken lerro orokorraren ordez.

Ordena horrek ohiko irakurketa okerra argitzen du. Ziurtagiri-kexa bat kredentzialik bidali aurretik jakinarazten da, beraz pasahitza aldatzeak ezin du lagundu; PPP autentifikazio-ukapena esku-emate arrakastatsu baten ondoren iristen da, beraz ziurtagiria ordezkatzeak ere ezin du lagundu. Gorde lehen errorea eta haren etapa, eta diagnostiko bat izango duzu, sintoma bat beharrean.

Ziurtagiriarekiko konfiantza eta kontuaren saio-hasiera ate bereiziak dira

Esku-emateak egiaztatzen du zerbitzaria iristeko asmoa zenuena dela, konfiguratu zenituen jaulkitzailea eta izena erabiliz. Horren ondoren bakarrik eskaintzen dio PPP geruzak zure erabiltzaile-izena eta pasahitza atakaren autentifikazio-metodoari. Bi egiaztapen independente, beraz, ordena finkoan ebaluatuak, bakoitzak bere ezarpenak dituela. Pasahitz-eremuan idatzitako ezerk ezin du lehenengoa eragin.

Jaulkitzaile okerrean konfiantza duen profileak lehen atakan huts egiten du identitate-errore batekin. Harekin ongi konfiantza duen baina pasahitz zaharkitua gordetzen duen profileak bigarrenean huts egiten du autentifikazio-ukapen batekin. Biak konektatuko ez den VPN baten itxura dute, eta bat ere ez da bestearen erremedioarekin konpontzen.

Eskatu espero den jaulkitzailea eta zerbitzari-izena ataka kudeatzen duenari, editorearen balio lehenetsiak asmatu beharrean, eta idatzi behar duten autentifikazio-metodoa. Erakundeak pluginak adierazi ezin duen metodoa behar badu, erantzun zintzoa baietz egin dezakeen bezero onartua da, ez balidazioa itzalita duen profil bat errorea desagerrarazteko.

Utzi jabe bakarrari profila eta sekretuak edukitzen

Profila sortu ondoren, aktibatu NetworkManager bidez eta utzi kudeatzaile horri sortutako ibilbideen eta ebazlearen aldaketen jabe izaten. NetworkManager-ek dagoeneko konexioa daramala bigarren SSTP bezero autonomo bat abiarazteak bi ibilbide-multzo, bi DNS konfigurazio eta inolako egiaren iturri bakarreko arazketa-saio bat ematen dizkizu.

Sekretuek ere jabea dute. Sistema osoan erabiltzeko markatutako konexioak kredentzialak bestela gordetzen ditu zure erabiltzaile-saiora mugatutakoak baino, eta gako-fitxategi batean eskuz sortutako profila pasahitza interaktiboki ematea espero duen sekretu-agenteak irakur ez dezake. Egiaztatu profileak zein testuinguru espero duen, inoiz arazoa izan ez zen pasahitz bat berridatzi aurretik. Profil bera terminaletik nmcli-rekin aktibatzea da proba azkarrena, inoiz agertzen ez den eskaera batek agenteak jada ezer ez zuela esaten baitizu.

Egiaztatu tunela, ibilbideak eta ebazlea bereiz

Konektatuta adierazleak esteka altxatu dela dio soilik. Egiaztatu benetan behar duzun helmuga, hura daraman ibilbidea eta erabiltzen ari den ebazlea, bat-batean; bakoitza oker egon daiteke beste biak ongi dauden bitartean.

Saiakera huts baterako, erregistratu osagai bakoitzaren bertsioa eta garbitutako errore-testua. Partekatu horiek, ez profila osoa, profilak aldez aurretik partekatutako sekretua eta gordetako kredentzialak izan baititzake.

Azkenik, deskonektatu eta berriro konektatu, eta gero berrabiarazi behin. Profilak lehen saiakeran bakarrik funtzionatzen badu, arazoa sekretuen kudeaketan edo ibilbideen jabegoan dago, eta biak orain konpontzea lanegun erdian baino merkeagoa da.