VirtualBox VPN लैब: गेटवे VM बनाम केवल-होस्ट नेटवर्क
VirtualBox VPN लैब के लिए राउटेड गेटवे VM और केवल-होस्ट सेगमेंट के बीच चुनें, फिर टनल गिरने पर गेस्ट को बंद होकर विफल होने दें।
आपको तय करना है कि आपकी VPN लैब कितनी मशीनरी की हकदार है। दो VirtualBox सेगमेंट के बीच एक राउटेड गेटवे VM पता अनुवाद, वापसी पथ और उस फ़ायरवॉल की स्थिति फिर से पैदा करता है जिसके पीछे एक वास्तविक क्लाइंट बैठता है। एक अकेला केवल-होस्ट सेगमेंट आपको एक नियंत्रित दरवाज़ा देता है और कुछ नहीं। गेटवे संस्करण में तीन गेस्ट और एक राउटिंग तालिका की लागत आती है जिसे आप बनाए रखते हैं; केवल-होस्ट संस्करण में एक गेस्ट और एक नीति की। तीन प्रश्न इन्हें अलग करते हैं, और तीसरा तय करता है कि आपका परीक्षण आख़िर पास हो सकता है या नहीं।
कुछ भी क्लोन करने से पहले तीन प्रश्नों के उत्तर दें
शुरू करें उस बात से जो 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 क्लाइंट और उसका फ़ायरवॉल गलती से गेस्ट तक नहीं पहुँच सकते। आंतरिक सेगमेंट में DHCP सर्वर भी नहीं होता जब तक आप एक न जोड़ें, इसलिए स्थिर पते सबसे छोटा रास्ता हैं।
क्लाइंट को केवल उसका WAN पता दें, डिफ़ॉल्ट गेटवे गेटवे के WAN पते की ओर इशारा करे। सर्वर को LAN पता मिलता है और वह गेटवे के LAN पते को अपना डिफ़ॉल्ट गेटवे बनाता है। जो गेस्ट एक सेगमेंट पर दो पते रखता है, या दूसरे सेगमेंट की ओर भटका हुआ रूट रखता है, उसके पास राउटर के चारों ओर एक रास्ता है, और नीचे के परीक्षण आपसे झूठ बोलेंगे।
मैं VM नामों के बगल में एक टेक्स्ट फ़ाइल रखता हूँ जिसमें चार पते और दो सेगमेंट नाम होते हैं, और उसे हर शेल में चिपका देता हूँ। हफ़्तों बाद, जब प्रोफ़ाइल में कोई बदलाव कुछ तोड़ देता है, तब वही फ़ाइल प्रोफ़ाइल को डिबग करने और अपनी स्मृति को डिबग करने के बीच का अंतर है।
जिस सेगमेंट से लीक नहीं होना चाहिए उसके लिए आंतरिक या केवल-होस्ट चुनें
केवल-होस्ट मोड होस्ट पर ही एक वर्चुअल अडैप्टर बनाता है, आमतौर पर 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/ में और नियम उस फ़ायरवॉल सेवा में सहेजें जो वितरण इस्तेमाल करता है, वरना रीबूट लैब को चुपचाप राउटेड पर अनूदित न होने वाली स्थिति में लौटा देगा।
फ़ॉरवर्डिंग अनुमति नहीं है। 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 जैसा मेश VPN लैब साझा करता है, तो याद रखें कि ब्रिज्ड अडैप्टर अडैप्टर का नाम मानता है, मेश नहीं, इसलिए क्लाइंट के अपना वर्चुअल अडैप्टर इंस्टॉल करने के बाद ब्रिज को फिर से इंगित करना होगा।
VBoxManage list bridgedifs
VBoxManage modifyvm lab-client --bridgeadapter1 <mesh-adapter-name>गेस्ट की टनल होस्ट के साथ साझा करना समस्या को प्रतिबिंबित करता है। होस्ट के डिफ़ॉल्ट रूट को गेस्ट की ओर इंगित करना काम करता है, और गेस्ट के अंदर प्रॉक्सी भी काम करता है; होस्ट के ज़रिए NAT होस्ट द्वारा शुरू किए गए ट्रैफ़िक के लिए गेस्ट की टनल नहीं ले जाता। सेगमेंट के नाम और फ़ायरवॉल नियम एक ही जगह सहेजें, काम करने वाली स्थिति का स्नैपशॉट लें, और वह स्रोत पता दर्ज करें जो सर्वर ने देखा। तब अगला प्रोफ़ाइल बदलाव फिर से बनी लैब के बजाय एक स्क्रिप्ट रन का खर्च लेगा।