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 விருந்தினரை முதலில் காட்டுகிறது; அதே ஆறு பதில்கள் மறுதொடக்கத்தைத் தாங்குகின்றன.