SSTP kwenye Linux inashindikana kabla ya kuingia? Angalia sehemu za utekelezaji

Unasakinisha programu-jalizi ya SSTP, kitufe cha redio kinaonekana kwenye kihariri cha mtandao, unajaza lango na jina la mtumiaji, na wasifu unashindikana kwa hitilafu ya jumla kabla hata ya kuuliza nenosiri. Hakuna kitu cha ajabu katika mfuatano huo, na hakuna kitu ndani yake kinachothibitisha kuwa programu ya handaki imesakinishwa. Muunganisho wa SSTP unakusanywa kutoka sehemu zinazosafirishwa tofauti: programu-jalizi ya VPN ambayo NetworkManager inaweza kuizindua, programu mteja ya SSTP inayomiliki kikao cha TLS na PPP, daemon ya PPP chini yake, na hifadhi ya siri ambayo muunganisho unaruhusiwa kuisoma.

Kipengee cha menyu kinaongeza nini na hakiongezi nini

Programu-jalizi inatoa maelezo ya huduma yanayomwambia NetworkManager jinsi ya kuizindua, na katika usambazaji mwingi kihariri kidogo kinachochora fomu. Huo ndio upeo wote wa kipengee cha menyu. Programu mteja inatoka kwenye kifurushi kingine cha chanzo, na README ya programu-jalizi yenyewe inasema mgawanyiko huo moja kwa moja: ni programu-jalizi, si mteja.

Kisha mteja anahitaji PPP, kwa sababu SSTP hubeba kikao cha PPP ndani ya muunganisho wa TLS. Bila pppd handaki inaweza kukamilisha mshikamano wa mikono wa TLS na bado kufa kwenye fremu ya kwanza ya udhibiti, jambo ambalo linaonekana kama tatizo la vitambulisho na si hivyo. Kwenye Debian na Ubuntu sehemu zinakuja kama network-manager-sstp, sstp-client na ppp, na kusakinisha ya kwanza pekee ndio sababu ya kawaida zaidi ya fomu kukubali kila sehemu huku muunganisho usikamilike kamwe.

Uchaguzi wa eneo-kazi unaongeza mgawanyiko mmoja zaidi. Plasma huhariri wasifu kupitia plasma-nm, ambayo inahitaji sehemu yake ya SSTP na kusoma maelezo yale yale ya huduma, kwa hiyo kihariri kisicho na kipengee cha SSTP na CLI inayounda wasifu vizuri ni nusu ya kihariri iliyokosekana, si mazingira ya utekelezaji yaliyovunjika.

Kabla ya kusakinisha upya chochote, soma hatua ya kwanza inayoshindikana

Jaribio la SSTP lililoshindikana hupitia hatua kwa mpangilio maalum, na hatua iliyoshindikana inakuambia sehemu gani ya kuangalia.

Kuzindua programu-jalizi ndio ya kwanza, na kushindikana hapo hutoa ujumbe kuhusu huduma ya VPN, si kuhusu seva. Kisha inakuja muunganisho wa TCP kwenye lango 443; kukataliwa au muda kuisha hapa ni tatizo la ufikivu, si la TLS. Kisha mshikamano wa mikono wa TLS na ukaguzi wa utambulisho wa seva, kisha majadiliano ya PPP na uthibitishaji wa akaunti, na mwisho ugawaji wa anwani na njia. Fuatilia journalctl -f -u NetworkManager unapowasha wasifu mara moja, na soma mstari wa kwanza mahususi badala ya ule wa mwisho wa jumla.

Mpangilio huo unaeleza usomaji mbaya wa kawaida. Malalamiko ya cheti huripotiwa kabla ya vitambulisho vyovyote kutumwa, kwa hiyo kubadilisha nenosiri hakuwezi kusaidia; kukataliwa kwa uthibitishaji wa PPP huja baada ya mshikamano wa mikono uliofanikiwa, kwa hiyo kubadilisha cheti pia hakuwezi kusaidia. Hifadhi hitilafu ya kwanza na hatua yake, na utakuwa na utambuzi, si dalili.

Kuamini cheti na kuingia kwenye akaunti ni malango mawili tofauti

Mshikamano wa mikono unathibitisha kuwa seva ndiyo uliyokusudia kufikia, kwa kutumia mtoaji na jina uliloweka. Ni baada ya hapo tu tabaka la PPP linatoa jina lako la mtumiaji na nenosiri kwa mbinu ya uthibitishaji ya lango. Ukaguzi mbili huru, basi, hupimwa kwa mpangilio maalum, ukiwa na mipangilio tofauti kwa kila moja. Hakuna kinachoandikwa kwenye sehemu ya nenosiri kinachoweza kuathiri ya kwanza.

Wasifu unaoamini mtoaji asiye sahihi unashindikana kwenye lango la kwanza kwa hitilafu ya utambulisho. Wasifu unaomwamini kwa usahihi lakini kuhifadhi nenosiri la zamani unashindikana kwenye la pili kwa kukataliwa kwa uthibitishaji. Zote mbili zinaonekana kama VPN ambayo haitaunganishwa, na hakuna inayorekebishwa na dawa ya nyingine.

Pata mtoaji na jina la seva linalotarajiwa kutoka kwa anayesimamia lango badala ya kukisia chaguo-msingi za kihariri, na uandike mbinu ya uthibitishaji wanayohitaji. Ikiwa shirika linahitaji mbinu ambayo programu-jalizi haiwezi kuieleza, jibu la uaminifu ni mteja aliyeidhinishwa anayeweza, si wasifu uliozimwa uthibitishaji ili hitilafu itoweke.

Acha mmiliki mmoja ashikilie wasifu na siri

Wasifu ukiwepo, uwashe kupitia NetworkManager na uache msimamizi huyo amiliki njia na mabadiliko ya kitatuzi yanayotokana. Kuanzisha mteja wa pili huru wa SSTP wakati NetworkManager tayari inaendesha muunganisho kunakupa seti mbili za njia, mipangilio miwili ya DNS na kikao cha utatuzi bila chanzo kimoja cha ukweli.

Siri pia zina mmiliki. Muunganisho uliowekwa alama kwa matumizi ya mfumo mzima huhifadhi vitambulisho kwa namna tofauti na ule uliobainishwa kwa kikao chako cha mtumiaji, na wasifu ulioundwa kwa mkono katika faili ya ufunguo unaweza usisomeke na wakala wa siri anayetarajia kutoa nenosiri kwa mwingiliano. Angalia muktadha ambao wasifu unatarajia kabla ya kuandika tena nenosiri ambalo halikuwa tatizo kamwe. Kuwasha wasifu uleule kutoka terminal kwa nmcli ni jaribio la haraka zaidi, kwa sababu kidokezo kisichotokea kamwe kinakuambia kuwa wakala hakuwa na chochote cha kutoa.

Angalia handaki, njia na kitatuzi kwa namna tofauti

Kiashiria cha kimeunganishwa kinadai tu kuwa kiungo kimeinuka. Angalia lengwa unalolihitaji kwa kweli, njia inayolibeba na kitatuzi kinachotumika, kimoja kwa wakati; kila kimoja kinaweza kuwa kibaya wakati viwili vingine viko sawa.

Kwa jaribio lililoshindikana, rekodi toleo la kila sehemu na maandishi ya hitilafu yaliyosafishwa. Shiriki hayo, si wasifu mzima, kwa sababu wasifu unaweza kuwa na siri iliyoshirikiwa mapema na vitambulisho vyako vilivyohifadhiwa.

Hatimaye, tenganisha na unganisha tena, kisha anzisha upya mara moja. Ikiwa wasifu unafanya kazi kwenye jaribio la kwanza pekee, tatizo liko katika utunzaji wa siri au umiliki wa njia, na zote mbili ni bei nafuu kurekebisha sasa kuliko katikati ya siku ya kazi.