VirtualBox NAT-ന് പിന്നിൽ നിങ്ങളുടെ അതിഥി VPN എന്തുകൊണ്ട് പരാജയപ്പെടുന്നു?

വെർച്വൽ മെഷീനിനുള്ളിലെ ബ്രൗസർ പ്രവർത്തിക്കുന്നു, അതേ അതിഥിയിലെ VPN ക്ലയന്റിന് ഡാറ്റ കൊണ്ടുപോകാൻ കഴിയുന്നില്ല. അതിഥിക്ക് കണക്ടിവിറ്റി വ്യക്തമാണ്, അതിനാൽ തകരാർ VPN-ന്റെ പുറം പ്രോട്ടോക്കോളിന് എന്ത് വേണം, വെർച്വൽ NAT എന്ത് കടത്തിവിടും എന്നതിലാണ്. ഫലം മൂന്ന് വ്യവസ്ഥകൾ തീരുമാനിക്കുന്നു: ഏത് പ്രോസസ് VPN സ്വന്തമാക്കുന്നു, വയറിൽ പുറം കൈമാറ്റം എങ്ങനെ കാണപ്പെടുന്നു, അഡാപ്റ്റർ മോഡ് നിങ്ങൾ കരുതുന്നത് തന്നെയാണോ. നിങ്ങൾക്ക് മാറ്റാൻ കഴിയുന്ന വ്യവസ്ഥയെ പേരിടുന്നതാണ് മുഴുവൻ തീരുമാനം.

നെറ്റ്വർക്കിനെ കുറ്റപ്പെടുത്തുന്നതിന് മുമ്പ് VPN പ്രോസസ് കണ്ടെത്തുക

VPN അതിഥിക്കുള്ളിലാണോ ഹോസ്റ്റിലാണോ പ്രവർത്തിക്കുന്നത് എന്ന് ആദ്യം തീരുമാനിക്കുക, കാരണം രണ്ട് ക്രമീകരണങ്ങളും വ്യത്യസ്തമായി പരാജയപ്പെടുന്നു. അതിഥിക്കുള്ളിലെ ക്ലയന്റ് അതിന്റെ പുറം കണക്ഷൻ അതിഥി അഡാപ്റ്ററിലൂടെയും പിന്നിലുള്ള ഏതെങ്കിലും വിവർത്തനത്തിലൂടെയും നിർമ്മിക്കുന്നു. ഹോസ്റ്റ് VPN ഹോസ്റ്റ്, ഹൈപ്പർവൈസർ നയങ്ങൾ അനുസരിച്ച് അതിഥിയുടെ ട്രാഫിക് പിടിക്കുന്നു, അത് സ്വന്തം നിയമങ്ങളുള്ള വേറിട്ട പിടുത്ത കേന്ദ്രമാണ്. രണ്ടും ഒരുമിച്ച് പ്രവർത്തിച്ച് തെളിവുകൾ കലക്കാം, അതിനാൽ ഏതെങ്കിലും ഒന്നിൽ തൊടുന്നതിന് മുമ്പ് ഈ ട്രാഫിക് ഏത് കൊണ്ടുപോകണം എന്ന് കണ്ടെത്തുക.

എന്തെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് ഇപ്പോൾ അതിഥിയുടെ അഡാപ്റ്റർ മോഡ് എഴുതിവെക്കുക. ആ ഒരു മൂല്യം പിന്നീടുള്ളവയുടെ ഭൂരിഭാഗവും വിശദീകരിക്കുന്നു, പിന്നീട് ആരും ആദ്യം ചോദിക്കുന്നതും അതു തന്നെ.

പുറം കൈമാറ്റം അനുയോജ്യത തീരുമാനിക്കുന്നു

VirtualBox നെറ്റ്വർക്കിംഗ് ഗൈഡ് ഇവിടെ പ്രധാനമായ NAT പരിമിതികൾ പട്ടികപ്പെടുത്തുന്നു: TCP, UDP ഒഴികെയുള്ള പ്രോട്ടോക്കോളുകൾ കടത്തിവിടില്ല, GRE പിന്തുണയില്ലാത്തതായി പേരിട്ടിരിക്കുന്നു, PPTP ബാധിത ഉദാഹരണമായി നൽകിയിരിക്കുന്നു. PPTP നിയന്ത്രണ കൈമാറ്റത്തിന് TCP-യും ഡാറ്റയ്ക്ക് GRE-യും ഉപയോഗിക്കുന്നു, അതിനാൽ നിയന്ത്രണ കണക്ഷൻ വിജയിക്കാം, പക്ഷേ ഡാറ്റ പാത അതേ അതിർത്തി കടക്കാൻ കഴിയില്ല. ഇവ രണ്ട് വ്യത്യസ്ത തെളിവുകളാണ്, അവയിൽ ഒന്ന് മാത്രമാണ് ട്രാഫിക് കൊണ്ടുപോകുന്നതിനെക്കുറിച്ച്. ഫയർവാൾ നിയമത്തിൽ TCP പോർട്ട് 47 അനുവദിക്കുന്നത് IP പ്രോട്ടോക്കോൾ 47 അനുവദിക്കുന്നതിന് തുല്യമല്ല, രണ്ടും നിരന്തരം കലക്കപ്പെടുന്നു.

പരിമിതി NAT എന്ന വാക്ക് ഉപയോഗിക്കുന്ന എല്ലാ ഉപകരണത്തിനും അല്ല, ഈ NAT ക്രമീകരണത്തിന് ബന്ധിപ്പിച്ച് നിർത്തുക. ഭൗതിക റൂട്ടറിന് പരാതിയില്ലാതെ GRE കടത്തിവിടാം, പക്ഷേ വെർച്വൽ NAT അത് വീഴ്ത്തുന്നു, മറ്റൊരു ഹൈപ്പർവൈസർ എന്ത് കൈമാറണം എന്ന് സ്വയം തീരുമാനിക്കുന്നു. സംഘടന TCP അല്ലെങ്കിൽ UDP-യ്ക്കുള്ളിൽ അംഗീകൃത ഗതാഗതം നൽകുന്നിടത്ത്, ആ പാതയ്ക്ക് അതിന്റെ പിന്തുണയുള്ള ക്ലയന്റും പ്രൊഫൈലും ഉപയോഗിക്കുക. അനുയോജ്യത പല ആവശ്യങ്ങളിൽ ഒന്നാണ്, അത് സെർവർ വിശ്വാസമോ അക്കൗണ്ട് അനുമതിയോ പ്രവർത്തിക്കുന്ന സ്വകാര്യ പാതകളോ സ്ഥാപിക്കുന്നില്ല.

ബ്രിഡ്ജ് യഥാർത്ഥത്തിൽ എന്ത് മാറ്റുന്നു

ബ്രിഡ്ജ് അതിഥിയുടെ MAC വിലാസം വിവർത്തനത്തിന് പിന്നിൽ ഒളിപ്പിക്കുന്നതിന് പകരം ഭൗതിക സെഗ്മെന്റിന് നൽകുന്നു. പിന്നീട് അതിഥി ആ സെഗ്മെന്റിന് സേവനം നൽകുന്ന ഏത് DHCP സെർവറിൽ നിന്നും വിലാസം എടുക്കുന്നു, ആ വിലാസത്തിന് ARP മറുപടി നൽകുന്നു, മുകളിലെ സ്വിച്ചിന് മറ്റൊരു പോർട്ടായി കാണപ്പെടുന്നു. അത് വെർച്വൽ വിവർത്തന പാത നീക്കം ചെയ്യുന്നു, പഴയ പാചകക്കുറിപ്പ് അത് ശുപാർശ ചെയ്യാനുള്ള കാരണം അതു തന്നെ, അതേ നിമിഷം മറ്റ് മൂന്ന് കാര്യങ്ങളും മാറ്റുന്നു. വിലാസനിർണ്ണയം ഇപ്പോൾ ഹൈപ്പർവൈസറിൽ നിന്നല്ല, പ്രാദേശിക സെഗ്മെന്റിൽ നിന്നാണ് വരുന്നത്, എക്സ്പോഷർ എന്നാൽ അതിഥി ആ സെഗ്മെന്റിന് ദൃശ്യമാണ്, പ്രവേശനം സ്വിച്ച് പോർട്ടും അതിന്റെ നയവും അനുസരിച്ചിരിക്കുന്നു. ഇവയിൽ ഓരോന്നും മാറ്റം നിരസിക്കാനുള്ള കാരണമാകാം, ഒന്നും VPN പ്രോട്ടോക്കോളിനെക്കുറിച്ചല്ല.

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

രണ്ട് ടണലുകൾ, രണ്ട് തെളിവ് പാതകൾ

ഏതെങ്കിലും ആന്തരിക വിലാസമോ സ്വകാര്യ പാതയോ പ്രധാനമാകുന്നതിന് മുമ്പ് അതിഥി VPN-ന് അതിഥി ഇന്റർഫേസിൽ നിന്ന് അതിന്റെ ജോടിയിലേക്ക് ഉപയോഗയോഗ്യമായ പാത വേണം. ഹോസ്റ്റ് VPN ഉണ്ടെങ്കിൽ, അത് സ്വന്തം നയപ്രകാരം ആ പുറം കൈമാറ്റം റിലേ ചെയ്യാം അല്ലെങ്കിൽ തടയാം, അതിഥിയുടെ ആന്തരിക ടണൽ പുറം വിജയിച്ചതിന് ശേഷം മാത്രമേ തുടങ്ങൂ. ഒരു പാളിയുടെയും പരിധി ഒരു ബന്ധിപ്പിച്ച ഐക്കണിൽ നിന്നോ ഹോസ്റ്റ് ബ്രൗസറിന്റെ പൊതു വിലാസത്തിൽ നിന്നോ വായിക്കാനാകില്ല.

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

ഏത് വ്യവസ്ഥയാണ് യഥാർത്ഥത്തിൽ തടയുന്നത്

ഇപ്പോൾ തീരുമാനം വ്യത്യസ്ത ഉത്തരങ്ങളുള്ള മൂന്ന് ചോദ്യങ്ങളായി ചുരുങ്ങുന്നു. പുറം പ്രോട്ടോക്കോൾ TCP, UDP-യ്ക്ക് പുറത്താണെങ്കിൽ, NAT മോഡാണ് പരിമിതി, മുന്നോട്ടുള്ള വഴി ബ്രിഡ്ജിംഗോ അംഗീകൃത TCP/UDP ഗതാഗതമോ ആണ്. പുറം കൈമാറ്റം പൂർത്തിയാകുകയും ഡാറ്റ പാത അല്ലാതിരിക്കുകയും ചെയ്താൽ, രണ്ടാം തെളിവിൽ കണ്ട അതേ പരിമിതിയാണ്. ടണൽ ഉയരുകയും വിഭവങ്ങൾ മറുപടി നൽകാതിരിക്കുകയും ചെയ്താൽ, പ്രശ്നം ഇതിനകം ഹൈപ്പർവൈസർ കടന്ന് റൂട്ടിംഗിലോ നയത്തിലോ എത്തിയിരിക്കുന്നു.

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