നിങ്ങളുടെ VM ഹോസ്റ്റിന്റെ VPN ഉപയോഗിക്കുന്നുണ്ടോ? ഗസ്റ്റിനുള്ളിൽ നിന്ന് പരിശോധിക്കുക

ഹോസ്റ്റിന്റെ പൊതു IP പരിശോധിക്കുന്നു, അത് VPN കാണിക്കുന്നു, അപ്പോൾ VM സംരക്ഷിതമാണെന്ന് നിഗമനം ചെയ്യുന്നു. ആ നിഗമനത്തെ ഈ പരിശോധന പിന്തുണയ്ക്കുന്നില്ല. ഗസ്റ്റിന് അതിന്റേതായ റൂട്ടിംഗ് ടേബിളും അതിന്റേതായ റിസോൾവറും അതിന്റേതായ ഇന്റർഫേസുകളും ഉണ്ട്, ഹോസ്റ്റിന്റെ എക്സിറ്റ് വിലാസം അവയെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല.

പരിശോധന ഗസ്റ്റിനുള്ളിൽ നടക്കണം, എന്താണ് അളന്നതെന്ന് അത് പറയണം.

ഹോസ്റ്റിന്റെ ബ്രൗസറിലല്ല, ഗസ്റ്റിനുള്ളിൽ നിന്ന് തുടങ്ങുക

ആദ്യം ഹൈപ്പർവൈസറിന്റെ നെറ്റ്വർക്ക് മോഡ് രേഖപ്പെടുത്തുക: NAT, bridged, host-only അല്ലെങ്കിൽ macvtap. NAT മോഡിൽ ഹോസ്റ്റ് ഗസ്റ്റിന്റെ ട്രാഫിക് റൂട്ട് ചെയ്യുന്നു, അതിനാൽ ക്ലയന്റ് റൂട്ടുകൾ എങ്ങനെ ഇൻസ്റ്റാൾ ചെയ്യുന്നു എന്നതിന് അനുസരിച്ച് ഹോസ്റ്റിന്റെ ടണൽ ബാധകമാകാം, ആകണമെന്നില്ല. Bridged മോഡിൽ ഗസ്റ്റ് ഫിസിക്കൽ LAN-ലെ സമനിലയിലുള്ള ഒരു കക്ഷിയാണ്, ഹോസ്റ്റിന്റെ ടണൽ പ്രസക്തമല്ല. ഈ രണ്ട് മോഡുകളും ഒരേ ഹോസ്റ്റ് കോൺഫിഗറേഷനിൽ നിന്ന് വിപരീത ഉത്തരങ്ങൾ നൽകുന്നു.

എന്തെങ്കിലും മാറ്റുന്നതിന് മുൻപ് മോഡ് എഴുതി വയ്ക്കുക, കാരണം ഫലത്തിന് എന്തർത്ഥമാകാം എന്നത് അതാണ് നിർണ്ണയിക്കുന്നത്.

ലക്ഷ്യസ്ഥാനം അറിയാവുന്ന ഒരു അഭ്യർത്ഥന നടത്തുക

താൻ കണ്ട സ്രോതസ്സ് വിലാസം റിപ്പോർട്ട് ചെയ്യുന്ന ഒരു സേവനത്തിലേക്ക് നിരുപദ്രവകരമായ അഭ്യർത്ഥന അയയ്ക്കുക. തുടർന്ന് ആ ലക്ഷ്യസ്ഥാനത്തിനുള്ള ഗസ്റ്റിന്റെ സ്വന്തം റൂട്ടിംഗ് തീരുമാനം പരിശോധിക്കുക: ip route get 203.0.113.5 ഗസ്റ്റ് ഉപയോഗിക്കുന്ന ഇന്റർഫേസും ഗേറ്റ്വേയും പ്രിന്റ് ചെയ്യുന്നു.

ഇന്റർഫേസ് ഗസ്റ്റിന്റെ സാധാരണ NIC ആണെങ്കിൽ, ആ ട്രാഫിക് ഗസ്റ്റിനുള്ളിലെ ടണലിലൂടെ പോകുന്നില്ല.

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

റിസോൾവർ വേർതിരിച്ച് പരിശോധിക്കുക

മാറിയ എക്സിറ്റ് വിലാസം ആ ഹോസ്റ്റ് നാമം ഏത് റിസോൾവർ കൈകാര്യം ചെയ്തു എന്ന് പറയുന്നില്ല. പ്ലാറ്റ്ഫോമിന് അനുയോജ്യമായ ടൂൾ ഉപയോഗിച്ച് നാമം വ്യക്തമായി ചോദിക്കുക, ഏത് സെർവർ ഉത്തരം നൽകി എന്ന് രേഖപ്പെടുത്തുക. Split DNS എന്നാൽ റിസോൾവർ ചോദ്യത്തിനും റൂട്ടിംഗ് ചോദ്യത്തിനും വ്യത്യസ്ത ഉത്തരങ്ങളുണ്ട് എന്നാണ്.

അവ രണ്ടും ഏത് ദിശയിലും വ്യതിചലിക്കാം, ആ വ്യതിചലനമാണ് പലപ്പോഴും യഥാർത്ഥ ബഗ്.

systemd ഹോസ്റ്റിൽ, resolvectl query ഉത്തരത്തിന് പിന്നിലെ ഇന്റർഫേസും DNS സെർവറും പേര് പറയുന്നു. പഴയ ക്രമീകരണങ്ങൾ സെർവർ dig ഔട്ട്പുട്ടിൽ കാണിക്കുന്നു. ഏതായാലും ഉത്തരം വന്നോ എന്നതല്ല, ഏത് സെർവർ ഉത്തരം നൽകി എന്നതാണ് കാണേണ്ടത്.

വിജയം മാത്രമല്ല, പരാജയ നയവും പരീക്ഷിക്കുക

ടണലിന് പുറത്തേക്ക് ഒരു ട്രാഫിക്കും പോകരുതെന്നാണ് ആവശ്യമെങ്കിൽ, വിജയകരമായ അഭ്യർത്ഥന ഒന്നും തെളിയിക്കുന്നില്ല. ക്ലയന്റ് പിന്തുണയ്ക്കുന്ന നിയന്ത്രിത പരാജയ പരിശോധന ഉപയോഗിക്കുക: പിന്തുണയ്ക്കുന്ന രീതിയിൽ ടണൽ നിർത്തി, പുതിയ ഗസ്റ്റ് അഭ്യർത്ഥന തടയപ്പെടുന്നുണ്ടോ എന്ന് നോക്കുക. ഹോസ്റ്റ് ക്ലയന്റിന്റെ kill switch എല്ലാ വെർച്വൽ ഫോർവേഡിംഗ് ക്രമീകരണങ്ങളെയും ഉൾക്കൊള്ളുന്നു എന്ന് കരുതരുത്. അതിന്റെ രേഖപ്പെടുത്തിയ പരിധി മാത്രമാണ് നിങ്ങൾക്ക് ആശ്രയിക്കാവുന്നത്.

ടണൽ വീഴുമ്പോൾ ഫിസിക്കൽ NIC-ലേക്ക് മടങ്ങുന്ന ഗസ്റ്റ് NAT മോഡ് അനുവദിക്കുന്നത് കൃത്യമായി ചെയ്യുന്നു.

മോഡും പരിധിയും രേഖപ്പെടുത്തുക

ഹൈപ്പർവൈസർ മോഡ്, ഗസ്റ്റിന്റെ ഇന്റർഫേസും റൂട്ടും, റിസോൾവർ, നിങ്ങൾ പരീക്ഷിച്ച ആപ്ലിക്കേഷൻ എന്നിവ എഴുതുക. തീയതി കൂടി ചേർക്കുക, കാരണം സ്നാപ്പ്ഷോട്ട് പുനഃസ്ഥാപിക്കലോ ഹൈപ്പർവൈസർ അപ്ഡേറ്റോ നാലും മാറ്റാം.

IPv4 ടണലിനെ പിന്തുടർന്നെങ്കിൽ അത് പറയുക. ഈ അവകാശവാദം IPv6, മറ്റൊരു namespace അല്ലെങ്കിൽ മറ്റൊരു നെറ്റ്വർക്കിലെ മറ്റൊരു VM-ലേക്ക് വ്യാപിപ്പിക്കരുത്.