രണ്ടറ്റത്തും ഒരേ സബ്നെറ്റ്: വിദൂര LAN ഒരു സ്വതന്ത്ര ശ്രേണിയിലേക്ക് മാപ്പ് ചെയ്യുക

വീടും ഓഫീസും 192.168.1.0/24 ഉപയോഗിക്കുന്നു, അതിനാൽ 192.168.1.1 ലേക്കുള്ള അഭ്യർത്ഥനയ്ക്ക് രണ്ട് സാധ്യമായ ഉത്തരങ്ങളുണ്ട്, ക്ലയന്റ് ചോദിക്കാതെ ഒന്ന് തിരഞ്ഞെടുക്കുന്നു. പ്രവർത്തിക്കുന്ന ഓഫീസ് നെറ്റ്വർക്ക് പുനർനമ്പർ ചെയ്യുന്നത് അപൂർവ്വമായേ ജനപ്രിയമാകൂ, റൗട്ടറിന്റെ വിലാസങ്ങൾ പലപ്പോഴും പ്രിന്ററുകളിലും ക്യാമറകളിലും രേഖകളിലും ഉറച്ചിരിക്കുന്നു. ക്ലയന്റ് വശത്തെ വിലാസ മാപ്പിംഗിന് പകരം വിദൂര നെറ്റ്വർക്ക് ഒരു സ്വതന്ത്ര ശ്രേണിക്ക് കീഴിൽ അവതരിപ്പിക്കാം, ഹോസ്റ്റ് ഭാഗം അതേപടി നിലനിർത്താം, അതിനാൽ 192.168.1.20 10.203.41.20 ആയി കാണപ്പെടുന്നു. കുരുക്ക് എന്തെന്നാൽ ചില ക്ലയന്റുകൾ മാത്രമേ അത് നടപ്പാക്കുന്നുള്ളൂ, മടങ്ങിവരവ് പാതയ്ക്ക് അത് ഒന്നും ചെയ്യുന്നുമില്ല.

ഒരേ ഹോസ്റ്റിന്റെ രണ്ട് കാഴ്ചകൾ

മാപ്പിംഗ് ഹോസ്റ്റ് ഭാഗം നിലനിർത്തി നെറ്റ്വർക്ക് ഭാഗം മാത്രം മാറ്റുന്നു. അപ്പോൾ അതേ യന്ത്രം നിങ്ങൾ നിൽക്കുന്ന സ്ഥലം അനുസരിച്ച് രണ്ട് വിലാസങ്ങളിൽ പ്രതികരിക്കുന്നു. എന്തെങ്കിലും കോൺഫിഗർ ചെയ്യുന്നതിന് മുമ്പ് രണ്ട് നിരകളും എഴുതിവെച്ചാൽ പിന്നീട് ലോഗുകളും ഫയർവാൾ നിയമങ്ങളും തെറ്റായി വായിക്കുന്നത് ഒഴിവാക്കാം.

വീട്ടിലെ പ്രാദേശിക ഉപകരണങ്ങൾ അവയുടെ 192.168.1.x വിലാസങ്ങൾ നിലനിർത്തുന്നു, അതാണ് ഈ അഭ്യാസത്തിന്റെ ഉദ്ദേശ്യം. അടുത്ത മുറിയിലെ പ്രിന്റർ എത്തിച്ചേരാവുന്നതായി തുടരുന്നു, ഓഫീസ് കൂട്ടിയിടിക്കാത്ത ശ്രേണിക്ക് കീഴിൽ പ്രത്യക്ഷപ്പെടുന്നു.

ആർഗ്യുമെന്റുകളുടെ ക്രമമാണ് മുഴുവൻ തന്ത്രം

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

push "route 10.203.41.0 255.255.255.0"
push "client-nat dnat 10.203.41.0 255.255.255.0 192.168.1.0"

പുതിയ ശ്രേണിക്കുള്ള ക്ലയന്റിന്റെ പാക്കറ്റുകളെ ടണലിലേക്ക് അയക്കുന്നത് റൂട്ടാണ്; വിവർത്തനം വഴിയിൽ ലക്ഷ്യസ്ഥാനം വീണ്ടും എഴുതുന്നു. 192.168.1.20 ൽ നിന്നുള്ള മറുപടി 10.203.41.20 ലേക്ക് തിരികെ എഴുതുന്നു, അതിനാൽ ക്ലയന്റിലെ സോക്കറ്റ് സ്ഥിരതയുള്ളതായി തുടരുന്നു. ഒറ്റ ഹോസ്റ്റും പൂർണ്ണ നീളമുള്ള മാസ്കുമായി അതേ രീതിയിൽ പ്രവർത്തിക്കുന്നു, റൂട്ടും മാപ്പിംഗും ഒരേ വിലാസം വിവരിക്കുന്നിടത്തോളം.

ഇത് വിലാസ മാപ്പിംഗാണ്, പോർട്ട് മാപ്പിംഗല്ല. ഒരു ഹോസ്റ്റിലെ രണ്ട് സേവനങ്ങളെ ഇതുകൊണ്ട് വേർതിരിക്കാനാവില്ല, അതിന്റെ പേലോഡിൽ IP വിലാസങ്ങൾ ഉൾച്ചേർക്കുന്ന പ്രോട്ടോക്കോൾ ഇപ്പോഴും യഥാർത്ഥവ കാണും.

മാപ്പിംഗ് മടങ്ങിവരവ് പാത സൃഷ്ടിക്കുന്നില്ല

വിവർത്തനം ക്ലയന്റിൽ സംഭവിക്കുന്നു, അതിനാൽ സർവർ ഇപ്പോഴും മറുപടികൾ ടണലിലേക്ക് റൂട്ട് ചെയ്യണം, അതിന്റെ ഫയർവാൾ ഇപ്പോഴും അവ അനുവദിക്കണം. വിദൂര ഗേറ്റ്വേയ്ക്ക് ടണലിന്റെ സബ്നെറ്റ് എങ്ങനെ എത്തിച്ചേരാമെന്ന് അറിയില്ലെങ്കിൽ, അഭ്യർത്ഥന എത്തുന്നു, മറുപടി തെറ്റായ വാതിലിലൂടെ പുറത്തുപോകുന്നു; മാപ്പിംഗ് പരാജയത്തെ ക്ലയന്റ് പ്രശ്നമായി കാണിക്കുന്നു മാത്രം.

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

ക്ലയന്റ് റൂട്ട് ചെയ്യുന്ന മറ്റൊന്നുമായി കൂട്ടിയിടിക്കാത്ത ഒരു അലിയാസ് ശ്രേണി തിരഞ്ഞെടുക്കുക: മറ്റൊരു VPN, കണ്ടെയ്നർ നെറ്റ്വർക്ക്, രണ്ടാം ഓഫീസ്. ഇവിടെയുള്ള കൂട്ടിയിടി യഥാർത്ഥ അവ്യക്തതയെ മറ്റൊരു നമ്പറിന് കീഴിൽ തിരികെ കൊണ്ടുവരുന്നു, വിലാസങ്ങൾ പരിചിതമല്ലാത്തതിനാൽ ശ്രദ്ധിക്കാൻ ബുദ്ധിമുട്ടാണ്.

പേരുകളും പേലോഡുകളും വിവർത്തനത്തെ അതിജീവിക്കുന്നു

യഥാർത്ഥ 192.168.1.20 ലേക്ക് പരിഹരിക്കുന്ന ഹോസ്റ്റ്നാമം ബ്രൗസറിനെ വിദൂരത്തിലേക്കല്ല, പ്രാദേശിക ഉപകരണത്തിലേക്ക് അയക്കുന്നു, റൂട്ടിംഗ് പട്ടിക എന്ത് പറഞ്ഞാലും. സ്വകാര്യ DNS മറുപടി ക്ലയന്റിന് കാണാവുന്ന ശ്രേണിയിലേക്ക് ചൂണ്ടണം, TLS സർട്ടിഫിക്കറ്റ് ഇപ്പോഴും അപ്ലിക്കേഷൻ പ്രതീക്ഷിക്കുന്ന പേര് വഹിക്കുന്നു. വിലാസത്തിന് പകരം പേര് ഉപയോഗിച്ച് പരിശോധിക്കുക, കാരണം വിലാസം പ്രവർത്തിക്കാം, പേര് നിശബ്ദമായി തെറ്റായ ദിശയിലേക്ക് പരിഹരിക്കാം. വിദൂര ഗേറ്റ്വേ ആ മേഖലയും സേവിക്കുന്നുവെങ്കിൽ, അതിന്റെ സ്വന്തം റെക്കോർഡുകൾക്കും ക്ലയന്റിന് കാണാവുന്ന ശ്രേണി വേണം.

റീഡയറക്ടുകൾ, ഉൾച്ചേർത്ത URL-കൾ, സ്വന്തം വിലാസം പേലോഡിൽ നൽകുന്ന അപ്ലിക്കേഷനുകൾ എന്നിവ ഏതൊരു പാക്കറ്റ് മാപ്പിംഗിനും നന്നാക്കാനാവാത്ത രീതിയിൽ തകരാം. അവയെ അപ്ലിക്കേഷൻ പ്രശ്നമായി കണക്കാക്കി, പുനർനമ്പർ ആവശ്യമില്ലെന്ന് വാഗ്ദാനം ചെയ്യുന്നതിന് മുമ്പ് പ്രയത്നം അതിനനുസരിച്ച് കണക്കാക്കുക.

പ്രതിജ്ഞാബദ്ധരാകുന്നതിന് മുമ്പ് മൂന്ന് പരിശോധനകൾ

ആദ്യം, ക്ലയന്റ് നടപ്പാക്കൽ സ്ഥിരീകരിക്കുക. Community OpenVPN ഈ ഓപ്ഷനെ പിന്തുണയ്ക്കുന്നു; OpenVPN 3 കോഡ്ബേസ് അതിനെ പിന്തുണയ്ക്കാത്ത സവിശേഷതകളിൽ പട്ടികപ്പെടുത്തുന്നു, അതിനാൽ Connect ശൈലിയിലുള്ള ക്ലയന്റിലേക്ക് തള്ളിയ പ്രൊഫൈൽ അതിനെ നിരസിക്കാം. സ്വീകരിക്കപ്പെട്ടിട്ടും ഒരിക്കലും പ്രയോഗിക്കാത്ത നിർദ്ദേശം പിശകിനേക്കാൾ മോശമാണ്, കാരണം ടണൽ ആരോഗ്യകരമായി കാണപ്പെടുന്നു.

രണ്ടാമത്, ഉയർന്ന വിശദാംശത്തിൽ ചെറിയ ഡയഗ്നോസ്റ്റിക് വിൻഡോ ഉപയോഗിച്ച് റൂട്ടും വിവർത്തനവും വെവ്വേറെ പരിശോധിക്കുക, തുടർന്ന് ping-ന് പകരം യഥാർത്ഥ സേവനം പരിശോധിക്കുക. മൂന്നാമത്, പ്രാദേശിക റൗട്ടറും വിദൂര വിഭവവും ക്ലയന്റിൽ നിന്ന് വേർതിരിച്ചറിയാവുന്നതായി തുടരുന്നുവെന്ന് സ്ഥിരീകരിക്കുക, അതായിരുന്നു യഥാർത്ഥ ലക്ഷ്യം.

ക്ലയന്റിന് വിവർത്തനം ചെയ്യാനാവില്ലെങ്കിൽ, ഗേറ്റ്വേ വശത്തോട് സഹായം ചോദിക്കുക അല്ലെങ്കിൽ പുനർനമ്പർ സ്വീകരിക്കുക. ഒരേ വിലാസത്തിന് കൂടുതൽ റൂട്ടുകൾ ചേർക്കുന്നത് ഒരു രൂപകൽപ്പനയല്ല.