VirtualBox VPN ஆய்வகம்: கேட்வே VM அல்லது ஹோஸ்ட்-மட்டும் நெட்வொர்க்
VirtualBox VPN ஆய்வகத்திற்கு ரூட் செய்யப்பட்ட கேட்வே VM அல்லது ஹோஸ்ட்-மட்டும் பிரிவைத் தேர்ந்தெடுத்து, சுரங்கப்பாதை விழும்போது விருந்தினர் மூடிய நிலையில் தோல்வியடையச் செய்யுங்கள்.
உங்கள் VPN ஆய்வகத்திற்கு எவ்வளவு இயந்திரம் தேவை என்பதை நீங்கள் தீர்மானிக்க வேண்டும். இரண்டு VirtualBox பிரிவுகளுக்கு இடையே ஒரு ரூட் செய்யப்பட்ட கேட்வே VM முகவரி மொழிபெயர்ப்பு, திரும்பும் பாதை மற்றும் உண்மையான வாடிக்கையாளர் அமரும் firewall இடத்தை மீண்டும் உருவாக்குகிறது. ஒரே ஹோஸ்ட்-மட்டும் பிரிவு உங்களுக்கு ஒரு கட்டுப்படுத்தப்பட்ட கதவை மட்டுமே தருகிறது, வேறு எதுவும் இல்லை. கேட்வே பதிப்புக்கு மூன்று விருந்தினர்கள் மற்றும் நீங்கள் பராமரிக்கும் ரூட்டிங் அட்டவணை தேவை; ஹோஸ்ட்-மட்டும் பதிப்புக்கு ஒரு விருந்தினர் மற்றும் ஒரு கொள்கை தேவை. மூன்று கேள்விகள் அவற்றைப் பிரிக்கின்றன, மூன்றாவது உங்கள் சோதனை எப்படியாவது வெற்றி பெற முடியுமா என்பதைத் தீர்மானிக்கிறது.
எதையும் குளோன் செய்வதற்கு முன் மூன்று கேள்விகளுக்கு பதிலளிக்கவும்
VPN சேவையகம் எதைக் கவனிக்க வேண்டும் என்பதில் தொடங்குங்கள். சோதனை விருந்தினரின் இல்லாத மூல முகவரியை சேவையகம் பார்க்க வேண்டும் என்றால், அவற்றுக்கிடையே ஏதோ மொழிபெயர்க்க வேண்டும், அந்த ஏதோ நீங்கள் கட்டுப்படுத்தும் ரவுட்டராக இருக்க வேண்டும். ஹோஸ்ட்-மட்டும் நெட்வொர்க்கிங் ஹோஸ்ட்டுக்கு விருந்தினரின் பிரிவில் அடாப்டரைத் தருகிறது, மொழிபெயர்ப்பாளர் அல்ல. பிறகு விருந்தினர் வெளியில் ஏதாவது அடைய வேண்டியிருக்கும்போது, நீங்கள் ஒரு NAT அடாப்டரை இணைக்கிறீர்கள், VirtualBox இன் சொந்த NAT இயந்திரம் உங்களைக் கேட்காமல் மூலத்தை மீண்டும் எழுதுகிறது.
அடுத்து, சுரங்கப்பாதையைத் தவிர வேறு எதையும் விருந்தினர் அடையலாமா என்று கேளுங்கள். அந்த பதில் உள் அல்லது ஹோஸ்ட்-மட்டும் என்பதைத் தேர்ந்தெடுக்கிறது, இதுவே பெரும்பாலான ஆய்வக எழுத்துகள் தவிர்க்கும் கேள்வி. இறுதியாக, சுரங்கப்பாதை விழும்போது என்ன நடக்க வேண்டும் என்று கேளுங்கள், ஏனெனில் அது இடவியல் அல்ல, கொள்கையைத் தீர்மானிக்கிறது, மகிழ்ச்சியான பாதையை மட்டும் நிரூபிக்கும் ஆய்வகம் எதையும் கிட்டத்தட்ட சோதிக்கவில்லை.
| What the test requires | Routed gateway VM | Host-only guest |
|---|---|---|
| Server sees a translated source address | Yes, from your own MASQUERADE rule | No, VirtualBox NAT does it instead |
| The guest has exactly one egress | Yes, while the second adapter faces the tunnel | Only until a NAT adapter is attached |
| Policy is testable during a tunnel failure | Rules live in one place | Rules live on each guest |
மூன்று பாத்திரங்களை உள் நெட்வொர்க்குகளுடன் இணைக்கவும்
மூன்று விருந்தினர்கள் மற்றும் இரண்டு பெயரிடப்பட்ட பிரிவுகளைப் பயன்படுத்துங்கள், இரண்டிலும் அடாப்டர் உள்ள ஒரே இயந்திரம் கேட்வே ஆக இருக்கட்டும்:
VBoxManage modifyvm lab-client --nic1 intnet --intnet1 WAN
VBoxManage modifyvm lab-server --nic1 intnet --intnet1 LAN
VBoxManage modifyvm lab-gw --nic1 intnet --intnet1 WAN --nic2 intnet --intnet2 LANஉள் நெட்வொர்க்குக்கு தனி உருவாக்க படி இல்லை. --intnet1 இல் உள்ள சரம் தான் பிரிவு: பெயர் சரியாக பொருந்தினால் மட்டுமே இரண்டு இயந்திரங்கள் அதைப் பங்கிடும், ஹோஸ்ட்டில் எதுவும் அதனுடன் இணைக்கப்படவில்லை. இந்த கடைசி பண்பே ஆய்வகம் தூய்மையாக மீள்வதற்கான காரணம், ஏனெனில் ஹோஸ்ட்டின் பாதைகள், அதன் சொந்த VPN வாடிக்கையாளர் மற்றும் அதன் firewall ஆகியவை தற்செயலாக விருந்தினர்களை அடைய முடியாது. உள் பிரிவில் DHCP சேவையகமும் இல்லை, நீங்கள் ஒன்றைச் சேர்த்தால் தவிர, எனவே நிலையான முகவரிகள் மிகக் குறுகிய பாதை.
வாடிக்கையாளருக்கு அதன் WAN முகவரியை மட்டும் கொடுங்கள், இயல்புநிலை கேட்வே கேட்வேயின் WAN முகவரியை நோக்கிக் காட்ட வேண்டும். சேவையகம் LAN முகவரியைப் பெற்று கேட்வேயின் LAN முகவரியை தன் இயல்புநிலை கேட்வேவாகப் பயன்படுத்துகிறது. ஒரு பிரிவில் இரண்டு முகவரிகளை வைத்திருக்கும், அல்லது மற்ற பிரிவுக்கு வழிதவறிய பாதை உள்ள விருந்தினருக்கு ரவுட்டரைச் சுற்றி ஒரு பாதை உள்ளது, கீழே உள்ள சோதனைகள் உங்களுக்குப் பொய் சொல்லும்.
VM பெயர்களுக்கு அருகில் நான்கு முகவரிகள் மற்றும் இரண்டு பிரிவு பெயர்கள் கொண்ட உரைக் கோப்பை வைத்து ஒவ்வொரு shell இலும் ஒட்டுகிறேன். வாரங்கள் கழித்து, சுயவிவர மாற்றம் ஏதாவது உடைக்கும்போது, அந்தக் கோப்பே சுயவிவரத்தை பிழைதிருத்துவதற்கும் என் சொந்த நினைவகத்தை பிழைதிருத்துவதற்கும் இடையிலான வித்தியாசம்.
கசியக்கூடாத பிரிவுக்கு உள் அல்லது ஹோஸ்ட்-மட்டும் தேர்ந்தெடுக்கவும்
ஹோஸ்ட்-மட்டும் பயன்முறை ஹோஸ்ட்டின் மீதே ஒரு மெய்நிகர் அடாப்டரை உருவாக்கி, பொதுவாக vboxnet0, ஹோஸ்ட்டுக்கு விருந்தினரின் பிரிவில் முகவரி தருகிறது. இது நிர்வாகத்திற்கு வசதியானது, தனிமைப்படுத்தல் சோதனைக்கு மரணமானது, ஏனெனில் ஹோஸ்ட் இப்போது விருந்தினரை நேரடியாக அடைய முடியும், ஹோஸ்ட் பக்கத்தின் ஒவ்வொரு சேவையும் சாத்தியமான பாதையாகிறது. உள் பயன்முறையில் ஹோஸ்ட் அடாப்டர் இல்லவே இல்லை. இரண்டு பயன்முறைகளும் நெட்வொர்க் அமைப்புகள் பலகையில் எளிதில் குழப்பமடைகின்றன, எனவே லேபிளை அல்ல, ஆவணப்படுத்தப்பட்ட வித்தியாசத்தைச் சரிபார்க்கவும் (VirtualBox நெட்வொர்க்கிங் விவரங்கள் பக்கத்தைப் பார்க்கவும்).
சுரங்கப்பாதையைப் பயன்படுத்த வேண்டிய விருந்தினருக்கு உள் மிகவும் பாதுகாப்பான இயல்புநிலை, கேட்வே ஒரே வெளியேறும் வழி. நீங்கள் ஹோஸ்ட்-மட்டும் வைத்திருந்தால், ஹோஸ்ட் அடாப்டரை நிர்வாக பாதையாகக் கருதி அதைச் சத்தமாகச் சொல்லுங்கள்: ஹோஸ்ட் விருந்தினரை அடையலாம், விருந்தினர் ஹோஸ்ட்டை வெளியேறும் வழியாகப் பயன்படுத்த முடியாது.
VBoxManage modifyvm lab-client --nic1 hostonly --hostonlyadapter1 vboxnet0நீங்கள் நிரூபிக்கக்கூடிய தனிமைப்படுத்தலே நீங்கள் உள்ளமைத்த தனிமைப்படுத்தல். ஒரு உள் அடாப்டர், கேட்வேயில் இயல்புநிலை பாதை மற்றும் NAT அடாப்டர் இல்லாத விருந்தினருக்கு கேட்வேயைத் தவிர்க்கும் பாதை இல்லை. ஹோஸ்ட்-மட்டும் அடாப்டர் மற்றும் NAT அடாப்டர் உள்ள விருந்தினருக்கு இரண்டு பாதைகள் உள்ளன, அவற்றில் ஒன்று மட்டுமே நீங்கள் சோதிக்க நினைத்த பாதை.
கேட்வேயில் ரூட் செய்து மொழிபெயர்க்கவும், பின்னர் அது மூடிய நிலையில் தோல்வியடையச் செய்யவும்
VirtualBox பிரிவுகளுக்கு இடையே அனுப்பாது; விருந்தினர் தான் அனுப்புகிறது. VPN சேவையக VM கேட்வேக்குப் பின்னால் இருக்கும்போது, அனுப்புதலை இயக்கி வாடிக்கையாளரின் போக்குவரத்தை சேவையகத்தை நோக்கி வெளியேறும்போது மொழிபெயர்க்கவும்:
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADEஅந்த விதியுடன் சேவையகம் வாடிக்கையாளருக்குப் பதிலாக கேட்வேயின் LAN முகவரியைப் பார்க்கிறது, இணைப்பு வழங்குநர் NAT க்குப் பின்னால் உள்ள உண்மையான வாடிக்கையாளர் நெட்வொர்க் தலைக்கு அப்படித்தான் தெரிகிறது. sysctl மதிப்பை /etc/sysctl.d/ இல் மற்றும் விதியை விநியோகம் பயன்படுத்தும் firewall சேவையில் சேமிக்கவும், இல்லையெனில் மறுதொடக்கம் ஆய்வகத்தை அமைதியாக ரூட் செய்யப்பட்ட ஆனால் மொழிபெயர்க்கப்படாத நிலைக்குத் திரும்பச் செய்யும்.
அனுப்புதல் அனுமதி அல்ல. ACCEPT இன் இயல்புநிலை FORWARD கொள்கையின் கீழ், இயல்புநிலை பாதை கேட்வேயை நோக்கிக் காட்டும் விருந்தினர், சுரங்கப்பாதை இருந்தாலும் இல்லாவிட்டாலும், ரூட்டிங் அட்டவணை தேர்ந்தெடுக்கும் இடைமுகம் வழியாக வெளியேறுகிறது. கேட்வேயில் தொகுப்பு நிறுவலுக்கான NAT அடாப்டரும் இருந்தால், சுரங்கப்பாதை விழும் தருணத்தில் அந்த அடாப்டர் வேலை செய்யும் குறியாக்கம் செய்யப்படாத வெளியேறும் வழி, உங்கள் VPN-மட்டும் சோதனை ஒருபோதும் VPN-மட்டும் சோதனையாக இருக்கவில்லை.
சேவையகம் தொலைவில் இருக்கும்போது சுரங்கப்பாதையை கேட்வேயே முடிக்கும்போது, அதே முடிவு இணையத்தை அடையும் NIC ஐ அல்ல, சுரங்கப்பாதை இடைமுகத்தை நோக்கிக் காட்டுகிறது:
iptables -P FORWARD DROP
iptables -A FORWARD -i eth0 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o eth0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPTசுரங்கப்பாதையின் சொந்த வெளிப்புற போக்குவரத்தையும் பட்டைக்கு வெளியேயான நிர்வாக பாதையையும் அனுப்பப்படும் போக்குவரத்திலிருந்து தனியாக வைத்திருங்கள். கேட்வேயைச் சரிசெய்வதற்கான ஒரே வழி நீங்கள் பிழைதிருத்தும் சுரங்கப்பாதையாக இருந்தால், ஆய்வகம் பூட்டப்படும் பயிற்சியாக மாறும். ஒரு தொடர் பணியகம், ஹோஸ்ட்-மட்டும் நிர்வாக அடாப்டர், அல்லது அறியப்பட்ட நல்ல நிலையின் ஸ்னாப்ஷாட் கைமுறையாக உடைந்த ரவுட்டரை மீட்டெடுப்பதை விட மலிவானது.
பாதையை ஹோஸ்ட்டிலிருந்து அல்ல, விருந்தினரிடமிருந்து சரிபார்க்கவும்
வெளிநோக்கி வேலை செய்யுங்கள். வாடிக்கையாளர் கேட்வேயின் WAN முகவரியை அடைகிறார், பின்னர் கேட்வே வழியாக சேவையகத்தை அடைகிறார், பின்னர் VPN துறைமுகத்திற்கான இணைப்பு வெளியேறி திரும்புகிறது என்பதை உறுதிப்படுத்துங்கள். கேட்வேயின் இரண்டு இடைமுகங்களிலும் பிடிப்பு பதில் வருகிறதா மற்றும் திரும்பும் பாதையில் தூக்கி எறியப்படுகிறதா என்பதைக் காட்டுகிறது, வாடிக்கையாளரில் மட்டும் பிடிப்பால் அதை வேறுபடுத்த முடியாது:
tcpdump -ni eth0 udp port 1194
tcpdump -ni tun0 udp port 1194பின்னர் வெளியேற்றத்தை நிரூபிக்கவும். விருந்தினரிடமிருந்து முகவரி பிரதிபலிப்பு சேவையிடம் எந்த மூலத்தைப் பார்க்கிறது என்று கேட்டு அதை கேட்வேயின் சொந்த வெளியேறும் முகவரியுடன் ஒப்பிடுங்கள்; பதில் ஹோஸ்ட்டின் முகவரியுடன் பொருந்தினால், சுரங்கப்பாதையைச் சுற்றி ஒரு பாதை உள்ளது. விருந்தினர் உண்மையில் எந்த தீர்வியைப் பயன்படுத்துகிறார் என்பதைச் சரிபார்க்கவும், IPv6 ஐ தனியாகச் சரிபார்க்கவும், ஏனெனில் IPv6 இயக்கப்பட்டு சுரங்கப்பாதை IPv4 மட்டும் சுமக்கும் பிரிவு தற்செயலாக அல்ல, வடிவமைப்பால் கசிகிறது.
இறுதியாக, அதை வேண்டுமென்றே உடையுங்கள். சுரங்கப்பாதையை நிறுத்துங்கள், அல்லது அதன் வெளிப்புற துறைமுகத்தைத் தடுங்கள், விருந்தினரிடமிருந்து புதிய இணைப்பைத் திறக்கவும். அது தோல்வியடைய வேண்டும், காரணம் நீங்கள் பெயரிடக்கூடியதாக இருக்க வேண்டும்: பாதை இல்லை, மறுப்பு விதி உள்ளது, அல்லது தீர்வி இறந்துவிட்டது. சுரங்கப்பாதையை மீண்டும் தொடங்கி விருந்தினர் நெட்வொர்க்கை மீண்டும் கட்டாமல் குணமடைவதை உறுதிப்படுத்துங்கள். Hamachi அல்லது ZeroTier போன்ற mesh VPN ஆய்வகத்தைப் பங்கிட்டால், பிரிட்ஜ் செய்யப்பட்ட அடாப்டர் mesh ஐ அல்ல, அடாப்டரின் பெயரைப் பின்பற்றுகிறது என்பதை நினைவில் கொள்ளுங்கள், எனவே வாடிக்கையாளர் தன் சொந்த மெய்நிகர் அடாப்டரை நிறுவிய பிறகு பிரிட்ஜ் மீண்டும் இயக்கப்பட வேண்டும்.
VBoxManage list bridgedifs
VBoxManage modifyvm lab-client --bridgeadapter1 <mesh-adapter-name>விருந்தினரின் சுரங்கப்பாதையை ஹோஸ்ட்டுடன் பங்கிடுவது சிக்கலைப் பிரதிபலிக்கிறது. ஹோஸ்ட்டின் இயல்புநிலை பாதையை விருந்தினரை நோக்கிக் காட்டுவது வேலை செய்கிறது, விருந்தினருக்குள் proxy யும் வேலை செய்கிறது; ஹோஸ்ட் வழியாக NAT ஹோஸ்ட் தொடங்கிய போக்குவரத்திற்கு விருந்தினரின் சுரங்கப்பாதையைச் சுமக்காது. பிரிவு பெயர்களையும் firewall விதிகளையும் ஒரே இடத்தில் சேமித்து, வேலை செய்யும் நிலையின் ஸ்னாப்ஷாட்டை எடுத்து, சேவையகம் கவனித்த மூல முகவரியைப் பதிவு செய்யுங்கள். பின்னர் அடுத்த சுயவிவர மாற்றம் மீண்டும் கட்டப்பட்ட ஆய்வகத்திற்குப் பதிலாக ஒரு ஸ்கிரிப்ட் ஓட்டத்தின் செலவாகும்.