SSTP në Linux dështon para hyrjes? Kontrolloni pjesët e ekzekutimit

Ju instaloni shtojcën SSTP, butoni i radios shfaqet në redaktorin e rrjetit, plotësoni një portë dhe një emër përdoruesi, dhe profili dështon me një gabim të përgjithshëm para se të kërkojë ndonjë fjalëkalim. Asgjë në këtë sekuencë nuk është e pazakontë, dhe asgjë në të nuk provon se softueri i tunelit është instaluar. Një lidhje SSTP montohet nga pjesë që dërgohen veçmas: një shtojcë VPN që NetworkManager mund të nisë, programi klient SSTP që zotëron sesionin TLS dhe PPP, daemoni PPP nën të, dhe një depo sekretesh që lidhjes i lejohet të lexojë.

Çfarë shton zëri i menusë dhe çfarë jo

Shtojca kontribuon me një përshkrim shërbimi që i thotë NetworkManager si ta nisë, dhe në shumicën e shpërndarjeve një redaktor të vogël që vizaton formularin. Ky është i gjithë shtrirja e zërit të menusë. Programi klient vjen nga një paketë tjetër burimore, dhe README i vetë shtojcës e thotë ndarjen drejtpërdrejt: është shtojcë, jo klient.

Klienti pastaj ka nevojë për PPP, sepse SSTP transporton një sesion PPP brenda një lidhjeje TLS. Pa pppd tuneli mund të përfundojë shtrëngimin e duarve TLS dhe prapë të vdesë në kornizën e parë të kontrollit, që duket si problem kredencialesh dhe nuk është. Në Debian dhe Ubuntu pjesët vijnë si network-manager-sstp, sstp-client dhe ppp, dhe instalimi vetëm i së parës është arsyeja më e zakonshme që një formular pranon çdo fushë ndërsa lidhja nuk përfundon kurrë.

Zgjedhja e desktopit shton një ndarje tjetër. Plasma i redakton profilet përmes plasma-nm, i cili ka nevojë për komponentin e vet SSTP dhe lexon të njëjtin përshkrim shërbimi, kështu që një redaktor pa zë SSTP dhe një CLI që krijon profile mirë është gjysma e redaktorit që mungon, jo një mjedis ekzekutimi i prishur.

Lexoni fazën e parë që dështon para se të riinstaloni gjithçka

Një përpjekje e dështuar SSTP kalon nëpër faza në një rend fiks, dhe faza që dështoi ju tregon se cilin komponent të shikoni.

Nisja e shtojcës është e para, dhe një dështim atje prodhon një mesazh për shërbimin VPN, jo për serverin. Më pas vjen një lidhje TCP në portën 443; një refuzim ose skadim kohe këtu është problem arritshmërie, jo TLS. Pastaj shtrëngimi i duarve TLS dhe verifikimi i identitetit të serverit, pastaj negociimi PPP dhe vërtetimi i llogarisë, dhe në fund caktimi i adresave dhe rrugët. Vëzhgoni journalctl -f -u NetworkManager ndërsa aktivizoni profilin një herë, dhe lexoni rreshtin e parë specifik në vend të atij të fundit të përgjithshëm.

Ky rend shpjegon një lexim të gabuar të zakonshëm. Një ankesë për certifikatën raportohet para se të dërgohet çdo kredencial, kështu që ndryshimi i fjalëkalimit nuk mund të ndihmojë; një refuzim vërtetimi PPP vjen pas një shtrëngimi të suksesshëm duarsh, kështu që zëvendësimi i certifikatës gjithashtu nuk ndihmon. Mbani gabimin e parë dhe fazën e tij, dhe keni një diagnozë, jo një simptomë.

Besimi te certifikata dhe hyrja në llogari janë dy porta të ndara

Shtrëngimi i duarve vërteton se serveri është ai që kishit ndërmend të arrinit, duke përdorur lëshuesin dhe emrin që konfiguruat. Vetëm pas kësaj shtresa PPP ofron emrin tuaj të përdoruesit dhe fjalëkalimin metodës së vërtetimit të portës. Dy kontrolle të pavarura, pra, vlerësohen në një rend fiks, me cilësime të veçanta për secilin. Asgjë e shtypur në fushën e fjalëkalimit nuk mund të ndikojë në të parin.

Një profil që i beson lëshuesit të gabuar dështon në portën e parë me një gabim identiteti. Një profil që i beson saktë por ruan një fjalëkalim të vjetër dështon në të dytën me një refuzim vërtetimi. Të dy duken si një VPN që nuk do të lidhet, dhe asnjëri nuk rregullohet nga ilaçi i tjetrit.

Merrni lëshuesin dhe emrin e serverit të pritur nga ai që administron portën në vend që të hamendësoni parazgjedhjet e redaktorit, dhe shënoni metodën e vërtetimit që kërkojnë. Nëse organizata ka nevojë për një metodë që shtojca nuk mund ta shprehë, përgjigjja e ndershme është një klient i miratuar që mundet, jo një profil me verifikimin e fikur për ta bërë gabimin të zhduket.

Lëreni një pronar të vetëm të mbajë profilin dhe sekretet

Pasi profili ekziston, aktivizojeni përmes NetworkManager dhe lëreni atë menaxher të zotërojë rrugët dhe ndryshimet e rezoluesit që vijnë. Nisja e një klienti të dytë të pavarur SSTP ndërsa NetworkManager tashmë drejton lidhjen ju jep dy grupe rrugësh, dy konfigurime DNS dhe një sesion korrigjimi pa një burim të vetëm të vërtetë.

Edhe sekretet kanë pronar. Një lidhje e shënuar për përdorim në të gjithë sistemin ruan kredencialet ndryshe nga një e kufizuar në sesionin tuaj të përdoruesit, dhe një profil i krijuar me dorë në një skedar çelësi mund të mos jetë i lexueshëm nga agjenti i sekreteve që pret të japë fjalëkalimin në mënyrë interaktive. Kontrolloni çfarë konteksti pret profili përpara se të rishtypni një fjalëkalim që nuk ishte kurrë problemi. Aktivizimi i të njëjtit profil nga një terminal me nmcli është testi më i shpejtë, sepse një kërkesë që nuk shfaqet kurrë ju thotë se agjenti nuk kishte më asgjë për të ofruar.

Kontrolloni tunelin, rrugët dhe rezoluesin veçmas

Një tregues i lidhur pretendon vetëm se lidhja u ngrit. Kontrolloni destinacionin që ju nevojitet vërtet, rrugën që e mbart dhe rezoluesin në përdorim, një nga një; secili mund të jetë i gabuar ndërsa dy të tjerët janë në rregull.

Për një përpjekje të dështuar, regjistroni versionin e secilit komponent dhe tekstin e pastruar të gabimit. Ndani ata, jo profilin e plotë, sepse profili mund të përmbajë sekretin e para-ndarë dhe kredencialet tuaja të ruajtura.

Së fundi, shkëputuni dhe rilidheni, pastaj rinisni një herë. Nëse profili funksionon vetëm në provën e parë, problemi qëndron në trajtimin e sekreteve ose në pronësinë e rrugëve, dhe të dyja janë më të lira të rregullohen tani sesa në mes të një dite pune.