VM-ലെ VPN വഴി ഹോസ്റ്റ് ട്രാഫിക് റൂട്ട് ചെയ്യൽ: ആറ് പരിശോധനകൾ

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

കാരണത്തിൽ നിന്ന് തുടങ്ങുക. ഒന്നുകിൽ കോർപ്പറേറ്റ് ക്ലയന്റ് ഗസ്റ്റിനുള്ളിൽ മാത്രം ഇൻസ്റ്റാൾ ചെയ്യപ്പെടുന്നു, അല്ലെങ്കിൽ നയം അതിനെ അവിടെ തന്നെ നിർത്തുന്നു, നിങ്ങൾക്ക് ഇപ്പോഴും ഹോസ്റ്റിൽ നിന്ന് ഉള്ളിലെ build സെർവർ വേണം. ഹോസ്റ്റിന് സ്വന്തം ക്ലയന്റ് അനുവദിച്ചിട്ടുണ്ടെങ്കിൽ അതു തന്നെ ചെയ്യുക: ഹോസ്റ്റിലെ ഒരു ടണൽ എപ്പോഴും രണ്ട് നെറ്റ്വർക്കും NAT-ഉം കൂടിയതിനേക്കാൾ മികച്ചതാണ്.

പരിശോധന 1: ഹോസ്റ്റിന് വിലാസം നൽകാനാകുന്ന ഒരു ലിങ്ക് വേണം

ഗസ്റ്റിന്റെ രണ്ടാം അഡാപ്റ്ററിന്റെ അതേ പ്രിഫിക്സിൽ ഒരു ഇന്റർഫേസ് ഹോസ്റ്റിന് ഉണ്ടായിരിക്കണം. VirtualBox-ലെ host-only, VMware Workstation-ലെ host-only അല്ലെങ്കിൽ ഇഷ്ടാനുസൃത VMnet, QEMU/KVM-ലെ ആന്തരിക ബ്രിഡ്ജ് അല്ലെങ്കിൽ tap ഉപകരണം, Hyper-V-ലെ Internal സ്വിച്ച് — എല്ലാം യോഗ്യമാണ്. ഗസ്റ്റ് 192.168.56.2, ഹോസ്റ്റ് 192.168.56.1, പ്രിഫിക്സ് 192.168.56.0/24 ലബോറട്ടറികളിൽ ഞാൻ ഉപയോഗിക്കുന്ന ക്രമീകരണമാണ്.

QEMU-വിന്റെ ഉപയോക്തൃ മോഡ് നെറ്റ്വർക്കിംഗും (-netdev user, സ്ഥിരസ്ഥിതി SLIRP backend) VirtualBox NAT-ഉം ഈ പരിശോധനയിൽ പൂർണ്ണമായി പരാജയപ്പെടുന്നു. ഗസ്റ്റിന്റെ പാക്കറ്റുകൾ ഹോസ്റ്റിലെ ഒരു പ്രോക്സി പ്രോസസ്സിൽ എത്തുന്നു, അതിനാൽ ഗസ്റ്റിന്റെ വിലാസങ്ങൾ വഹിക്കുന്ന ഉപകരണം ഹോസ്റ്റ് ഒരിക്കലും കാണുന്നില്ല, റൂട്ട് ചൂണ്ടാൻ ഒന്നുമില്ല. Hyper-V-ന്റെ Default Switch-ഉം അതേ കഥ തന്നെ. ഹോസ്റ്റിൽ നിന്നുള്ള ping 192.168.56.2 പരാജയപ്പെട്ടാൽ നിർത്തുക: പിന്നീട് ചേർക്കുന്ന ഒരു റൂട്ടും അത് ശരിയാക്കില്ല.

പരിശോധന 2: ഗസ്റ്റ് ഫോർവേർഡ് ചെയ്യുന്നു, വിവർത്തനം ചെയ്യുന്നു

ഹോസ്റ്റിൽ നിന്നുള്ള പാക്കറ്റുകൾ host-only ഉറവിട വിലാസത്തോടും ആന്തരിക ലക്ഷ്യസ്ഥാനത്തോടും എത്തുന്നു, അതിനാൽ ഗസ്റ്റ് അവ ഫോർവേർഡ് ചെയ്ത് പിന്നീട് സ്വന്തം ടണൽ വിലാസത്തിന് പിന്നിൽ ഒളിപ്പിക്കണം. Linux ഗസ്റ്റിൽ ഇതിനർത്ഥം ഫോർവേർഡിംഗ്, ഒരു FORWARD accept ജോടി, ടണലിലേക്കുള്ള source NAT എന്നിവയാണ്:

sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -A FORWARD -i eth1 -o tun0 -j ACCEPT
sudo iptables -A FORWARD -i tun0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -t nat -A POSTROUTING -s 192.168.56.0/24 -o tun0 -j MASQUERADE

MASQUERADE നിയമമാണ് ആളുകൾ വിട്ടുകളയുന്ന ഭാഗം. കോർപ്പറേറ്റ് റൂട്ടറുകൾക്ക് 192.168.56.0/24 ഉണ്ടെന്ന് അപൂർവ്വമായേ അറിയൂ; നിയമത്തോടെ ആന്തരിക സെർവറുകൾ ഗസ്റ്റിന്റെ ടണൽ വിലാസം കണ്ട് അതിന് മറുപടി നൽകുന്നു, മറുപടി ഗസ്റ്റിലേക്ക് തിരികെ വഴി കണ്ടെത്തുന്നു.

Windows ഗസ്റ്റ് കൂടുതൽ അനാകർഷകമാണ്. SYSTEM\CurrentControlSet\Services\Tcpip\Parameters-ന് കീഴിലുള്ള IPEnableRouter=1 വിവർത്തനമില്ലാതെ ഫോർവേർഡിംഗ് ഓണാക്കുന്നു, അതിനാൽ കോർപ്പറേറ്റ് റൂട്ടിംഗ് ഇതിനകം നിങ്ങളുടെ host-only പ്രിഫിക്സിലേക്ക് തിരികെ ചൂണ്ടുന്നിടത്ത് മാത്രം ഇത് പ്രവർത്തിക്കുന്നു. Internet Connection Sharing വിവർത്തനം ചെയ്യുന്നു, പക്ഷേ പങ്കിട്ട അഡാപ്റ്റർ 192.168.137.1-ലേക്ക് പുനഃക്രമീകരിക്കുന്നു, അതിനാൽ ഹോസ്റ്റ് റൂട്ടുകൾ എഴുതുന്നതിന് മുൻപ് അത് യഥാർത്ഥത്തിൽ എടുത്ത വിലാസം വായിക്കുക.

പരിശോധന 3: ഹോസ്റ്റ് റൂട്ടുകൾ ഗസ്റ്റിനെ പേരിടുന്നു, ടണലിനെയല്ല

ഹോസ്റ്റിന് ആവശ്യമുള്ള പ്രിഫിക്സുകൾ മാത്രം ഗസ്റ്റിലൂടെ അയയ്ക്കുക. Linux-ൽ ഓരോ പ്രിഫിക്സിനും ഒരു റൂട്ട് മതി, അത് വൃത്തിയായി തിരികെ മാറുന്നു:

sudo ip route add 10.20.0.0/16 via 192.168.56.2
ip route get 10.20.30.40

Windows-ൽ തത്തുല്യമായത് route add 10.20.0.0 mask 255.255.0.0 192.168.56.2 ആണ്. പരീക്ഷിക്കുമ്പോൾ -p ഒഴിവാക്കുക, മോശം റൂട്ട് റീബൂട്ടിൽ മരിക്കട്ടെ, പാത പ്രവർത്തിച്ചാൽ അത് ചേർക്കുക. ഹോസ്റ്റിലെ ഡിഫോൾട്ട് റൂട്ട് നീക്കം ചെയ്യരുത്, ഹോസ്റ്റിലെ എല്ലാ ആപ്ലിക്കേഷനുകളും ടണൽ ഉപയോഗിക്കേണ്ടതുണ്ടെങ്കിൽ ഒഴികെ; യഥാർത്ഥത്തിൽ ഫുൾ ടണൽ ആവശ്യമാണെങ്കിൽ, രണ്ട് /1 റൂട്ടുകൾ ചേർത്ത് ഹൈപ്പർവൈസർ നെറ്റ്വർക്കിലേക്കുള്ള നേരിട്ടുള്ള റൂട്ട് നിലനിർത്തുക:

sudo ip route add 0.0.0.0/1 via 192.168.56.2
sudo ip route add 128.0.0.0/1 via 192.168.56.2

Windows ഹോസ്റ്റിൽ ഇന്റർഫേസ് മെട്രിക് കൂടി പരിശോധിക്കുക. host-only അഡാപ്റ്റർ നിഷ്ക്രിയമായിരുന്നപ്പോൾ ചേർത്ത റൂട്ട് പട്ടികയിൽ നിൽക്കും, പക്ഷേ ഒരിക്കലും ട്രാഫിക് കൊണ്ടുപോകുന്നില്ല, കൂടാതെ കുറഞ്ഞ മെട്രിക്കുള്ള രണ്ടാം അഡാപ്റ്റർ അതേ പ്രിഫിക്സിനുള്ള തിരച്ചിൽ നേടിയേക്കാം.

പരിശോധന 4: DNS റൂട്ടിനെ പിന്തുടരുന്നു, ടണലിന്റെ ഡിഫോൾട്ടിനെയല്ല

റൂട്ടുകൾ പാക്കറ്റുകളെ നീക്കുന്നു; ഏത് പേരുകൾ പാക്കറ്റുകൾ സൃഷ്ടിക്കുന്നു എന്ന് റിസോൾവർ തീരുമാനിക്കുന്നു. ഹോസ്റ്റിന്റെ റിസോൾവർ മാറ്റുന്നതിനുപകരം കോർപ്പറേറ്റ് റിസോൾവറെ കോർപ്പറേറ്റ് സോണിൽ പരിമിതപ്പെടുത്തുക, പുതിയ റൂട്ട് ഇതിനകം എത്തുന്ന DNS സെർവറിലേക്ക് അതിനെ ചൂണ്ടുക. ഹോസ്റ്റിൽ systemd-resolved ഉണ്ടെങ്കിൽ:

resolvectl dns eth1 10.20.0.53
resolvectl domain eth1 '~corp.example.com'

Windows-ൽ നാമ വിവർത്തന നയ പട്ടികയിലെ ഒരു എൻട്രി അതേ ജോലി ചെയ്യുന്നു: Add-DnsClientNrptRule -Namespace ".corp.example.com" -NameServers 10.20.0.53. ഗസ്റ്റ് host-only വിലാസത്തിൽ സ്വന്തം റിസോൾവർ പ്രവർത്തിപ്പിക്കുന്നുവെങ്കിൽ അതിനുപകരം ആ വിലാസം ഉപയോഗിക്കുക, പക്ഷേ അത് loopback-ൽ അല്ല, 192.168.56.2-ൽ മറുപടി നൽകുന്നുവെന്ന് ഉറപ്പാക്കിയ ശേഷം മാത്രം.

പിന്നീട് മന്ദഗതിയിലുള്ള പേജുകൾക്ക് DNS-നെ കുറ്റപ്പെടുത്തുന്നതിന് മുൻപ് MTU പരിശോധിക്കുക. ടണൽ ഇന്റർഫേസ് ഹോസ്റ്റിന്റെ 1500 ബൈറ്റ് ഇന്റർഫേസിനേക്കാൾ ചെറുതാണ്, അതിനാൽ DF ബിറ്റ് ഇട്ട് പൂർണ്ണ വലിപ്പത്തിലുള്ള സെഗ്മെന്റുകൾ അയയ്ക്കുന്ന ഹോസ്റ്റ് അവ ഗസ്റ്റിനുള്ളിൽ എവിടെയോ നഷ്ടപ്പെടുന്നു. സാധാരണ ലക്ഷണം പ്രവർത്തിക്കുന്ന ping കൂടാതെ TLS ഹാൻഡ്ഷേക്കിന് ശേഷം നിന്നുപോകുന്ന ആന്തരിക വെബ് ആപ്പ് എന്നിവയാണ്. ഗസ്റ്റിന്റെ ഫോർവേർഡ് പാതയിൽ MSS കർശനമാക്കുക:

sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

പരിശോധന 5: ഇരു അറ്റങ്ങളിൽ നിന്നും പരിശോധിക്കുക

ഹോസ്റ്റിൽ നിന്ന് ആന്തരിക വിലാസത്തിലേക്ക് traceroute അല്ലെങ്കിൽ tracert ആദ്യ ഹോപ്പായി ഭൗതിക ഗേറ്റ്വേയല്ല, 192.168.56.2 കാണിക്കണം. ഗസ്റ്റിൽ അതേ ശ്രമം പുറത്തുപോകുന്നത് നിരീക്ഷിക്കുക: tcpdump -ni any host 10.20.30.40 host-only ഭാഗത്ത് ഫോർവേർഡ് ചെയ്ത അഭ്യർത്ഥനയും ടണലിൽ വിവർത്തനം ചെയ്തതും കാണിക്കുന്നു. പുറത്തുപോയി തിരികെ വന്നിട്ടും ഹോസ്റ്റിനെ മൗനമാക്കുന്ന അഭ്യർത്ഥന തിരികെയുള്ള പാതയിലേക്ക് ചൂണ്ടുന്നു.

ഇതിന്റെ ഭൂരിഭാഗവും രണ്ട് പരാജയങ്ങൾ വിശദീകരിക്കുന്നു. ഒന്നുകിൽ NAT നിയമം ഇല്ലാത്തതിനാൽ ഗസ്റ്റിന്റെ ടണലിന് host-only പ്രിഫിക്സിലേക്ക് തിരികെയുള്ള റൂട്ട് ഇല്ല, അല്ലെങ്കിൽ റീബൂട്ടിന് ശേഷം ഗസ്റ്റിന് ഇനി ഇല്ലാത്ത വിലാസത്തിലേക്ക് ഹോസ്റ്റ് റൂട്ട് ചൂണ്ടുന്നു. കഴിഞ്ഞ സെഷന്റെ കുറിപ്പുകൾ വിശ്വസിക്കുന്നതിനുപകരം ip -br addr, ip route get ഉപയോഗിച്ച് വിലാസങ്ങൾ വീണ്ടും വായിക്കുക.

പരിശോധന 6: റീബൂട്ടും ഹൈപ്പർവൈസർ അപ്ഗ്രേഡും അതിജീവിക്കാൻ ഇടയാക്കുക

രണ്ട് പകുതികളും സ്ഥിരമാക്കുക: ഹോസ്റ്റിൽ netplan അല്ലെങ്കിൽ NetworkManager റൂട്ട് കോൺഫിഗറേഷൻ, Windows-ൽ route add ... -p, കൂടാതെ /etc/sysctl.d/-ൽ net.ipv4.ip_forward=1 ഉം ഗസ്റ്റിൽ വീണ്ടും ലോഡ് ചെയ്യുന്ന ഫയർവാൾ നിയമങ്ങളും. കോൺഫിഗറേഷൻ പരിശോധിച്ച ഉടൻ, അടുത്ത കോർപ്പറേറ്റ് ക്ലയന്റ് അപ്ഡേറ്റ് വരുന്നതിന് മുൻപ് ഗസ്റ്റിന്റെ snapshot എടുക്കുക.

ഹൈപ്പർവൈസർ തന്റെ അഡാപ്റ്ററുകൾ വീണ്ടും സൃഷ്ടിക്കുമ്പോൾ host-only നെറ്റ്വർക്കുകൾ പുനഃക്രമീകരിക്കപ്പെടുന്നു, ഇത് 192.168.56.0/24-ൽ നിർമ്മിച്ച ഓരോ റൂട്ടും NAT നിയമവും നിശബ്ദമായി അസാധുവാക്കുന്നു. അപ്ഗ്രേഡിന് ശേഷം ആദ്യത്തെ മൂന്ന് പരിശോധനകൾ ക്രമത്തിൽ ആവർത്തിക്കുക; ഇതിന് ഒരു മിനിറ്റ് എടുക്കും, ഹോസ്റ്റിന് ഇപ്പോഴും റൂട്ട് ഉണ്ടായിരിക്കെ ഗസ്റ്റ് പുതിയ സബ്നെറ്റിലേക്ക് മാറിയ സാഹചര്യം പിടിക്കും.

IPv6-ന് സ്വന്തം വട്ടം വേണം. ip6tables നിയമങ്ങൾ, AAAA റെക്കോർഡുകൾ, രണ്ടാം ഹോസ്റ്റ് റൂട്ട് കുടുംബം എന്നിവ IPv4 ക്രമീകരണത്തെ പിന്തുടരുന്നില്ല, IPv6 വഴി ലഭ്യമായ കോർപ്പറേറ്റ് സേവനം IPv4 പ്രവർത്തിക്കുമ്പോൾ ശാശ്വതമായി തകർന്നതായി കാണപ്പെടും.

വിജയിച്ചാലും ഇല്ലെങ്കിലും, ക്രമത്തിൽ: ഹോസ്റ്റിന് ഗസ്റ്റിന്റെ host-only വിലാസത്തിലേക്ക് പിംഗ് ചെയ്യാം; ഗസ്റ്റ് ടണലിലേക്ക് ഫോർവേർഡും MASQUERADE-ഉം ചെയ്യുന്നു; ip route get ആന്തരിക പ്രിഫിക്സിന് ഗേറ്റ്വേയായി ഗസ്റ്റിനെ തിരികെ നൽകുന്നു; കോർപ്പറേറ്റ് പേരുകൾ പരിമിതപ്പെടുത്തിയ റിസോൾവർ വഴി പരിഹരിക്കപ്പെടുന്നു; traceroute ഗസ്റ്റിനെ ആദ്യം കാണിക്കുന്നു; അതേ ആറ് ഉത്തരങ്ങൾ റീബൂട്ടിനെ അതിജീവിക്കുന്നു.