ഈ പൊതു VPN നോഡ് യഥാർത്ഥത്തിൽ ഏത് പ്രോട്ടോക്കോളുകൾ നൽകുന്നു?

സോഫ്റ്റ്വെയർ അതിനെ പിന്തുണയ്ക്കുന്നു, അതിനാൽ നോഡ് അത് നൽകുന്നു. ഈ അനുമാനം ഒരു നിയമമാകുന്നത്ര പതിവായി തെറ്റാണ്: SoftEther വിന്യാസത്തിന് അതിന്റെ പൊരുത്തപ്പെടുന്ന കണക്ഷൻ രീതികളുടെ ഏത് ഉപവിഭാഗവും സജീവമാക്കാം, കൂടാതെ പൊതു നോഡ് എന്നത് ഉടമയും കോൺഫിഗറേഷനും ഉള്ള ഒരു വിന്യാസമാണ്. നിങ്ങൾക്ക് എന്തുമായി ബന്ധപ്പെടാം എന്നത് ആ നോഡിനെ ആശ്രയിച്ചിരിക്കുന്നു, അത് പ്രവർത്തിപ്പിക്കുന്ന പ്രോജക്ടിന്റെ സവിശേഷതാ പട്ടികയെയല്ല. ഈ രണ്ടിനും ഇടയിലുള്ള വിടവിലാണ് “പ്രോട്ടോക്കോൾ തകർന്നിരിക്കുന്നു” എന്ന ടിക്കറ്റുകളിൽ ഭൂരിഭാഗവും യഥാർത്ഥത്തിൽ ജീവിക്കുന്നത്.

പ്രോജക്ട് പട്ടിക യഥാർത്ഥത്തിൽ എന്താണ് വാഗ്ദാനം ചെയ്യുന്നത്

പ്രോജക്ടിന്റെ പ്രോട്ടോക്കോൾ പ്രവർത്തനങ്ങൾ സെർവറിന് എന്ത് ചെയ്യാനാകും എന്ന് വിവരിക്കുന്നു. ഒരു നോഡ് ആ ശ്രോതാക്കളിൽ ചിലത് സജീവമാക്കുന്നു, മറ്റുള്ളവയല്ല, കൂടാതെ ഓപ്പറേറ്റർക്ക് സോഫ്റ്റ്വെയർ പതിപ്പിൽ തൊടാതെ ആ ഗണം മാറ്റാം. അതിനാൽ ഒരേ ബിൽഡിലെ രണ്ട് നോഡുകൾ വ്യത്യസ്തമായി പ്രവർത്തിക്കുന്നു, ഒന്നിനെതിരെ പ്രവർത്തിക്കുന്ന പ്രൊഫൈൽ അടുത്ത ലക്ഷ്യത്തെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല. എവിടെ ബന്ധപ്പെടണം എന്ന് തിരഞ്ഞെടുക്കുമ്പോൾ നോഡിന്റെ സ്വന്തം പട്ടിക പ്രോജക്ട് പേജിനേക്കാൾ പ്രാധാന്യമുള്ളതാണ്.

പട്ടിക ഒരു മെനുവായല്ല, അഞ്ച് ഫീൽഡുകളായി വായിക്കുക: എൻഡ്പോയിന്റ്, പോർട്ട്, ഗതാഗതം, പ്രോട്ടോക്കോൾ കുടുംബം, പ്രാമാണീകരണ രീതി. പരസ്യം ചെയ്യുന്ന ഒരു പൊതു നോഡ് SSTP ഒരു പോർട്ടിലെ ശ്രോതാവിനെക്കുറിച്ച് നിങ്ങളോട് പറഞ്ഞു; ഏത് സർട്ടിഫിക്കറ്റ് അവതരിപ്പിക്കുന്നു അല്ലെങ്കിൽ നിങ്ങളുടെ അക്കൗണ്ട് അവിടെ പ്രവർത്തിക്കുന്നുണ്ടോ എന്ന് പറഞ്ഞില്ല. ആ അഞ്ച് ഫീൽഡുകളെ നിങ്ങളുടെ പ്രൊഫൈലുമായി താരതമ്യപ്പെടുത്തുന്നത് എത്രയും ക്ലയന്റ് പുനഃസ്ഥാപനത്തേക്കാൾ വേഗതയുള്ളതാണ്, കൂടാതെ പിന്നീട് പരിശോധിക്കാവുന്ന ഒരു എഴുതപ്പെട്ട പ്രതീക്ഷ സൃഷ്ടിക്കുന്നു.

പ്രൊഫൈൽ അത് പേരിടുന്ന എൻഡ്പോയിന്റുമായി പൊരുത്തപ്പെടുത്തുക

നേറ്റീവ് SoftEther എൻട്രി സ്വയമേവ ഒരു OpenVPN കോൺഫിഗറേഷനല്ല, ഒരേ തലക്കെട്ടിന് കീഴിൽ ഒരേ ദാതാവിന്റെ പേജിൽ രണ്ടും പ്രത്യക്ഷപ്പെട്ടാലും. ഒരു നോഡ് OpenVPN നായി TCP, UDP ശ്രോതാക്കൾ എന്നിവ പ്രസിദ്ധീകരിക്കുമ്പോൾ, അവയെ രണ്ട് എൻഡ്പോയിന്റുകളായി കണക്കാക്കുക: ഒന്നിൽ നിന്ന് മറ്റൊന്നിലേക്ക് തിരുത്തിയ പ്രൊഫൈൽ ആരും സജീവമാക്കാത്ത ശ്രോതാവിനെ സൂചിപ്പിക്കുന്നു. ഫയലിലെ ഗതാഗത ലേബൽ വിലാസത്തിന്റെ ഭാഗമാണ്, അലങ്കാര ക്രമീകരണമല്ല.

ക്ലയന്റ് ഇറക്കുമതി ചെയ്ത ഫയൽ സ്വീകരിക്കുന്നു എന്നത് ഫയൽ പാഴ്സ് ചെയ്യുന്നു എന്ന് തെളിയിക്കുന്നു. മറുവശത്ത് ഒരു വിദൂര ശ്രോതാവ് കാത്തിരിക്കുന്നുണ്ടോ എന്നതിനെക്കുറിച്ച് അത് ഒന്നും പറയുന്നില്ല, അതിനാലാണ് ആദ്യ കണക്ഷൻ ശ്രമമാണ് യഥാർത്ഥ പരീക്ഷ. പ്രോട്ടോക്കോളിനെ കുറ്റപ്പെടുത്തുന്നതിന് മുമ്പ് പ്രൊഫൈലിന്റെ remote വരി നോഡിന്റെ പ്രഖ്യാപിത ഹോസ്റ്റും പോർട്ടും ആയി താരതമ്യപ്പെടുത്തുക.

പരാജയപ്പെടുന്ന ഘട്ടം പരിശോധിക്കുക

വെബ് ട്രാഫിക്കിന് ഉത്തരം നൽകുന്ന ഒരു ഹോസ്റ്റിനും ഉദ്ദേശിച്ച VPN സേവനം ഇല്ലായിരിക്കാം, കൂടാതെ ഒരു പ്രോട്ടോക്കോൾ നിരസിക്കുന്ന ഹോസ്റ്റ് എല്ലാത്തിനും ഡൗൺ ആയിരിക്കണമെന്നില്ല. ആ രണ്ട് തെറ്റുകൾ ആളുകളെ അതേ ഉച്ചകഴിഞ്ഞ് വിപരീത ദിശകളിലേക്ക് അയയ്ക്കുന്നു. ഒരാൾ കുഴപ്പമില്ലാത്ത ഒരു ഫയർവാളിനെ പിന്തുടരുന്നു; മറ്റൊരാൾ ഒരിക്കലും പ്രശ്നമല്ലാതിരുന്ന ക്ലയന്റ് പുനഃസ്ഥാപിക്കുന്നു. ഓരോ പാതയും വെവ്വേറെ പരിശോധിക്കുക, അപ്പോൾ ഉത്തരം മുഴുവൻ ഹോസ്റ്റിനെയല്ല, ഒരു ശ്രോതാവിനെ വിവരിക്കും.

ഈ അഞ്ച് പരിശോധനകൾ സാധാരണ പൊതു നോഡ് രീതികൾ ഉൾക്കൊള്ളുന്നു. ക്ലയന്റ് ഉപയോഗിക്കുന്ന അതേ നെറ്റ്വർക്കിൽ നിന്ന് അവ പ്രവർത്തിപ്പിക്കുക, കാരണം ഫിൽട്ടർ ചെയ്ത പോർട്ട് വിദൂരത്തുനിന്ന് കാണുമ്പോൾ കാണാത്ത ശ്രോതാവിനെപ്പോലെ തന്നെ കാണപ്പെടുന്നു.

nc -vz node.example 1194
nc -vz node.example 443
openvpn --config client.ovpn --verb 4
nmap -sU -p 500,4500 node.example
openssl s_client -connect node.example:443 -servername node.example

എന്തെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് നിരീക്ഷിച്ച ഓരോ പിശകും അതിന്റെ വരിയുമായി ബന്ധിപ്പിക്കുക. TLS ഐഡന്റിറ്റി പരാജയം ശ്രോതാവ് നിലവിലുണ്ടെന്ന് തെളിയിക്കുന്നു, അതിനാൽ പ്രൊഫൈൽ മറ്റൊരു പ്രോട്ടോക്കോളിലേക്ക് പുനർലേഖനം ചെയ്യുന്നത് പ്രവർത്തിക്കുന്ന തെളിവ് ഉപേക്ഷിക്കും. നിരസിച്ച കണക്ഷൻ ഈ പോർട്ട് ഉത്തരം നൽകിയില്ല എന്ന് മാത്രം തെളിയിക്കുന്നു, അത് “നോഡ് OpenVPN പിന്തുണയ്ക്കുന്നില്ല” എന്നതിനേക്കാൾ വളരെ ഇടുങ്ങിയ പ്രസ്താവനയാണ്.

എന്തെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് പിശക് സംരക്ഷിക്കുക

കൃത്യമായ ഫലം എഴുതുക: സമയം കഴിയൽ, സർട്ടിഫിക്കറ്റ് ഐഡന്റിറ്റി പരാജയം, അക്കൗണ്ട് നിരസിക്കൽ, ആപ്ലിക്കേഷൻ തലത്തിലുള്ള നിരസിക്കൽ എന്നിവ നാല് വ്യത്യസ്ത ഫലങ്ങളാണ്. ആദ്യത്തേത് മാത്രമാണ് പ്രോട്ടോക്കോൾ ലഭ്യമല്ലാത്തതിനെക്കുറിച്ച്, അവസാനത്തേത് മാത്രമാണ് വിജയകരമായ കണക്ഷന് ശേഷമുള്ള അനുമതിയെക്കുറിച്ച്. ക്ലയന്റ് പുനഃസജ്ജമാക്കുന്നതോ പ്രോട്ടോക്കോളുകൾ മാറ്റുന്നതോ ആ വ്യത്യാസം നശിപ്പിക്കുന്നു, കാരണം അടുത്ത പരാജയം വ്യത്യസ്ത ചരിത്രവുമായി താരതമ്യത്തിന് അടിസ്ഥാന രേഖയും ഇല്ലാതെ വരുന്നു.

പൊരുത്തപ്പെടാത്ത പ്രൊഫൈൽ പ്രവർത്തിക്കുന്നതായി തോന്നാൻ പരിശോധന ദുർബലമാക്കരുത്. പ്രവർത്തനരഹിതമാക്കിയ സർട്ടിഫിക്കറ്റ് പരിശോധന വ്യക്തമായ ഐഡന്റിറ്റി പരാജയത്തെ നിങ്ങൾ ഉദ്ദേശിക്കാത്ത എന്തിലേക്കോ ഉള്ള കണക്ഷനാക്കി മാറ്റുന്നു, കൂടാതെ അതിൽ നിന്നുള്ള വിജയം ഏത് ഘട്ടമാണ് തെറ്റായിരുന്നത് എന്ന് മറയ്ക്കുന്നതിനാൽ യഥാർത്ഥ പിശകിനേക്കാൾ മോശമാണ്.

ഓരോ നോഡിനും ഓരോ തവണയും വീണ്ടും പരിശോധിക്കുക

ഒരു പൊതു നോഡ് പട്ടികയിലെ നേറ്റീവ് SSL, OpenVPN, L2TP/IPsec, SSTP ഓപ്ഷനുകൾ ആ നിമിഷത്തെ ആ നോഡിന്റെ കോൺഫിഗറേഷനെ വിവരിക്കുന്നു. അതേ സോഫ്റ്റ്വെയർ മറ്റൊരിടത്ത് വ്യത്യസ്ത ഗണം അവതരിപ്പിക്കാം, കൂടാതെ ഒരു ദാതാവിന് നിങ്ങളുടെ ബുക്ക്മാർക്കും അടുത്ത ശ്രമവും ഇടയിൽ ഒരു ശ്രോതാവിനെ പിൻവലിക്കാം. പഴയ കുറിപ്പുകൾ പഴയ വിന്യാസങ്ങളെ വിവരിക്കുന്നു.

പരിശോധിച്ച പ്രൊഫൈൽ അതിന്റെ എൻഡ്പോയിന്റും രീതിയും സഹിതം രേഖപ്പെടുത്തുക, തുടർന്ന് നോഡ് മാറുമ്പോഴോ കണക്ഷൻ പരാജയപ്പെടാൻ തുടങ്ങുമ്പോഴോ പരിശോധന ആവർത്തിക്കുക. SoftEther പ്രോട്ടോക്കോൾ സ്പെസിഫിക്കേഷൻ സോഫ്റ്റ്വെയർക്ക് എന്ത് ചെയ്യാനാകും എന്നതിനുള്ള റഫറൻസാണ്; നോഡിന്റെ സ്വന്തം പട്ടിക അത് എന്ത് ചെയ്യുന്നു എന്നതിനുള്ള റഫറൻസാണ്. രണ്ട് രേഖകളും വെവ്വേറെ സൂക്ഷിക്കുക, രോഗനിർണ്ണയം ചെറുതാകും.