host-only नेटवर्क पर VM ट्रैफ़िक को TUN OpenVPN सर्वर से रूट करें

host-only एडाप्टर स्थानीय वर्चुअल नेटवर्क बनाते हैं, और रूट किए गए TUN टनल पतों के बीच IP पैकेट ले जाते हैं। इनमें से कोई भी दूसरे के लिए ब्रिज नहीं है, इसलिए काम करने वाली कॉन्फ़िगरेशन को बताना होगा कि कौन फ़ॉरवर्ड करता है और वापसी रूट किसका है। ये दो ज़िम्मेदारियाँ गलत मिलीं तो गेस्ट टनल को ऐसे स्रोत से जवाब देता है जो टनल क्लाइंट ने कभी नहीं माँगा। नीचे का डिज़ाइन दोनों प्रीफ़िक्स अलग रखता है और वापसी का रास्ता स्पष्ट करता है।

दो नेटवर्क, दो प्रीफ़िक्स

टनल पूल और host-only नेटवर्क को अलग-अलग प्रीफ़िक्स दें और कभी एक को दूसरे के लिए दोबारा इस्तेमाल न करें। इस उदाहरण में VPN पूल 10.44.0.0/24 है और host-only नेटवर्क 192.168.99.0/24 है, होस्ट 192.168.99.1 पर और एक गेस्ट 192.168.99.20 पर। एक ही प्रीफ़िक्स TUN डिवाइस और host-only एडाप्टर दोनों को देने से वे जुड़ते नहीं। यह एक पता-सीमा पर दो दावे बनाता है, और रूटिंग टेबल तब उसी दावे का पक्ष लेती है जो उसने संयोग से रखा था।

host-only एडाप्टर होस्ट पर और गेस्ट के अंदर दोनों जगह मौजूद रहता है, और उसके पास खुद से मशीन से बाहर जाने का कोई रास्ता नहीं है। ब्रिज और NAT कनेक्शन का जोखिम अलग होता है, और एक गेस्ट सेवा तक पहुँचने के लिए ब्रिज मोड में जाना ज़रूरी नहीं है।

होस्ट के पास रास्ता पहले से है

कुछ जोड़ने से पहले देखें कि क्या मौजूद है। होस्ट के पास host-only नेटवर्क पर एक इंटरफ़ेस और उस प्रीफ़िक्स के लिए एक रूट है, दोनों एडाप्टर के उठते ही बने थे।

ip -br addr show
ip route show 192.168.99.0/24
sysctl net.ipv4.ip_forward

तीसरी पंक्ति वही तंत्र है जो होस्ट को एक हॉप बनाता है। इसके बिना, टनल से आने वाला पैकेट ऐसे नेटवर्क पर पता पाता है जहाँ होस्ट पहुँच सकता है पर फ़ॉरवर्ड नहीं करेगा। फ़ॉरवर्डिंग ज़रूरी है और पर्याप्त नहीं। फ़िल्टर नीति अभी भी तय करती है कि टनल इंटरफ़ेस और host-only इंटरफ़ेस के बीच कोई ख़ास प्रवाह मंज़ूर है या नहीं, और वह फ़ैसला लिखित होना चाहिए, किसी ऐसी डिफ़ॉल्ट नीति में नहीं जिसे किसी ने नहीं पढ़ा।

रूट पुश करें, फिर जो वह पहुँचता है उसे फ़िल्टर करें

सर्वर उन क्लाइंट को host-only प्रीफ़िक्स दे सकता है जो पुश किए गए रूट स्वीकार करते हैं, जो टनल के पीछे के किसी भी सबनेट के लिए इस्तेमाल होने वाला वही तंत्र है।

push "route 192.168.99.0 255.255.255.0"
iptables -A FORWARD -i tun0 -o vboxnet0 -d 192.168.99.20 -p tcp --dport 5432 -j ACCEPT
iptables -A FORWARD -i vboxnet0 -o tun0 -s 192.168.99.20 -p tcp --sport 5432 -m conntrack --ctstate ESTABLISHED -j ACCEPT

वे दो नियम एक दिशा में एक सेवा और उसके जवाबों को मंज़ूरी देते हैं। पूरे प्रीफ़िक्स तक पहुँचने वाला रूट और एक पोर्ट मंज़ूर करने वाला फ़िल्टर जानबूझकर बना संयोजन है; रूट के साथ बिना शर्त स्वीकृति वह रास्ता है जिससे प्रयोगशाला की सेवा खुली सेवा बन जाती है। पुश किया गया रूट भी अनुमति नहीं है। क्लाइंट उसे स्वीकार करता है, होस्ट उसे फ़ॉरवर्ड करता है, और गेस्ट फ़ायरवॉल तथा सेवा खुद अब भी राय रखते हैं।

गेस्ट को लौटने का रास्ता चाहिए

10.44.0.x से पहुँचाए जाने वाले गेस्ट को अपने जवाब होस्ट के host-only पते पर भेजने होंगे, या होस्ट को स्रोत का अनुवाद करना होगा। VirtualBox DHCP से पता मिलना इन दोनों में से किसी भी व्यवस्था के बारे में कुछ नहीं कहता।

ip route add 10.44.0.0/24 via 192.168.99.1 dev enp0s8
ip route get 10.44.0.15

गेस्ट के अंदर वह रूट जोड़ने से मूल स्रोत बना रहता है, जो हर क्लाइंट की नीति और लॉग को अर्थपूर्ण रखता है। होस्ट पर सीमित स्रोत अनुवाद विकल्प है, और वह काम करता है, पर यह छिपाने की क़ीमत पर कि कौन सा क्लाइंट जुड़ा। ओवरलैप दूसरी विफलता का तरीका है। जिसका घरेलू LAN पहले से 192.168.99.0/24 इस्तेमाल करता है, ऐसा दूर का क्लाइंट पुश किए गए रूट को अपना नेटवर्क पढ़ेगा, और सर्वर की ओर कोई भी बदलाव उस अस्पष्टता को नहीं सुधारता। एक ओर को फिर से नंबर दें या ऐसा प्रीफ़िक्स चुनें जिसके टकराने की संभावना कम हो।

TUN डिवाइस IP पैकेट ले जाता है, इसलिए गेस्ट के अंदर डिफ़ॉल्ट गेटवे जोड़ने से टनल host-only एडाप्टर के साथ ईथरनेट सेगमेंट नहीं बन जाता। TAP ब्रिजिंग अलग डिज़ाइन है जिसका अपना क्लाइंट समर्थन और पता-स्वामित्व है, और दोनों विवरण मिलाने से ऐसी कॉन्फ़िगरेशन बनती है जो कभी नहीं मिलती।

सत्यापित करें, फिर इसे रीस्टार्ट में टिकने लायक बनाएँ

सामान्य दूर के क्लाइंट से एक हानिरहित सेवा जाँचें, गेस्ट का वापसी रूट देखें, और पुष्टि करें कि जिस सेवा को आपने मंज़ूर नहीं किया वह धीमी नहीं बल्कि अस्वीकार होती है।

ss -lntp '( sport = :5432 )'
conntrack -L | grep 192.168.99.20

फिर VPN सेवा और वर्चुअल मशीन की नेटवर्किंग रीस्टार्ट करें और वही तीन जाँचें दोहराएँ। हाथ से जोड़ा गया रूट अगले रीबूट तक टिकता है, और जो कॉन्फ़िगरेशन केवल गरम सत्र में काम करे वह डिज़ाइन नहीं है। दोनों प्रीफ़िक्स, फ़ॉरवर्डिंग नीति और गेस्ट रूट एक साथ दर्ज करें। अगली वर्चुअल मशीन जोड़ने वाले को तीनों चाहिए होंगे और वरना वह हर विफल कनेक्शन पर उन्हें फिर से खोजता रहेगा।