റോമിംഗ് VPN ക്ലയന്റിന് ഓഫീസിനായി ഒരു സേവനം ഹോസ്റ്റ് ചെയ്യാൻ കഴിയുമോ?

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

ഡയൽ-ഇൻ ദിശ സേവന ദിശയെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല

ഒരു ക്ലയന്റ് ടണൽ ആരംഭിക്കുമ്പോൾ, അത് നിലവിൽ വന്നതിന് ശേഷം രണ്ട് ദിശകൾക്കും ഉപയോഗിക്കാവുന്ന ഒരു പാത തുറക്കുന്നു. ഹബ്ബിൽ നിന്ന് ആ ക്ലയന്റിലേക്ക് പുതിയ കണക്ഷൻ പ്രവേശിക്കാമോ എന്നത് ഗേറ്റ്വേ നയത്തിന്റെ ചോദ്യമാണ്, ഡയൽ ചെയ്തയാളുടെ സ്വഭാവമല്ല. ഉദാഹരണത്തിന്, റൂട്ട് ചെയ്ത OpenVPN ഹബ്ബിൽ സെർവറിന് ക്ലയന്റിന്റെ ആന്തരിക വിലാസത്തിലേക്കുള്ള റൂട്ടും പിയർ ബന്ധം അനുവദിക്കുന്ന ഫോർവേഡിംഗും ആവശ്യമാണ്.

റോമിംഗ് ലാപ്ടോപ്പുകളിലെ ഏജന്റിനെ പോൾ ചെയ്യുന്ന ഒരു ഇൻവെന്ററി സിസ്റ്റമോ, വീട്ടിലെ വർക്ക്സ്റ്റേഷനിൽ നിന്ന് ടെസ്റ്റ് API ആവശ്യമുള്ള ഒരു ഡെവലപ്പറെയോ സങ്കൽപ്പിക്കുക. രണ്ടുപേരും ഓഫീസ് ഭാഗം സംഭാഷണം തുടങ്ങണമെന്ന് ആഗ്രഹിക്കുന്നു, ഇത് സാധാരണ ക്ലയന്റ്-ടു-സെർവർ മാതൃകയുടെ വിപരീതമാണ്.

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

പോർട്ട് തുറക്കുന്നതിന് മുൻപ് മടക്കപ്പാത പിന്തുടരുക

പാതയ്ക്ക് മൂന്ന് ഭാഗങ്ങളുണ്ട്: ഗേറ്റ്വേയിൽ ക്ലയന്റിന്റെ ആന്തരിക വിലാസത്തിലേക്ക് ചൂണ്ടുന്ന ഒരു റൂട്ട്, നിർദ്ദിഷ്ട വിളിക്കുന്നയാളെ അനുവദിക്കുന്ന നയം, ലക്ഷ്യത്തിൽ കേൾക്കുന്ന ഒരു സേവനം. ഓരോ ഭാഗവും വ്യത്യസ്ത രീതിയിൽ പരാജയപ്പെടുന്നു, അതിനാൽ «VPN ഓണാണ്» എന്നത് ഏതാണ്ട് ഒന്നും പറയുന്നില്ല.

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

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

പേരുകളും വിലാസങ്ങളും ഡിസൈൻ തീരുമാനങ്ങളാണ്

ടണലിനുള്ളിലെ വിലാസം സ്വയം ഒരു പേരാകുന്നില്ല. നിങ്ങൾ നിയന്ത്രിക്കുന്ന സ്വകാര്യ DNS റെക്കോർഡ്, ഡിസ്കവറി പ്രോട്ടോക്കോൾ ടണൽ കടക്കുമെന്ന പ്രതീക്ഷയെക്കാൾ വ്യക്തമാണ്, കാരണം ലിങ്ക്-ലോക്കൽ മൾട്ടികാസ്റ്റ് നാമ നിർണ്ണയം പ്രാദേശിക സെഗ്മെന്റിൽ തന്നെ തുടരുന്നു, സബ്നെറ്റുകൾക്കിടയിലുള്ള DNS ആകുന്നില്ല.

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

VPN ഐഡന്റിറ്റി ഉടമയുമായി പേര് യോജിക്കുക, അതുവഴി റെക്കോർഡും വിലാസ വിഭജനവും ആക്സസ് നയവും മൂന്ന് വേറിട്ട ടിക്കറ്റുകളിലല്ല, ഒരുമിച്ച് മാറും.

അംഗത്വമല്ല, സേവനം പരിശോധിക്കുക

ലക്ഷ്യത്തിൽ നിന്ന് എന്താണ് ഏത് വിലാസത്തിൽ കേൾക്കുന്നതെന്ന് ഉറപ്പാക്കുക, തുടർന്ന് തിരിച്ചുള്ള പാതയെക്കുറിച്ചുള്ള ഗേറ്റ്വേയുടെ കാഴ്ച ഉറപ്പാക്കുക:

$ ss -ltnp | grep 8080
LISTEN 0 128 10.80.0.23:8080 0.0.0.0:*
$ ip -4 addr show tun0 | grep inet
inet 10.80.0.23/24 scope global tun0
$ ip route get 10.80.0.1
10.80.0.1 dev tun0 src 10.80.0.23

ഇപ്പോൾ ഓഫീസ് ഭാഗത്തുനിന്ന് പ്രതിധ്വനിക്ക് പകരം യഥാർത്ഥ അഭ്യർത്ഥന ഉപയോഗിച്ച് പരീക്ഷിക്കുക. സേവനത്തിനെതിരെയുള്ള വിജയകരമായ curl പാത, നയം, കേൾക്കുന്നയാൾ എന്നിവ ഒരുമിച്ച് തെളിയിക്കുന്നു, അതേസമയം വിജയകരമായ പിംഗ് ICMP അനുവദനീയമാണെന്ന് മാത്രം തെളിയിക്കുന്നു. അഭ്യർത്ഥന പരാജയപ്പെട്ടാൽ, ഫയർവാൾ വിശാലമാക്കി പ്രതീക്ഷിക്കുന്നതിന് പകരം മൂന്ന് ഭാഗങ്ങളിലൂടെ പിന്നോട്ട് പോകുക.

ലഭ്യത അതേ സംഭാഷണത്തിന്റെ ഭാഗമാണ്. ലാപ്ടോപ്പ് ഉറങ്ങുന്നു, നെറ്റ്വർക്കുകൾക്കിടയിൽ സഞ്ചരിക്കുന്നു, ദിവസാവസാനം വിച്ഛേദിക്കുന്നു. ഏത് മണിക്കൂറിലും ഉത്തരം നൽകേണ്ട ഒരു സേവനം എപ്പോഴും ഓണായിരിക്കുന്ന ഹോസ്റ്റിലാണ് വേണ്ടത്, അതേസമയം മികച്ച-ശ്രമ സേവനം ആ പരിമിതി എഴുതിവെച്ച് ക്ലയന്റിൽ തുടരാം.

പേര്, അനുവദനീയമായ വിളിക്കുന്നവരുടെ പട്ടിക, ഉടമ എന്നിവയോടെ വിഭവം ബോധപൂർവം പ്രസിദ്ധീകരിക്കുക, എന്നാൽ ദൂരെയുള്ള ഉപകരണം ആകസ്മിക സെർവറല്ല, പിന്തുണയുള്ള സേവനമായി മാറുന്നു.