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 नामहरूको छेउमा मैले चार ठेगाना र दुई खण्ड नाम भएको पाठ फाइल राख्छु र त्यसलाई हरेक 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/ मा र नियम वितरणले प्रयोग गर्ने फायरवाल सेवामा सुरक्षित गर्नुहोस्, नत्र रिबुटले प्रयोगशालालाई चुपचाप रुट गरिएको तर अनुवाद नगरिएको अवस्थामा फर्काउँछ।
फर्वार्डिङ अनुमति होइन। 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त्यसपछि निकास प्रमाणित गर्नुहोस्। पाहुनाबाट ठेगाना प्रतिबिम्ब सेवालाई यसले कुन स्रोत देख्छ भनी सोध्नुहोस् र त्यसलाई गेटवेको आफ्नै निकास ठेगानासँग तुलना गर्नुहोस्; जवाफ होस्टको ठेगानासँग मिल्यो भने सुरुङको वरिपरिको बाटो अवस्थित छ। पाहुनाले वास्तवमा कुन resolver प्रयोग गर्छ जाँच्नुहोस्, र IPv6 छुट्टै जाँच्नुहोस्, किनकि IPv6 सक्षम भएको तर सुरुङले IPv4 मात्र बोकेको खण्ड दुर्घटनाले होइन, डिजाइनले चुहिन्छ।
अन्तमा, यसलाई जानाजान तोड्नुहोस्। सुरुङ रोक्नुहोस्, वा यसको बाह्य पोर्ट अवरुद्ध गर्नुहोस्, र पाहुनाबाट नयाँ जडान खोल्नुहोस्। यो असफल हुनैपर्छ, र कारण तपाईंले नाम दिन सक्ने हुनुपर्छ: रुट छैन, अस्वीकार नियम छ, वा resolver मृत छ। सुरुङ पुनः सुरु गर्नुहोस् र पाहुना नेटवर्क पुनः नबनाई सुधार हुन्छ भनी निश्चित गर्नुहोस्। Hamachi वा ZeroTier जस्तो mesh VPN ले प्रयोगशाला साझा गर्छ भने ब्रिज गरिएको एडाप्टरले mesh होइन, एडाप्टरको नाम पछ्याउँछ भनी सम्झनुहोस्, त्यसैले क्लाइन्टले आफ्नै भर्चुअल एडाप्टर इन्स्टल गरेपछि ब्रिज पुनः निर्देशित गर्नुपर्छ।
VBoxManage list bridgedifs
VBoxManage modifyvm lab-client --bridgeadapter1 <mesh-adapter-name>पाहुनाको सुरुङ होस्टसँग साझा गर्नु समस्याको प्रतिबिम्ब हो। होस्टको पूर्वनिर्धारित रुट पाहुनातर्फ निर्देशित गर्नु काम गर्छ, र पाहुनाभित्रको प्रोक्सी पनि काम गर्छ; होस्टमार्फत NAT ले होस्टले सुरु गरेको ट्राफिकका लागि पाहुनाको सुरुङ बोर्दैन। खण्डका नाम र फायरवाल नियम एकै ठाउँमा सुरक्षित गर्नुहोस्, काम गर्ने अवस्थाको स्न्यापसट लिनुहोस्, र सर्भरले अवलोकन गरेको स्रोत ठेगाना अभिलेख गर्नुहोस्। त्यसपछि अर्को प्रोफाइल परिवर्तनले पुनः बनाइएको प्रयोगशालाको सट्टा एउटा स्क्रिप्ट रन जत्तिकै खर्च गर्छ।