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 ने मागे घ्या. अशा प्रकारे जोडलेले सर्व काही रीबूटवर नाहीसे होते, जोपर्यंत व्यवस्थापक ते लिहीत नाही; हा एक सुरक्षा गुणधर्म आहे आणि एकमेव प्रत तुमच्या शेल इतिहासात न ठेवण्याचे कारणही.

तीन निरीक्षणांनी पडताळा

अ‍ॅपने मागितलेला स्रोत, लुकअपने निवडलेला मार्ग आणि सर्व्हरने प्रत्यक्षात पाहिलेला स्रोत नोंदवा.

हे तीन वेगळे पडू शकतात, आणि प्रत्येक फरक वेगळ्या ठिकाणी निर्देश करतो. टनेल इंटरफेसवरील कॅप्चर पॅकेट योग्य स्रोतासह बाहेर पडल्याचे सिद्ध करते. भौतिक इंटरफेसवरील कॅप्चर ते चुकीच्या मार्गाने बाहेर पडल्याचे सिद्ध करते. मार्ग सुरुवातीपासून शेवटपर्यंत सिद्ध करते ते फक्त सर्व्हरच्या बाजूचे दृश्य.

अ‍ॅप डिव्हाइसशी बांधण्याचा पर्याय किंवा प्रति-अ‍ॅप मार्गनिर्देशन मोड देते असेल, तर तो वेगळ्या मर्यादा असलेली वेगळी यंत्रणा म्हणून पाहा. दिसायला सारखी सेटिंग्ज सर्व एकाच कर्नेल निर्णयापर्यंत पोहोचत नाहीत.