ഒരു IPv4 ലക്ഷ്യസ്ഥാനം OpenVPN ടണലിന് പുറത്തേക്ക് അയയ്ക്കുന്നതെങ്ങനെ

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

വരി നിരുപദ്രവകരമായി തോന്നുന്നു, പലപ്പോഴും അങ്ങനെയാണ്, എന്നാൽ അത് ഒരു ചോദ്യം മാത്രം തീർപ്പാക്കുന്നു: ആ കൃത്യമായ IPv4 വിലാസത്തിലേക്കുള്ള പാക്കറ്റുകൾ എവിടേക്ക് പോകുന്നു. അത് DNS, IPv6, ഫയർവാൾ നയം, ഏത് പ്രോസസ് ആണ് കണക്ഷൻ തുറന്നത് എന്നിവയൊന്നും മാറ്റുന്നില്ല, ഇവയിൽ ഓരോന്നും ഒഴിവാക്കലിനെ നിശബ്ദമായി അസാധുവാക്കാം.

net_gateway യഥാർത്ഥത്തിൽ എന്താണ് സൂചിപ്പിക്കുന്നത്

ആ ഒഴിവാക്കലിനുള്ള പ്രൊഫൈൽ എൻട്രി ഒരു വരിയാണ്: route 198.51.100.77 255.255.255.255 net_gateway. ആദ്യ വിലാസം ലക്ഷ്യസ്ഥാനത്തിനുള്ള ഡോക്യുമെന്റേഷൻ പ്ലേസ്ഹോൾഡറാണ്, മാസ്ക് അതിനെ ഒരു ഹോസ്റ്റ് റൂട്ടാക്കുന്നു, അവസാന ടോക്കൺ ഗേറ്റ്വേ പ്ലേസ്ഹോൾഡറിനെ സൂചിപ്പിക്കുന്നു. OpenVPN റൂട്ടുകൾ ഇൻസ്റ്റാൾ ചെയ്യുമ്പോൾ ഗേറ്റ്വേ പ്ലേസ്ഹോൾഡറുകൾ പരിഹരിക്കുന്നു. vpn_gateway എന്നാൽ ടണലിന്റെ സ്വന്തം ഗേറ്റ്വേ, അതായത് VPN ലിങ്കിന്റെ അകലെയുള്ള വശം. net_gateway എന്നാൽ VPN എന്തെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് ഹോസ്റ്റിനുണ്ടായിരുന്ന ഡിഫോൾട്ട് ഗേറ്റ്വേ, അത് സാധാരണയായി ഭൗതിക നെറ്റ്വർക്കിലെ ലോക്കൽ റൂട്ടർ ആണ്.

മൂന്നാമത്തെ പ്ലേസ്ഹോൾഡർ, remote_host, VPN സെർവറിന്റെ വിലാസത്തെ സൂചിപ്പിക്കുന്നു, ടണലിന് ഭൗതിക പാതയിലൂടെ സെർവറിൽ എത്താൻ അത് നിലകൊള്ളുന്നു. ഈ മൂന്നെണ്ണം കൂട്ടിക്കലർത്തുന്നതാണ് ഒഴിവാക്കൽ തെറ്റായ സ്ഥലത്ത് എത്താനോ ഒട്ടും ഇൻസ്റ്റാൾ ചെയ്യപ്പെടാതിരിക്കാനോ ഉള്ള ഏറ്റവും സാധാരണ കാരണം.

മൂല്യം കണക്റ്റ് ചെയ്യുമ്പോൾ വായിക്കുന്നു, ഫയലിൽ എഴുതുന്നില്ല. യന്ത്രം മറ്റൊരു നെറ്റ്വർക്കിലേക്ക് മാറുകയാണെങ്കിൽ, VPN-ന് മുമ്പുള്ള ഗേറ്റ്വേ മാറുന്നു, റൂട്ട് പുതിയതിനെ പിന്തുടരുന്നു. സാധാരണയായി അതാണ് നിങ്ങൾ ആഗ്രഹിക്കുന്നത്, എന്നാൽ ഒഴിവാക്കലിന്റെ സ്വഭാവം ക്ലൈന്റ് തുടങ്ങിയ നെറ്റ്വർക്കിനെ ആശ്രയിച്ചിരിക്കുന്നു എന്നും ഇതിനർത്ഥമുണ്ട്.

ഹോസ്റ്റ് റൂട്ട് ടണലിന്റെ ഡിഫോൾട്ടിനെ എന്തുകൊണ്ട് തോൽപ്പിക്കുന്നു

റൂട്ടിംഗ് ഏറ്റവും നിർദ്ദിഷ്ടമായ പൊരുത്തപ്പെടുന്ന പ്രിഫിക്സാണ് തീരുമാനിക്കുന്നത്. redirect-gateway def1 സാധാരണയായി ഡിഫോൾട്ട് റൂട്ടിനെ മാറ്റിസ്ഥാപിക്കുന്നില്ല; അത് രണ്ട് പകുതികൾ ചേർക്കുന്നു, വിലാസ ഇടത്തിന്റെ താഴത്തെ പകുതിക്ക് ഒരു റൂട്ടും മുകളിലെ പകുതിക്ക് ഒന്നും, അതിനാൽ യഥാർത്ഥ ഡിഫോൾട്ട് റൂട്ട് മറ്റ് ഉപയോഗങ്ങൾക്കായി സൂക്ഷിക്കപ്പെടുന്നു. ആ പകുതികൾ ഒരു വിലാസത്തേക്കാൾ വീതിയുള്ളതാണ്.

255.255.255.255 മാസ്കുള്ള ഒരു വിലാസത്തിന്റെ റൂട്ട് /32 ആണ്, IPv4-ന് ലഭിക്കാവുന്ന ഏറ്റവും ഉയർന്ന നിർദ്ദിഷ്ടത. ആ വിലാസത്തിനുള്ള പാക്കറ്റ് വിലയിരുത്തുമ്പോൾ /32 പൊരുത്തപ്പെടുന്നു, ഏത് റൂട്ട് ആണ് ആദ്യം ഇൻസ്റ്റാൾ ചെയ്തത് എന്നത് പരിഗണിക്കാതെ വിജയിക്കുന്നു. ഇതാണ് ഒഴിവാക്കലിന്റെ പിന്നിലെ സംവിധാനം, റൂട്ട് യഥാർത്ഥത്തിൽ ഉണ്ടെങ്കിൽ Linux, macOS, Windows എന്നിവയിൽ ഇത് ഒരുപോലെ പ്രവർത്തിക്കുന്നു.

Windows രണ്ടാമത്തെ അളവ് ചേർക്കുന്നു. രണ്ട് റൂട്ടുകൾ ഒരുപോലെ നിർദ്ദിഷ്ടമാകുമ്പോൾ കുറഞ്ഞ മെട്രിക് ഉള്ളത് വിജയിക്കുന്നു, VPN അഡാപ്റ്റർക്ക് ഫലം മാറ്റുന്ന ഇന്റർഫേസ് മെട്രിക് ഉണ്ടാകാം. /32 ഇപ്പോഴും പകുതികളേക്കാൾ നിർദ്ദിഷ്ടമാണ്, അതിനാൽ ഒഴിവാക്കൽ സാധാരണയായി നിലനിൽക്കുന്നു, എന്നാൽ മുൻ സെഷനിൽ നിന്നുള്ള പഴയ റൂട്ട് ഒരുപോലെ നിർദ്ദിഷ്ടമാണെങ്കിൽ ആശയക്കുഴപ്പമുള്ള ഫലം നൽകാം.

ഒഴിവാക്കൽ ഉൾക്കൊള്ളാത്തത്

DNS ആണ് ആദ്യ വിടവ്. ക്ലൈന്റിന് ആന്തരിക റിസോൾവർ ക്രമീകരണങ്ങൾ തള്ളാം, ഓപ്പറേറ്റിംഗ് സിസ്റ്റം അവ ലുക്കപ്പുകൾക്ക് ഉപയോഗിക്കുന്നത് തുടരും. കണക്റ്റ് ചെയ്യുന്നതിന് മുമ്പ് പേര് പരിഹരിക്കുന്ന ഒരു അപ്ലിക്കേഷന് നേരിട്ട് പോകേണ്ട ഒരു സേവനത്തിന് ആന്തരിക വിലാസമോ, ശരിയായി പരിഹരിക്കപ്പെടുന്നതും എന്നാൽ പിന്നീട് അടുത്ത വിടവിൽ ഇടറുന്നതുമായ ഒരു ബാഹ്യ വിലാസമോ ലഭിക്കാം.

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

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

സ്വയം വഞ്ചിക്കാതെ ഒഴിവാക്കൽ പരിശോധിക്കുക

ബ്രൗസറിൽ നിന്നല്ല, ഇൻസ്റ്റാൾ ചെയ്ത റൂട്ടിൽ നിന്ന് തുടങ്ങുക. Linux-ൽ നിർദ്ദിഷ്ട വിലാസത്തിന് ഏത് റൂട്ടും അടുത്ത ഹോപ്പും ഉപയോഗിക്കുമെന്ന് കേർണലിനോട് ചോദിക്കുക; Windows-ൽ ആ /32-നുള്ള റൂട്ട് പട്ടിക വായിക്കുക. ഗേറ്റ്വേ ഭൗതികമാണെന്നും ടണലല്ലെന്നും ഉറപ്പാക്കുക. എൻട്രി ഇല്ലെങ്കിൽ, പ്രൊഫൈൽ പ്രയോഗിച്ചിട്ടില്ല അല്ലെങ്കിൽ ക്ലൈന്റിന് റൂട്ടുകൾ മാറ്റാനുള്ള അനുമതി ഉണ്ടായിരുന്നില്ല.

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

അവസാനമായി, റൂട്ടിനെ അതിക്രമിക്കാവുന്ന നിയന്ത്രണങ്ങൾ പരിശോധിക്കുക. ക്ലൈന്റ് വശത്തുള്ള kill switch അല്ലെങ്കിൽ Windows-ന്റെ block-outside-dns ക്രമീകരണം നേരിട്ടുള്ള ട്രാഫിക് വിലക്കാം, അത് റൂട്ട് ശരിയാണെങ്കിലും പരാജയപ്പെടുന്ന കണക്ഷനായി കാണപ്പെടുന്നു. ഒഴിവാക്കൽ പ്രവർത്തിക്കുന്നതായി തോന്നിക്കാൻ ആ നിയന്ത്രണങ്ങൾ പ്രവർത്തനരഹിതമാക്കരുത്; നയം നേരിട്ടുള്ള പാത വിലക്കുന്നുവെങ്കിൽ, ഒഴിവാക്കൽ VPN സേവനത്തിന്റെ ഉടമയ്ക്കുള്ള ഒരു രൂപകൽപ്പന പ്രശ്നമാണ്.

വീണ്ടും കണക്റ്റ് ചെയ്യുകയോ നെറ്റ്വർക്ക് മാറ്റുകയോ ചെയ്തതിന് ശേഷം വീണ്ടും പരിശോധിക്കുക, കാരണം VPN-ന് മുമ്പുള്ള ഗേറ്റ്വേയും ലഭ്യമായ പാതയും പ്രൊഫൈലിന്റെയല്ല, നിമിഷത്തിന്റെ സവിശേഷതകളാണ്.