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 होस्टने सुरू केलेल्या रहदारीसाठी गेस्टचा बोगदा वाहत नाही। विभागांची नावे आणि फायरवॉल नियम एका जागी जतन करा, चालणार्‍या स्थितीचा स्नॅपशॉट घ्या, आणि सर्व्हरने निरीक्षण केलेला स्रोत पत्ता नोंदवा। मग पुढील प्रोफाइल बदल पुन्हा बांधलेल्या लॅबऐवजी एका स्क्रिप्ट रनइतकाच खर्चाचा होईल।