दो गेटवे, एक VPN: OpenVPN गलत अपलिंक क्यों चुनता है

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

टनल का पता अंतिम बिंदु नहीं है

हर सत्र में दो अलग रास्ते होते हैं। बाहरी रास्ता एन्क्रिप्टेड ट्रांसपोर्ट को सर्वर के सार्वजनिक पते तक ले जाता है। भीतरी रास्ता वह सब ले जाता है जो सर्वर टनल में धकेलता है, और एक के रूटिंग नियम दूसरे पर कोई असर नहीं डालते।

प्रोफ़ाइल में remote प्रविष्टि बाहरी गंतव्य का नाम बताती है, इसलिए वही पता पिन करना है। यह वह मान भी है जो तब बदलता है जब कोई होस्टनाम अलग तरह से हल हो या प्रोफ़ाइल कई remote की सूची दे।

वह पता खोजें जिस पर क्लाइंट ने वास्तव में डायल किया

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

ss -tunp | grep -i openvpn
journalctl -u openvpn-client@work --no-pager | grep -i "Peer Connection Initiated"

लॉग पंक्ति कनेक्शन के समय पीयर का पता और पोर्ट बताती है। अगर यह प्रोफ़ाइल से मेल नहीं खाती, तो क्लाइंट के आगे कुछ कनेक्शन शुरू होने से पहले गंतव्य को फिर से लिख रहा है।

पता परिवार भी जाँचें। दोहरे स्टैक वाली प्रोफ़ाइल IPv6 से जुड़ सकती है जबकि आपका अपवाद केवल IPv4 को कवर करता है, और तब ट्रैफ़िक आपके लिखे नियम से अलग नियम का पालन करता है। यही बात ऐसे प्रॉक्सी पर लागू होती है जो अंतिम बिंदु की ओर से जवाब देता है। दोनों स्थितियों में ऐसी टनल बनती है जो काम करती है जबकि आपका रूट कुछ नहीं करता।

अंतिम बिंदु पिन करें और नीति का क्रम पढ़ें

होस्ट रूट किसी भी डिफ़ॉल्ट से अधिक विशिष्ट है। इसलिए पीयर पते के लिए /32 उस तालिका में जीतता है जो उसे रखती है। सामान्य रूप गेटवे और डिवाइस को स्पष्ट रूप से बताता है:

ip route add 203.0.113.40/32 via 192.168.10.1 dev eth0

वह रूट तभी मदद करता है जब खोज उस तालिका तक पहुँचे। नीति नियम क्रम में आँके जाते हैं और पहला मेल निर्णय देता है, इसलिए जो नियम सब कुछ दूसरी तालिका में भेजता है वह main में आपके होस्ट रूट को बायपास करता है। रूट को प्रामाणिक मानने से पहले नियम पढ़ें:

ip rule show
ip route get 203.0.113.40

दूसरे आदेश से उसी स्रोत पते या मार्क के साथ पूछें जो क्लाइंट उपयोग करता है, जब नीति उन पर निर्भर हो। यह वह रूट बताता है जिसे कर्नेल चुनेगा, जो खोज के बारे में साक्ष्य है और यह प्रमाण नहीं कि जीवंत सॉकेट उसी रास्ते का उपयोग कर रहा है।

जब अंतिम बिंदु हिलता है

कई पतों पर हल होने वाला होस्टनाम जवाब बदलते ही स्थायी /32 को अमान्य कर देता है। कई remote पंक्तियों वाली प्रोफ़ाइल को भी वही समस्या है, क्योंकि क्लाइंट उनमें से किसी पर भी उतर सकता है। रूट को हाथ से जोड़ने के बजाय क्लाइंट के अपने जीवनचक्र हुक से ताज़ा करें। जो up स्क्रिप्ट बातचीत किए गए पीयर को पढ़ती है और होस्ट रूट स्थापित करती है, वह अपवाद को वास्तविकता के साथ संरेखित रखती है, और मेल खाती down स्क्रिप्ट उसे हटा देती है।

ताज़ाकरण को उसी जगह दर्ज करें जहाँ होस्ट का बाकी रूटिंग कॉन्फ़िगरेशन है। जो रूट केवल अगले रीबूट तक रहता है वह परीक्षण है, समाधान नहीं।

भीतरी नीति अलग रखें

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

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

परिणाम की पुष्टि दो स्वतंत्र अवलोकनों से करें: सॉकेट का स्थानीय पता और डिवाइस, और वह रूट जिस पर निजी गंतव्य हल होता है। जब दोनों आपके इरादे से मेल खाते हैं, तो विभाजन वास्तविक है। OpenVPN 2.6 मैनुअल remote और स्थानीय बाइंडिंग विकल्पों को कवर करता है जो तय करते हैं कि क्लाइंट किस पते पर डायल करेगा।