VPN ഹോസ്റ്റിൽ ഓടിക്കണോ VM-നുള്ളിൽ ഓടിക്കണോ? തീരുമാന മാർഗ്ഗദർശി

അതിഥിയുടെ ഉള്ളിൽ ടണൽ നിർമ്മിക്കുന്നതും അത് ഹോസ്റ്റിൽ നിർമ്മിക്കുന്നതും ബ്രൗസർ റിപ്പോർട്ട് ചെയ്യുന്ന വിലാസം മാറ്റുന്നു, സാമ്യം അവിടെ അവസാനിക്കുന്നു. അതിഥിയുടെ ഉടമസ്ഥതയിലുള്ള ടണൽ അതിന്റെ കീകളും സ്വതേയുള്ള റൂട്ടും റിസോൾവറും അതിഥിയുടെ കേർണലിനുള്ളിൽ സൂക്ഷിക്കുന്നു, ഹോസ്റ്റ് എൻക്രിപ്റ്റ് ചെയ്ത പാക്കറ്റുകൾ ഒരു ദൂര വിലാസത്തിലേക്ക് കൈമാറുന്നു. ഹോസ്റ്റിന്റെ ഉടമസ്ഥതയിലുള്ള ടണൽ അതിന്റെ കണ്ണാടി ചിത്രമാണ്: ഹോസ്റ്റ് ക്ലയന്റ് സെഷൻ സൂക്ഷിക്കുകയും റൂട്ടുകളും നയവും പ്രയോഗിക്കുകയും ചെയ്യുന്നു, അതിഥി പുറത്തുവരുന്നത് കടം വാങ്ങുന്നു. തെറ്റായ ഉടമയെ തിരഞ്ഞെടുത്താൽ തുടർന്നുള്ള എല്ലാ ലക്ഷണങ്ങളും നിങ്ങളെ തെറ്റായ യന്ത്രത്തിലേക്ക് അയയ്ക്കും. രണ്ട് കമാൻഡുകൾ ഈ ചോദ്യം ഏകദേശം ഒരു മിനിറ്റിൽ തീർപ്പാക്കുന്നു, ഈ മാർഗ്ഗദർശിയുടെ ബാക്കി ഉത്തരവുമായി എന്ത് ചെയ്യണം എന്നതാണ്.

ക്ലയന്റ് തൊടുന്നതിന് മുമ്പ് ഉടമയെ തീരുമാനിക്കുക

നിയമം സൈഫർടെക്സ്റ്റ് എവിടെ ഉത്പാദിപ്പിക്കുന്നു എന്നതിനെക്കുറിച്ചാണ്, ഏത് യന്ത്രം VPN ഐക്കൺ കാണിക്കുന്നു എന്നതിനെക്കുറിച്ചല്ല. അതിഥി അത് ഉത്പാദിപ്പിക്കുന്നെങ്കിൽ, അതിഥിക്ക് VPN സെർവറിലേക്ക് പ്രവർത്തിക്കുന്ന ഒരു റൂട്ട് ആവശ്യമാണ്, ഹോസ്റ്റിൽ നിന്ന് മറ്റൊന്നും വേണ്ട. ഹോസ്റ്റ് അത് ഉത്പാദിപ്പിക്കുന്നെങ്കിൽ, ഹോസ്റ്റ് ക്ലയന്റ് പ്രാദേശിക ട്രാഫിക്കിൽ അടിച്ചേൽപ്പിക്കുന്ന ഏത് നയത്തെയും അതിജീവിക്കണം അതിഥിയുടെ ഹോസ്റ്റ്-പാതയ്ക്ക്.

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

ഉത്തരം VM നാമത്തിന് അടുത്ത് ഒരു വരിയിൽ എഴുതുക: guest-owned അല്ലെങ്കിൽ host-owned. ആറ് യന്ത്രങ്ങളുള്ള ലാബിൽ ഈ കുറിപ്പ് താഴെയുള്ള ഏത് ഘട്ടത്തേക്കാളും സമയം ലാഭിക്കുന്നു, കാരണം നിങ്ങൾ ലോഗിൻ ചെയ്ത യന്ത്രത്തിൽ ഒരിക്കലും ഇല്ലാതിരുന്ന ഒരു ടണലിനെ പരിശോധിക്കുന്നതിൽ നിന്ന് ഇത് തടയുന്നു.

WSL1-ഉം WSL2-ഉം വിപരീത കേസുകളാണ്

WSL1 ഒരു വെർച്വൽ മെഷീൻ അല്ല, അതിനാൽ സ്ഥാനത്തെക്കുറിച്ചുള്ള ചോദ്യം കൂടുതലും ബാഷ്പീകരിക്കുന്നു. അതിന്റെ Linux ബൈനറികൾ ഒരു വിവർത്തന പാളിയിലൂടെ Windows-ന്റെ നെറ്റ്വർക്ക് സ്റ്റാക്കിനെതിരെ പ്രവർത്തിക്കുന്നു, Linux VPN ക്ലയന്റിന് ക്രമീകരിക്കാൻ സ്വതന്ത്ര ഇന്റർഫേസുകളില്ല. പ്രവർത്തിക്കുന്ന ക്രമീകരണം Windows വശത്തെ ടണലാണ്, വിതരണം ഒന്നും ഉടമസ്ഥതയില്ലാതെ ഫലം ഉപയോഗിക്കുന്നു.

WSL2 ഇതിന് വിപരീതമാണ്. Hyper-V വെർച്വൽ സ്വിച്ചിന് പിന്നിലെ ഭാരം കുറഞ്ഞ യൂട്ടിലിറ്റി VM-ൽ ഇത് യഥാർത്ഥ കേർണൽ പ്രവർത്തിപ്പിക്കുന്നു, അതിന്റെ വിലാസ സ്ഥലം ഹോസ്റ്റ് വശത്തെ അഡാപ്റ്റർ വഴി NAT ചെയ്യുന്നു. അതിനാൽ വിതരണത്തിനുള്ളിലെ Linux ക്ലയന്റ് ഭൗതിക Linux ബോക്സിലെന്നപോലെ പ്രവർത്തിക്കുന്നു: ഇത് tun0 അല്ലെങ്കിൽ wg0 സൃഷ്ടിച്ച് സ്വന്തം റൂട്ടുകൾ ഇൻസ്റ്റാൾ ചെയ്ത് പ്രവർത്തിക്കുന്നു. പരാജയം ഹോസ്റ്റ് വശത്താണ് കഴിയുന്നത്. Windows VPN ക്ലയന്റ് പ്രാദേശിക നെറ്റ്വർക്കുകളിലെ ട്രാഫിക് തടയുന്ന ഒരു നയത്തോടെ ബന്ധിപ്പിക്കുമ്പോൾ, WSL2 സബ്നെറ്റിനെ വിശ്വസനീയമല്ലാത്ത പ്രാദേശിക നെറ്റ്വർക്കായി കണക്കാക്കി NAT പാത മുറിക്കുന്നു. അപ്പോൾ വിതരണത്തിന് DNS-ഉം പുറത്തേക്കുള്ള പ്രവേശനവും നഷ്ടമാകുന്നു, അതിന്റെ സ്വന്തം ടണൽ ഇപ്പോഴും ആരോഗ്യകരമായിരിക്കെ: wg show ഹാൻഡ്ഷേക്ക് റിപ്പോർട്ട് ചെയ്യുന്നു, ip route ശരിയായി തോന്നുന്നു, curl തൂങ്ങിക്കിടക്കുന്നു.

ഏത് പരിഹാരം ഉപയോഗിക്കാം എന്നത് Windows ബിൽഡിനെ ആശ്രയിച്ചിരിക്കുന്നു. പഴയത് WSL സബ്നെറ്റിനായുള്ള ഹോസ്റ്റ് ക്ലയന്റിലെ ഒരു ഒഴിവാക്കലാണ്, ക്ലയന്റിന്റെ പ്രാദേശിക-നെറ്റ്വർക്ക് അല്ലെങ്കിൽ വിഭജിത-ടണൽ ക്രമീകരണങ്ങൾക്ക് കീഴിൽ ചേർക്കുന്നു. പുതിയത്, ഇതിനെ പിന്തുണയ്ക്കുന്ന Windows 11 ബിൽഡുകളിൽ, കണ്ണാടി നെറ്റ്വർക്കിംഗ് ആണ്: %UserProfile%\.wslconfig-ന്റെ [wsl2] വിഭാഗത്തിൽ networkingMode=mirrored ഇടുക, wsl --shutdown പ്രവർത്തിപ്പിക്കുക, വിതരണം സ്വകാര്യ NAT സബ്നെറ്റിന് പകരം ഹോസ്റ്റിന്റെ ഇന്റർഫേസുകൾ പങ്കിടും. കണ്ണാടി മോഡ് localhost-ന്റെയും ഇൻബൗണ്ട് പോർട്ടുകളുടെയും പെരുമാറ്റവും മാറ്റുന്നു, അതിനാൽ അതിനെ ടോഗിൾ അല്ല, മൈഗ്രേഷൻ ആയി കാണുക.

NAT, ബ്രിഡ്ജ്, ഹോസ്റ്റിന് എന്ത് കാണാം

NAT-ന് കീഴിൽ അതിഥിയുടെ ടണൽ പാക്കറ്റുകൾ VPN സെർവറിന്റെ പൊതു വിലാസത്തിലേക്ക് അഡ്രസ് ചെയ്ത് എൻക്രിപ്റ്റ് ചെയ്ത UDP അല്ലെങ്കിൽ TCP ആയി ഹോസ്റ്റ് അഡാപ്റ്റർ വഴി പുറത്തുപോകുന്നു. ഹോസ്റ്റ് ഒരു ഫ്ലോയും അതിന്റെ ബൈറ്റ് എണ്ണവും കാണുന്നു, അതിനുള്ളിലെ ലക്ഷ്യസ്ഥാനങ്ങളെക്കുറിച്ച് ഒന്നുമില്ല. ബ്രിഡ്ജ് അഡാപ്റ്ററിന് കീഴിൽ ഭൗതിക LAN-ൽ അതിഥിക്ക് സ്വന്തം 2-ാം പാളി ഐഡന്റിറ്റിയുണ്ട്, സ്വന്തം DHCP ലീസ് എടുക്കുന്നു, MAC അടിസ്ഥാനമാക്കിയ ഏത് നയത്തിനും രണ്ടാമത്തെ ഉപകരണമായി കാണപ്പെടുന്നു. ഒരു മോഡും ഹോസ്റ്റിനെ ടണലിന്റെ പേലോഡ് വായിക്കാൻ അനുവദിക്കുന്നില്ല; ബ്രിഡ്ജ് ചെയ്ത അതിഥി അതിന് ചുറ്റുമുള്ള നെറ്റ്വർക്കിന് കൂടുതൽ ദൃശ്യമാണ് എന്ന് മാത്രം.

വേർതിരിക്കലിനും ഒരു താഴ്ന്ന പരിധിയുണ്ട്. അതിഥിയുടെ മെമ്മറി ഉടമസ്ഥതയിലുള്ള യന്ത്രത്തിൽ നിന്ന് അതിന് ഒളിക്കാനാവില്ല, ഹോസ്റ്റ് നിയന്ത്രിക്കുന്ന ആർക്കും അതിഥിയുടെ RAM-ൽ നിന്ന് കീകൾ വായിക്കാം. അതിഥിയിലെ ടണൽ നൽകുന്നത് റൂട്ടിംഗ് അതിരും മാൽവെയർ അതിരുമാണ്, ലാപ്ടോപ്പ് പിടിക്കുന്ന വ്യക്തിയിൽ നിന്നുള്ള സംരക്ഷണമല്ല. രേഖപ്പെടുത്തിയ അഡാപ്റ്റർ മോഡുകൾ തിരഞ്ഞെടുക്കുമ്പോൾ തുറന്ന് വയ്ക്കുന്നത് നല്ലതാണ്, കാരണം മോഡ് ഹോസ്റ്റ് കാണുന്നതും LAN കാണുന്നതും രണ്ടും മാറ്റുന്നു.

മാർഗ്ഗദർശി: സ്ഥാപിക്കുക, ക്രമീകരിക്കുക, തെളിയിക്കുക

ഈ നാല് പരിശോധനകൾ ക്രമത്തിൽ ഒരു പുതിയ അതിഥി ഷെല്ലിൽ പ്രവർത്തിപ്പിച്ച്, നിങ്ങൾ എഴുതിയ ഉടമയുമായി പൊരുത്തപ്പെടാത്ത ആദ്യത്തേതിൽ നിർത്തുക.

1. ip route get 1.1.1.1 tun0 അല്ലെങ്കിൽ wg0 തിരികെ നൽകിയാൽ അതിഥി-ഉടമസ്ഥത, സ്വകാര്യ അടുത്ത ഹോപ്പോടെയുള്ള eth0 നൽകിയാൽ ഹോസ്റ്റ്-ഉടമസ്ഥത.
2. resolvectl query example.com, അല്ലെങ്കിൽ അതിഥി റിസോൾവർ സേവനം പ്രവർത്തിപ്പിക്കാത്തിടത്ത് /etc/resolv.conf വായിക്കുക. ട്രാഫിക് കൊണ്ടുപോകുന്നുവെങ്കിലും DNS അല്ലാത്ത ടണൽ ഏറ്റവും സാധാരണമായ പകുതി-ക്രമീകരിച്ച അവസ്ഥയാണ്.
3. എക്സിറ്റുകൾ താരതമ്യം ചെയ്യുക: അതിഥിയിൽ curl -4 -s https://ifconfig.me, ഹോസ്റ്റിൽ curl.exe -4 -s https://ifconfig.me. വ്യത്യസ്ത വിലാസങ്ങൾ എന്നാൽ അതിഥിയാണ് ടണലിന്റെ ഉടമ, VPN-ലുള്ള ഹോസ്റ്റും വീട്ടിലെ ISP കാണിക്കുന്ന അതിഥിയും ചേരുന്നത് ഒന്നും പാരമ്പര്യമായി കിട്ടാത്ത സന്ദർഭമാണ്.
4. രണ്ടും -6 ഉപയോഗിച്ച് ആവർത്തിക്കുക. v4 മാത്രമുള്ള ടണൽ v6 ചോരുന്നു, ക്ലയന്റ് അത് തടയുകയോ റൂട്ട് ചെയ്യുകയോ ചെയ്യുന്നില്ലെങ്കിൽ, പല ക്ലയന്റുകളും സ്വതേ v6 ഭൗതിക ഇന്റർഫേസിൽ വിടുന്നു.

നിരവധി അതിഥികൾ ഒരു ടണൽ പങ്കിടുന്ന ഹോസ്റ്റ്-ഗേറ്റ്‌വേ രൂപകൽപ്പനയിൽ ഹോസ്റ്റ് ഫോർവേഡ് ചെയ്ത് വിവർത്തനം ചെയ്യണം. Linux ഹോസ്റ്റിൽ അത് മൂന്ന് കഷണങ്ങളാണ്, അവയിലൊന്ന് ഇല്ലെങ്കിൽ അതിഥി നിശബ്ദമായി അതിന്റെ സാധാരണ റൂട്ടിലേക്ക് മടങ്ങുന്നു:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE
iptables -A FORWARD -i virbr0 -o wg0 -j ACCEPT
iptables -A FORWARD -i wg0 -o virbr0 -m state --state RELATED,ESTABLISHED -j ACCEPT

WireGuard വശത്ത് ഹോസ്റ്റ് പിയറിന്റെ AllowedIPs-ൽ അതിഥികളുടെ സബ്നെറ്റ് ഉൾപ്പെടണം, ഉദാഹരണത്തിന് 192.168.122.0/24, അല്ലെങ്കിൽ മടങ്ങിവരുന്ന പാക്കറ്റുകൾ ഒരിക്കലും എത്തില്ല, ക്രമീകരണം ഫയർവാൾ പ്രശ്നമായി തോന്നും. Windows ഹോസ്റ്റ് Internet Connection Sharing അല്ലെങ്കിൽ Hyper-V സ്വിച്ചിലെ NAT നിയമം വഴി അതേ ഫലം നേടുന്നു, അതേ മടക്കപ്പാത പരിശോധന ആവശ്യമാണ്.

രൂപകൽപ്പന ഇപ്പോഴും തുറന്നിരിക്കുമ്പോൾ, ഈ പട്ടിക ഏറ്റവും സാധാരണ ക്രമീകരണങ്ങൾ ഉൾക്കൊള്ളുന്നു:

രണ്ട് ടണലുകൾ, രണ്ട് അതിഥികൾ, അവയ്ക്കിടയിലുള്ള കൂട്ടിയിടികൾ

ഒരേ സമയം രണ്ട് എക്സിറ്റുകൾ വേണ്ടിവരുമ്പോൾ നിലനിൽക്കുന്ന മാതൃക ഓരോ അതിഥിക്കും ഒരു ടണലാണ്. ഓരോ VM-ഉം സ്വന്തം സ്വതേയുള്ള റൂട്ടും റിസോൾവറും സൂക്ഷിക്കുന്നു, ഹോസ്റ്റ് സാധാരണ നെറ്റ്വർക്കിൽ തുടരുന്നു, രണ്ട് ടണലുകളും ഒരേ റൂട്ടിംഗ് പട്ടികയ്ക്കായി ഒരിക്കലും തർക്കിക്കുന്നില്ല. രണ്ട് അതിഥികളെ ബ്രിഡ്ജ് ചെയ്യുന്നത് അവയുടെ റൂട്ടുകൾ കൂട്ടിച്ചേർക്കുന്നില്ല: വെർച്വൽ നെറ്റ്വർക്ക് ഒരു പാത നൽകുന്നു, ഈ പ്രാദേശിക ട്രാഫിക് ടണൽ ഒഴിവാക്കാം എന്ന് ഓരോ ക്ലയന്റിനോടും ഇപ്പോഴും പറയണം.

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

സ്ഥിരീകരിക്കുക, പിന്നെ വീണ്ടെടുക്കൽ ഉടമയുടെ കൈവശം വയ്ക്കുക

അതിഥിയുടെ ഉള്ളിൽ നിന്ന് പരീക്ഷിക്കുക ഒരു പുതിയ അപ്ലിക്കേഷൻ പ്രോസസ് ഉപയോഗിച്ച്: ട്രാഫിക്, പേര് നിർണ്ണയം, രണ്ട് വിലാസ കുടുംബങ്ങളും, ടണൽ വീഴുമ്പോൾ എന്ത് സംഭവിക്കുന്നു എന്നതും. ഹോസ്റ്റിന്റെ VPN ഐക്കൺ അതിഥിയുടെ പരിധിയെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല, ഈ മേഖലയിലാകെ ഏറ്റവും സാധാരണമായ തെറ്റായ സ്ഥിരീകരണം അതാണ്.

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