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 ले फर्काउनुहोस्। यसरी थपिएको सबै कुरा रिबुटमा हराउँछ, जबसम्म कुनै प्रबन्धकले लेख्दैन; यो एकातिर सुरक्षा गुण हो र अर्कोतिर एउटै प्रतिलिपि तपाईंको शेल इतिहासमा नराख्ने कारण।

तीन अवलोकनले प्रमाणित गर्नुहोस्

एपले मागेको स्रोत, खोजीले छानेको रुट, र सर्भरले वास्तवमै देखेको स्रोत लेख्नुहोस्।

यी तीन फरक पर्न सक्छन्, र हरेक भिन्नताले अन्त कतै संकेत गर्छ। टनेल इन्टरफेसमा क्याप्चरले प्याकेट सही स्रोतसँग बाहिर गएको प्रमाणित गर्छ। भौतिक इन्टरफेसमा क्याप्चरले यो गलत बाटोबाट बाहिर गएको प्रमाणित गर्छ। सर्भरपट्टिको दृश्य मात्र त्यो हो जसले बाटोलाई सुरुदेखि अन्तसम्म प्रमाणित गर्छ।

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