Linux-ൽ ലോഗിൻ ചെയ്യുന്നതിന് മുമ്പ് SSTP പരാജയപ്പെടുന്നോ? റൺടൈം ഭാഗങ്ങൾ പരിശോധിക്കുക

നിങ്ങൾ SSTP പ്ലഗിൻ ഇൻസ്റ്റാൾ ചെയ്യുന്നു, നെറ്റ്വർക്ക് എഡിറ്ററിൽ റേഡിയോ ബട്ടൺ പ്രത്യക്ഷപ്പെടുന്നു, ഗേറ്റ്‌വേയും ഉപയോക്തൃനാമവും പൂരിപ്പിക്കുന്നു, പ്രൊഫൈൽ പാസ്‌വേഡ് ചോദിക്കുന്നതിന് മുമ്പുതന്നെ പൊതുവായ പിശകോടെ പരാജയപ്പെടുന്നു. ആ ക്രമത്തിൽ അസാധാരണമായി ഒന്നുമില്ല, അതിൽ ടണൽ സോഫ്റ്റ്‌വെയർ ഇൻസ്റ്റാൾ ചെയ്തതായി തെളിയിക്കുന്നതുമില്ല. SSTP കണക്ഷൻ വെവ്വേറെ വിതരണം ചെയ്യുന്ന ഭാഗങ്ങളിൽ നിന്ന് കൂട്ടിച്ചേർക്കുന്നു: NetworkManager പ്രവർത്തിപ്പിക്കാവുന്ന VPN പ്ലഗിൻ, TLS, PPP സെഷൻ കൈവശം വയ്ക്കുന്ന SSTP ക്ലയന്റ് പ്രോഗ്രാം, അതിനടിയിലുള്ള PPP ഡീമൺ, കണക്ഷന് വായിക്കാൻ അനുവാദമുള്ള രഹസ്യ സംഭരണി.

മെനു എൻട്രി എന്ത് ചേർക്കുന്നു, എന്ത് ചേർക്കുന്നില്ല

പ്ലഗിൻ NetworkManager-നോട് അത് എങ്ങനെ ആരംഭിക്കണമെന്ന് പറയുന്ന സേവന വിവരണവും, മിക്ക വിതരണങ്ങളിലും ഫോം വരയ്ക്കുന്ന ചെറിയ എഡിറ്ററും നൽകുന്നു. മെനു എൻട്രിയുടെ മുഴുവൻ പരിധി അത്രയേയുള്ളൂ. ക്ലയന്റ് പ്രോഗ്രാം മറ്റൊരു സോഴ്‌സ് പാക്കേജിൽ നിന്ന് വരുന്നു, പ്ലഗിന്റെ സ്വന്തം README ആ വിഭജനം നേരിട്ട് പറയുന്നു: ഇത് ഒരു പ്ലഗിൻ ആണ്, ക്ലയന്റ് അല്ല.

തുടർന്ന് ക്ലയന്റിന് PPP ആവശ്യമാണ്, കാരണം SSTP TLS കണക്ഷനുള്ളിൽ PPP സെഷൻ വഹിക്കുന്നു. pppd ഇല്ലാതെ ടണൽ TLS ഹാൻഡ്‌ഷേക്ക് പൂർത്തിയാക്കിയാലും ആദ്യ നിയന്ത്രണ ഫ്രെയിമിൽ മരിക്കാം, ഇത് ക്രെഡൻഷ്യൽ പ്രശ്‌നമായി തോന്നുമെങ്കിലും അല്ല. Debian, Ubuntu എന്നിവയിൽ ഭാഗങ്ങൾ network-manager-sstp, sstp-client, ppp എന്നിവയായി വരുന്നു, ആദ്യത്തേത് മാത്രം ഇൻസ്റ്റാൾ ചെയ്യുന്നതാണ് ഫോം എല്ലാ ഫീൽഡും സ്വീകരിക്കുകയും എന്നാൽ കണക്ഷൻ ഒരിക്കലും പൂർത്തിയാകാതിരിക്കുകയും ചെയ്യുന്നതിന്റെ ഏറ്റവും സാധാരണ കാരണം.

ഡെസ്ക്ടോപ്പ് തിരഞ്ഞെടുപ്പ് ഒരു വിഭജനം കൂടി ചേർക്കുന്നു. Plasma പ്രൊഫൈലുകൾ plasma-nm വഴി എഡിറ്റ് ചെയ്യുന്നു, അതിന് സ്വന്തം SSTP ഘടകം ആവശ്യമാണ്, അതേ സേവന വിവരണം വായിക്കുന്നു, അതിനാൽ SSTP എൻട്രി ഇല്ലാത്ത എഡിറ്ററും പ്രൊഫൈലുകൾ നന്നായി സൃഷ്ടിക്കുന്ന CLI-യും തകർന്ന റൺടൈം അല്ല, മറിച്ച് കാണാത്ത എഡിറ്റർ പകുതിയാണ്.

എന്തെങ്കിലും വീണ്ടും ഇൻസ്റ്റാൾ ചെയ്യുന്നതിന് മുമ്പ് ആദ്യ പരാജയ ഘട്ടം വായിക്കുക

പരാജയപ്പെട്ട SSTP ശ്രമം നിശ്ചിത ക്രമത്തിൽ ഘട്ടങ്ങളിലൂടെ കടന്നുപോകുന്നു, പരാജയപ്പെട്ട ഘട്ടം ഏത് ഘടകം നോക്കണമെന്ന് പറയുന്നു.

പ്ലഗിൻ ആരംഭിക്കുന്നതാണ് ആദ്യം, അവിടെയുള്ള പരാജയം സെർവറിനെക്കുറിച്ചല്ല, VPN സേവനത്തെക്കുറിച്ചുള്ള സന്ദേശം നൽകുന്നു. തുടർന്ന് പോർട്ട് 443-ലേക്കുള്ള TCP കണക്ഷൻ വരുന്നു; ഇവിടെ നിരസിക്കലോ സമയപരിധിയോ എത്തിച്ചേരൽ പ്രശ്‌നമാണ്, TLS അല്ല. പിന്നെ TLS ഹാൻഡ്‌ഷേക്കും സെർവർ ഐഡന്റിറ്റി പരിശോധനയും, പിന്നെ PPP ചർച്ചകളും അക്കൗണ്ട് ആഥന്റിക്കേഷനും, അവസാനം വിലാസ വിതരണവും റൂട്ടുകളും. പ്രൊഫൈൽ ഒരിക്കൽ സജീവമാക്കുമ്പോൾ journalctl -f -u NetworkManager നിരീക്ഷിക്കുക, അവസാന പൊതു വരിയല്ല, ആദ്യത്തെ നിർദ്ദിഷ്ട വരി വായിക്കുക.

ആ ക്രമം സാധാരണ തെറ്റായ വായന വിശദീകരിക്കുന്നു. ഏതെങ്കിലും ക്രെഡൻഷ്യൽ അയയ്ക്കുന്നതിന് മുമ്പേ സർട്ടിഫിക്കറ്റ് പരാതി റിപ്പോർട്ട് ചെയ്യുന്നു, അതിനാൽ പാസ്‌വേഡ് മാറ്റുന്നത് സഹായിക്കില്ല; PPP ആഥന്റിക്കേഷൻ നിരസിക്കൽ വിജയകരമായ ഹാൻഡ്‌ഷേക്കിന് ശേഷം വരുന്നു, അതിനാൽ സർട്ടിഫിക്കറ്റ് മാറ്റുന്നതും സഹായിക്കില്ല. ആദ്യ പിശകും അതിന്റെ ഘട്ടവും സൂക്ഷിക്കുക, എങ്കിൽ ലക്ഷണമല്ല, രോഗനിർണയം ലഭിക്കും.

സർട്ടിഫിക്കറ്റ് വിശ്വാസവും അക്കൗണ്ട് ലോഗിനും വെവ്വേറെ ഗേറ്റുകളാണ്

ഹാൻഡ്‌ഷേക്ക് സെർവർ നിങ്ങൾ എത്താൻ ഉദ്ദേശിച്ചതാണെന്ന് നിങ്ങൾ കോൺഫിഗർ ചെയ്ത ഇഷ്യൂവറും പേരും ഉപയോഗിച്ച് സ്ഥിരീകരിക്കുന്നു. അതിന് ശേഷം മാത്രം PPP പാളി നിങ്ങളുടെ ഉപയോക്തൃനാമവും പാസ്‌വേഡും ഗേറ്റ്‌വേയുടെ ആഥന്റിക്കേഷൻ രീതിക്ക് നൽകുന്നു. അതായത് രണ്ട് സ്വതന്ത്ര പരിശോധനകൾ, നിശ്ചിത ക്രമത്തിൽ വിലയിരുത്തപ്പെടുന്നു, ഓരോന്നിനും പ്രത്യേക ക്രമീകരണങ്ങൾ. പാസ്‌വേഡ് ഫീൽഡിൽ ടൈപ്പ് ചെയ്യുന്ന ഒന്നിനും ആദ്യത്തേതിനെ സ്വാധീനിക്കാനാവില്ല.

തെറ്റായ ഇഷ്യൂവറെ വിശ്വസിക്കുന്ന പ്രൊഫൈൽ ആദ്യ ഗേറ്റിൽ ഐഡന്റിറ്റി പിശകോടെ പരാജയപ്പെടുന്നു. അതിനെ ശരിയായി വിശ്വസിക്കുന്നുവെങ്കിലും പഴയ പാസ്‌വേഡ് സൂക്ഷിക്കുന്ന പ്രൊഫൈൽ രണ്ടാമത്തേതിൽ ആഥന്റിക്കേഷൻ നിരസിക്കലോടെ പരാജയപ്പെടുന്നു. രണ്ടും ബന്ധിപ്പിക്കാത്ത VPN പോലെ തോന്നുന്നു, ഒന്നും മറ്റൊന്നിന്റെ മരുന്നുകൊണ്ട് ശരിയാകുന്നില്ല.

എഡിറ്ററിന്റെ സ്ഥിരസ്ഥിതികൾ ഊഹിക്കുന്നതിന് പകരം ഗേറ്റ്‌വേ നടത്തുന്നവരിൽ നിന്ന് പ്രതീക്ഷിക്കുന്ന ഇഷ്യൂവറും സെർവർ പേരും നേടുക, അവർ ആവശ്യപ്പെടുന്ന ആഥന്റിക്കേഷൻ രീതി രേഖപ്പെടുത്തുക. സംഘടനയ്ക്ക് പ്ലഗിൻ പ്രകടിപ്പിക്കാനാവാത്ത ഒരു രീതി വേണമെങ്കിൽ, സത്യസന്ധമായ ഉത്തരം അത് ചെയ്യാനാവുന്ന അംഗീകൃത ക്ലയന്റാണ്, പിശക് അപ്രത്യക്ഷമാക്കാൻ സാധുത പരിശോധന ഓഫ് ചെയ്ത പ്രൊഫൈലല്ല.

ഒരു ഉടമ മാത്രം പ്രൊഫൈലും രഹസ്യങ്ങളും കൈവശം വയ്ക്കട്ടെ

പ്രൊഫൈൽ ഉള്ളപ്പോൾ, NetworkManager വഴി അത് സജീവമാക്കുക, തത്ഫലമായുണ്ടാകുന്ന റൂട്ടുകളുടെയും റിസോൾവർ മാറ്റങ്ങളുടെയും ഉടമസ്ഥത ആ മാനേജർക്ക് നൽകുക. NetworkManager ഇതിനകം കണക്ഷൻ നടത്തുമ്പോൾ രണ്ടാമത്തെ സ്വതന്ത്ര SSTP ക്ലയന്റ് ആരംഭിച്ചാൽ നിങ്ങൾക്ക് രണ്ട് റൂട്ട് സെറ്റുകൾ, രണ്ട് DNS കോൺഫിഗറേഷനുകൾ, ഒരൊറ്റ സത്യ സ്രോതസ്സില്ലാത്ത ഡീബഗ്ഗിംഗ് സെഷൻ ലഭിക്കും.

രഹസ്യങ്ങൾക്കും ഉടമയുണ്ട്. സിസ്റ്റം-വ്യാപക ഉപയോഗത്തിനായി അടയാളപ്പെടുത്തിയ കണക്ഷൻ നിങ്ങളുടെ ഉപയോക്തൃ സെഷനിൽ പരിമിതമായ കണക്ഷനിൽ നിന്ന് വ്യത്യസ്തമായി ക്രെഡൻഷ്യലുകൾ സൂക്ഷിക്കുന്നു, കീ-ഫയലിൽ കൈകൊണ്ട് സൃഷ്ടിച്ച പ്രൊഫൈൽ പാസ്‌വേഡ് ഇന്ററാക്ടീവായി നൽകാൻ പ്രതീക്ഷിക്കുന്ന രഹസ്യ ഏജന്റിന് വായിക്കാനാവണമെന്നില്ല. ഒരിക്കലും പ്രശ്‌നമല്ലാത്ത പാസ്‌വേഡ് വീണ്ടും ടൈപ്പ് ചെയ്യുന്നതിന് മുമ്പ് പ്രൊഫൈൽ ഏത് സന്ദർഭം പ്രതീക്ഷിക്കുന്നുവെന്ന് പരിശോധിക്കുക. അതേ പ്രൊഫൈൽ ടെർമിനലിൽ നിന്ന് nmcli ഉപയോഗിച്ച് സജീവമാക്കുന്നതാണ് ഏറ്റവും വേഗതയേറിയ പരിശോധന, കാരണം ഒരിക്കലും വരാത്ത പ്രോംപ്റ്റ് ഏജന്റിന് ഇതിനകം നൽകാൻ ഒന്നുമില്ലായിരുന്നു എന്ന് പറയുന്നു.

ടണൽ, റൂട്ടുകൾ, റിസോൾവർ എന്നിവ വെവ്വേറെ പരിശോധിക്കുക

കണക്റ്റഡ് സൂചകം ലിങ്ക് ഉയർന്നു എന്ന് മാത്രം അവകാശപ്പെടുന്നു. നിങ്ങൾക്ക് യഥാർത്ഥത്തിൽ ആവശ്യമുള്ള ലക്ഷ്യസ്ഥാനം, അത് വഹിക്കുന്ന റൂട്ട്, ഉപയോഗത്തിലുള്ള റിസോൾവർ എന്നിവ ഓരോന്നായി പരിശോധിക്കുക; ഓരോന്നും തെറ്റാകാം, ബാക്കിയുള്ള രണ്ടും കുഴപ്പമില്ലാതിരിക്കുമ്പോൾ.

പരാജയപ്പെട്ട ശ്രമത്തിന് ഓരോ ഘടകത്തിന്റെയും പതിപ്പും ശുദ്ധീകരിച്ച പിശക് ടെക്സ്റ്റും രേഖപ്പെടുത്തുക. മുഴുവൻ പ്രൊഫൈലല്ല, അവ പങ്കിടുക, കാരണം പ്രൊഫൈലിൽ മുൻകൂട്ടി പങ്കിട്ട രഹസ്യവും നിങ്ങളുടെ സംഭരിച്ച ക്രെഡൻഷ്യലുകളും ഉണ്ടാകാം.

അവസാനം, വിച്ഛേദിച്ച് വീണ്ടും ബന്ധിപ്പിക്കുക, പിന്നെ ഒരിക്കൽ റീബൂട്ട് ചെയ്യുക. പ്രൊഫൈൽ ആദ്യ ശ്രമത്തിൽ മാത്രം പ്രവർത്തിക്കുന്നുവെങ്കിൽ, പ്രശ്‌നം രഹസ്യ കൈകാര്യത്തിലോ റൂട്ട് ഉടമസ്ഥതയിലോ ആണ്, രണ്ടും ഇപ്പോൾ ശരിയാക്കുന്നത് ജോലി ദിവസത്തിന് നടുവിൽ ശരിയാക്കുന്നതിനേക്കാൾ വിലകുറവാണ്.