NAT-ന് പിന്നിൽ SoftEther: നേരിട്ടുള്ള ട്രാവേഴ്സൽ അതോ VPN Azure റിലേയോ?

നിങ്ങളുടെ SoftEther സെർവർ നിങ്ങൾക്ക് മാറ്റാൻ കഴിയാത്ത ദാതാവിന്റെ റൗട്ടറിന് പിന്നിലാണ്, ക്ലയന്റുകൾ ഇപ്പോഴും കണക്ട് ചെയ്യുന്നു, അതിനാൽ ഒരു റിലേ എല്ലാം വഹിക്കുന്നുവെന്ന് നിങ്ങൾ കരുതുന്നു. അത് ശരിയാണോ എന്നത് ഏത് സംവിധാനമാണ് ജോലി ചെയ്തത് എന്നതിനെ ആശ്രയിച്ചിരിക്കുന്നു: DNS നാമം, ഏകോപിപ്പിച്ച UDP പാത, അല്ലെങ്കിൽ റിലേയിലേക്കുള്ള പുറത്തേക്കുള്ള ടണൽ. മൂന്നും കണക്ട് ചെയ്ത ക്ലയന്റ് ഉണ്ടാക്കാം, അവ വ്യത്യസ്ത സാഹചര്യങ്ങളിൽ പരാജയപ്പെടുന്നു. ഉപയോക്താക്കളെയോ ഹബ്ബുകളെയോ സ്പർശിക്കുന്നതിന് മുമ്പ് ഏത് പാതയാണ് നിങ്ങൾ വാങ്ങുന്നതെന്ന് തീരുമാനിക്കുക.

മൂന്ന് സംവിധാനങ്ങൾ, മൂന്ന് വ്യത്യസ്ത വാഗ്ദാനങ്ങൾ

ഡൈനാമിക് DNS എന്നത് നാമകരണമാണ്. മാറുന്ന വിലാസത്തിലേക്ക് ഹോസ്റ്റ്നാമം നിലനിർത്തുന്നതിലൂടെ ആളുകൾ നമ്പറിന് പിന്നാലെ ഓടുന്നത് നിർത്താൻ സഹായിക്കുന്നു, മറ്റൊന്നും ചെയ്യുന്നില്ല. തദ്ദേശീയ NAT ട്രാവേഴ്സൽ ഏകോപനമാണ്: രണ്ട് SoftEther അന്ത്യബിന്ദുക്കൾ വിവരങ്ങൾ കൈമാറുകയും അവയ്ക്കിടയിലുള്ള വിവർത്തന ഉപകരണങ്ങളിലൂടെ ഉപയോഗയോഗ്യമായ UDP പാത തുറക്കാൻ ശ്രമിക്കുകയും ചെയ്യുന്നു. VPN Azure ഒരു റിലേയാണ്: സെർവർ സേവനത്തിലേക്ക് പുറത്തേക്ക് ഡയൽ ചെയ്യുന്നു, ക്ലയന്റുകൾ റിലേയുടെ ഇൻഫ്രാസ്ട്രക്ചറിലെ ഹോസ്റ്റ്നാമിലൂടെ എത്തുന്നു.

മൂന്നും പരസ്പരം പൂരകമാണ്, ഒരു സവിശേഷതയുടെ പതിപ്പുകളല്ല. ഒരു വിന്യാസം നാമകരണം ഉപയോഗിക്കാമെങ്കിലും അതിന്റെ കണക്ഷൻ യഥാർത്ഥത്തിൽ ട്രാവേഴ്സലിനെയോ റിലേയെയോ ആശ്രയിച്ചിരിക്കുന്നു.

ക്ലയന്റിൽ നിന്നും നെറ്റ്വർക്കിൽ നിന്നും തീരുമാനിക്കുക

തിരഞ്ഞെടുപ്പ് ക്ലയന്റിൽ നിന്ന് ആരംഭിക്കുന്നു, കാരണം ട്രാവേഴ്സൽ തദ്ദേശീയ SoftEther കണക്ഷൻ സംവിധാനത്തിൽ മാത്രമേ നിലനിൽക്കുന്നുള്ളൂ. ഒരേ സെർവറിലെ OpenVPN, L2TP/IPsec, SSTP ശ്രോതാക്കൾ അത് അനുവാദമായി ലഭിക്കുന്നില്ല, ഒരു ഹോസ്റ്റ് പങ്കിട്ടാലും. ഉപയോക്താവ് എന്ത് പ്രവർത്തിപ്പിക്കും, തുടർന്ന് നെറ്റ്വർക്ക് എന്ത് അനുവദിക്കുന്നു എന്ന് നോക്കുക. TCP 443 മാത്രം അനുവദിക്കുന്ന കോർപ്പറേറ്റ് നെറ്റ്വർക്ക് നിങ്ങളെ ആ പോർട്ടിലെ റിലേയിലേക്ക് തള്ളുന്നു, എന്നാൽ ട്രാവേഴ്സലിന് ആവശ്യമായ UDP പോർട്ടുകൾ കടത്തിവിടുന്ന നെറ്റ്വർക്ക് നേരിട്ടുള്ള പാത പരീക്ഷിക്കാം; രണ്ടും യഥാർത്ഥ എഗ്രസ് നയത്തിനെതിരെ സ്ഥിരീകരിക്കുക.

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

സെഷൻ ഏത് ഗതാഗതം തിരഞ്ഞെടുത്തുവെന്ന് സ്ഥിരീകരിക്കുക

ഉപയോഗത്തിലുള്ള പാതയുടെ ഏക സത്യസന്ധമായ ഉറവിടം കണക്ഷൻ സ്ഥിതിയാണ്. അത് സെർവറിൽ വായിക്കുക, ക്ലയന്റിന് ലഭിച്ച ഹോസ്റ്റ്നാം പരിഹരിക്കുക.

vpncmd /SERVER localhost /HUB VPN /CMD:SessionList
vpncmd /SERVER localhost /HUB VPN /CMD:SessionGet <session-name>
nslookup alice.vpnazure.net

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

തിരഞ്ഞെടുത്ത പാത എന്തിനെ ആശ്രയിച്ചിരിക്കുന്നു എന്ന് ആസൂത്രണം ചെയ്യുക

ഓരോ പാതയും ഒരു ആശ്രയത്വം വഹിക്കുന്നു. നെറ്റ്വർക്ക് മാറ്റത്തിനോ പുതിയ വിവർത്തന ഉപകരണത്തിനോ ശേഷം നേരിട്ടുള്ള ട്രാവേഴ്സൽ മാറാം, എന്നാൽ സേവനമോ അതിന്റെ എത്തിച്ചേരാവുന്ന പോർട്ടോ പരാജയപ്പെടുമ്പോൾ റിലേ സെഷൻ പരാജയപ്പെടുന്നു. മറ്റൊരു നെറ്റ്വർക്കിൽ നിന്ന് വീണ്ടും കണക്ട് ചെയ്ത് ക്ലയന്റ് പരിശോധിച്ച സെർവർ ഐഡന്റിറ്റി സ്ഥിരീകരിക്കുക, മുമ്പ് പ്രവർത്തിച്ച പാത അതേ പരീക്ഷണത്തിൽ നിലനിർത്തുക. തുടർന്ന് VPN-ന് പിന്നിലുള്ള സ്വകാര്യ വിഭവം പരീക്ഷിക്കുക, കാരണം അംഗീകാരം, ഹബ്ബ് അംഗത്വം, വിലാസ അനുവദനം, മടങ്ങിവരവ് പാതകൾ ഏത് സാഹചര്യത്തിലും നിങ്ങളുടെ ഉത്തരവാദിത്വമായി തുടരുന്നു.

ഹോസ്റ്റ്നാം, പ്രോട്ടോക്കോൾ, സവിശേഷതാ ക്രമീകരണങ്ങൾ, നിരീക്ഷിച്ച ഗതാഗതം എന്നിവ എഴുതുക. ആ നാല് ഭാഗങ്ങളുള്ള റെക്കോർഡാണ് അടുത്തയാൾക്ക് പ്രവർത്തിക്കുന്ന കണക്ഷൻ പുനഃസൃഷ്ടിക്കാൻ അനുവദിക്കുന്നത്.