OpenVPN के ज़रिए सार्वजनिक प्रीफ़िक्स: वापसी का रास्ता ठीक करें

देखें कि टनल ऊपर आता है और क्लाइंट दूसरी तरफ़ पिंग करता है, और फिर VPN के पीछे का कोई सार्वजनिक पता कहीं और से जवाब देता है, या बिलकुल नहीं। इस लक्षण का आम तौर पर साइफ़र या सर्टिफ़िकेट से कोई संबंध नहीं होता। प्रोवाइडर द्वारा राउट किया गया प्रीफ़िक्स IP रूट के रूप में पहुँचाया जाता है, और उसे OpenVPN से ले जाने का मतलब है उस रूट को दो स्तरों पर फिर से बनाना और वापसी के रास्ते पर स्रोत पता बनाए रखना। WAN को ब्रिज करने की ज़रूरत नहीं है, और पते को किसी इंटरफ़ेस में जोड़ने से ऊपरी रूट नहीं बनता।

प्रीफ़िक्स को पहले आपकी ओर राउट होना चाहिए

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

अगर प्रोवाइडर 198.51.100.64/28 को आपके एंट्री सर्वर पर राउट करता है, तो उस रेंज के पैकेट सर्वर पर आते हैं और वहीं रुक जाते हैं जब तक कि आप उन्हें फ़ॉरवर्ड न करें। अगर प्रोवाइडर इसके बजाय रेंज को आपके अपलिंक पर ब्रिज करता है, तो सर्वर को उसके लिए ARP का जवाब देना होगा, जो एक अलग समस्या है।

OpenVPN को छूने से पहले डिलीवरी मॉडल जाँचें: बाहर से ब्लॉक के किसी पते को पिंग करें और देखें कि कौन-सा इंटरफ़ेस उसे प्राप्त करता है। अगर कुछ नहीं आता, तो कोई भी टनल कॉन्फ़िगरेशन मदद नहीं करेगा। अगर पता WAN पर सीधे जवाब देता है, तो प्रोवाइडर राउट करने के बजाय ब्रिज कर रहा है, और नीचे की डिज़ाइन लागू नहीं होती।

दो राउटिंग स्तर: कर्नेल रूट और iroute

OpenVPN को प्रीफ़िक्स दो जगहों पर चाहिए। कर्नेल को पता होना चाहिए कि प्रीफ़िक्स टनल डिवाइस का है, ताकि फ़ॉरवर्ड किए गए पैकेट डिफ़ॉल्ट रूट के बजाय OpenVPN में प्रवेश करें। OpenVPN को यह भी पता होना चाहिए कि कौन-सा प्रमाणित क्लाइंट प्रीफ़िक्स का मालिक है, और वह क्लाइंट-विशिष्ट डायरेक्टरी में iroute प्रविष्टि है।

सर्वर-साइड रूट ऐसा दिखता है, जिसमें प्रीफ़िक्स और मास्क आवंटन से मेल खाने चाहिए:

ip route add 198.51.100.64/28 dev tun0

क्लाइंट-विशिष्ट कॉन्फ़िगरेशन स्वामित्व सौंपता है। इसे उस CCD फ़ाइल में रखें जिसका नाम क्लाइंट सर्टिफ़िकेट के सामान्य नाम पर है, और पुष्टि करें कि वही डायरेक्टरी है जिसे सर्वर वास्तव में पढ़ता है:

iroute 198.51.100.64 255.255.255.240

OpenVPN का राउट किए गए नेटवर्क पर दस्तावेज़ दोनों स्तरों और उनके अलग होने का कारण बताता है। iroute के बिना कर्नेल रूट पैकेटों को बिना मालिक के टनल में भेजता है, और OpenVPN उन्हें गिरा देता है। कर्नेल रूट के बिना iroute पैकेटों को सर्वर के डिफ़ॉल्ट रास्ते पर छोड़ देता है। दोनों गलतियाँ क्लाइंट की तरफ़ से टूटी टनल जैसी दिखती हैं।

सेवा पता कहाँ रहता है

डेलीगेट किया गया प्रीफ़िक्स टनल के अपने पतों जैसा नहीं है। चाहें तो लिंक को निजी स्पेस से नंबर करें, और सार्वजनिक सेवा पता वहाँ रखें जहाँ सेवा वास्तव में चलती है।

जो Linux क्लाइंट सेवा को स्थानीय रूप से समाप्त करता है, उस पर एक ही होस्ट पता पर्याप्त है:

ip address add 198.51.100.70/32 dev lo

अगर प्रीफ़िक्स आगे किसी VM होस्ट या दूसरे LAN की ओर राउट होता है, तो इसके बजाय उस डाउनस्ट्रीम रास्ते और उसके वापसी रूट को कॉन्फ़िगर करें। ब्लॉक के हर पते को VPN क्लाइंट को सौंपना ज़रूरी नहीं है और बाद में टकराव पैदा करता है।

वापसी के रास्ते पर सार्वजनिक स्रोत रखें

डेलीगेट किए गए प्रीफ़िक्स से जवाब को टनल से बाहर निकलकर प्रोवाइडर के रूट तक पहुँचना चाहिए। अगर दूर का होस्ट इसे अपने ISP से भेजता है, तो स्रोत पता नक़ली लगता है, और प्रोवाइडर या गंतव्य उसे गिरा देता है। समाधान है स्रोत-आधारित नियम या समर्पित राउटिंग तालिका, न कि ज़्यादा चौड़ा NAT। इसके बिना सेवा टनल साथी से काम करती है और बाकी हर जगह से विफल होती है।

एंट्री सर्वर पर चौड़ा masquerade नियम आम दोषी है। यह सार्वजनिक स्रोत को सर्वर के मुख्य पते में बदल देता है, और क्लाइंट असली कभी नहीं देखता:

iptables -t nat -S POSTROUTING

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

भरोसा करने से पहले दोनों दिशाएँ जाँचें

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

कर्नेल से पूछें कि डेलीगेट किया गया पता कौन-सा रास्ता लेता है, और अनुरोध चलते समय टनल को देखें:

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

रिवर्स-पाथ फ़िल्टरिंग सही रूट को रद्द कर सकती है। टनल पर और अपलिंक पर प्रभावी सेटिंग जाँचें, और याद रखें कि सख़्त मोड उस ट्रैफ़िक को अस्वीकार करता है जिसका स्रोत उस इंटरफ़ेस से मेल नहीं खाता जिस पर वह आया:

sysctl net.ipv4.conf.tun0.rp_filter net.ipv4.conf.eth0.rp_filter

अंत में, विफलता का मामला जाँचें। टनल रोकें और पुष्टि करें कि सार्वजनिक प्रीफ़िक्स सामान्य अपलिंक से लीक नहीं होता। VPN बहाल करने से सेवा वापस आनी चाहिए, बिना यह बढ़ाए कि होस्ट कौन-से पोर्ट खोलता है।