VPN पते से बंधा ऐप फिर भी गलत रूट इस्तेमाल करता है

एक ऐप VPN के पते से बंधता है, और कनेक्शन फिर भी सामान्य डिफ़ॉल्ट रूट से बाहर जाता है। बाइंड में कुछ विफल नहीं हुआ; उसने ठीक वही किया जो बाइंड करता है। सॉकेट को स्थानीय पते से बाँधने पर वह स्रोत पता चुना जाता है जो कर्नेल हेडर में डालता है। यह कोई रूट इंस्टॉल नहीं करता, और ऐसा नीति नियम नहीं बनाता जो उस स्रोत वाले पैकेट किसी विशेष टनल में भेजे।

इस रनबुक का बाकी हिस्सा वही जाँच क्रम है जो मैं उपयोग करता हूँ, साथ में वह कमांड जो हर अवलोकन देती है।

बाइंड वास्तव में क्या तय करता है

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

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

Linux IP सॉकेट संदर्भ बाइंड की अर्थ-व्यवस्था का दस्तावेज़ीकरण करता है। रूटिंग वाला आधा हिस्सा ip-rule और ip-route में रहता है, और वे किसी कारण से अलग मैनुअल हैं।

पुष्टि करें कि पता इस नेमस्पेस का है

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

ip -br addr show
ip netns identify <pid>
ss -tanp | grep <port>

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

उस स्रोत और गंतव्य के लिए लुकअप पढ़ें

एक कमांड उस सवाल का जवाब देती है जो बाइंड ने नहीं दिया:

ip route get 203.0.113.10 from 10.8.0.2
ip rule show

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

फिर ip rule show बताता है कि क्या कोई नियम दूसरी तालिका चुनता। यहाँ प्राथमिकताएँ मायने रखती हैं, क्योंकि पहला मेल खाता नियम जीतता है, और आपके नियम के ऊपर सब कुछ पकड़ने वाला नियम आपके नियम को अदृश्य कर देता है।

नीति नियम तभी लगाएँ जब यही डिज़ाइन हो

स्रोत-आधारित रूटिंग एक सोचा-समझा डिज़ाइन है, एक ऐप के लिए मरम्मत नहीं। अगर नीति का मालिक चाहता है कि टनल सबनेट का ट्रैफ़िक टनल का उपयोग करे, तो नियम उसके कॉन्फ़िगरेशन में है, आपके लैपटॉप पर एक बार की कमांड में नहीं।

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

ip route add default dev tun0 table 100
ip rule add from 10.8.0.2 table 100 priority 100
ip route get 203.0.113.10 from 10.8.0.2

ip rule del और ip route flush table 100 से वापस लें। इस तरह जोड़ा गया सब कुछ रीबूट पर गायब हो जाता है, जब तक कोई प्रबंधक उसे न लिखे; यह एक सुरक्षा गुण भी है और एकमात्र प्रति अपने शेल इतिहास में न रखने का कारण भी।

तीन अवलोकनों से सत्यापित करें

ऐप ने जो स्रोत माँगा, लुकअप ने जो रूट चुना, और सर्वर ने वास्तव में जो स्रोत देखा — तीनों दर्ज करें।

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

अगर ऐप डिवाइस से बाँधने का विकल्प या प्रति-ऐप रूटिंग मोड देता है, तो उसे अलग बाधाओं वाला अलग तंत्र मानें। दिखने में समान सेटिंग्स सभी एक ही कर्नेल निर्णय तक नहीं पहुँचतीं।