राउटिङ तालिका विरुद्ध वास्तविक खोज: VPN ट्राफिक कहाँ जान्छ

राउटिङ तालिकाको डम्प VPN समस्या समाधानमा सबैभन्दा कम उपयोगी निदान हो र सबैभन्दा धेरै पेस्ट गरिने। चालीस लाइन प्रिफिक्सले तपाईंलाई मेसिनले के गर्न सक्थ्यो भन्छ, असफल अनुरोधका लागि के गर्यो भनेर होइन। तपाईंले वास्तवमा चाहेको संयन्त्र खोज हो: यो स्रोत र यो गन्तव्य दिइएको अवस्थामा कुन नियम मिल्यो, कुन तालिका हेरियो, र कुन इन्टरफेस र अर्को हप बाहिर आयो। एउटा गन्तव्य र एउटा स्रोतबाट सुरु गर्नुहोस्, त्यसपछि त्यो प्रश्न हातमा लिएर तालिका पढ्नुहोस्, र त्यही आउटपुट हल्लाखल्लाको सट्टा प्रमाण बन्छ।

तालिका उम्मेदवारहरूको समूह हो, निर्णय होइन

प्रत्येक प्रविष्टिले प्रिफिक्स र त्यससँग मिल्ने ट्राफिकसँग के गर्ने भनेर वर्णन गर्छ: त्यसलाई इन्टरफेसमा पठाउनुहोस्, अर्को हपलाई दिनुहोस्, वा खारेज गर्नुहोस्। त्यो सूचीमा केही पनि उद्देश्यअनुसार क्रमबद्ध छैन, र मानिसलाई सबैभन्दा विशिष्ट देखिने प्रविष्टि सधैं कर्नेलले छान्ने प्रविष्टि हुँदैन, किनकि छनोटले सबैभन्दा लामो प्रिफिक्स मिलान र समान प्रिफिक्सहरूबीच मेट्रिकलाई पछ्याउँछ।

त्यसैले पहिलो कदम सूची पढ्नुको सट्टा कर्नेललाई सोध्नु हो। खोज आदेशले गन्तव्यका लागि जवाफ दिन्छ, र स्रोत आर्गुमेन्टसँग फर्वार्ड गरिएको वा बाइन्ड गरिएको जडानले प्रयोग गर्ने ठ्याक्कै जोडीका लागि जवाफ दिन्छ:

ip route get 198.51.100.10
ip route get 198.51.100.10 from 10.80.0.25
ip -6 route get 2001:db8:10::40

माथिका प्रत्येक ठेगाना दस्तावेजीकरणको उदाहरण हो। मुख्य कुरा जवाफको आकार हो: इन्टरफेस, छनोट गरिएको स्रोत ठेगाना, गेटवे, र प्रविष्टि आएको तालिका। यदि त्यो आउटपुट तपाईंले अपेक्षा गरेको इन्टरफेससँग मिल्दैन भने, तपाईंले एउटै आदेशमा समस्या पहिचान गर्नुभयो, र पूरै तालिका पढेर पनि कुन उम्मेदवार जित्यो भन्ने थाहा हुँदैनथ्यो।

खोज पहिले नियमहरूबाट, त्यसपछि तालिकाहरूबाट जान्छ

Linux मा निर्णय दुई चरणमा हुन्छ। नीति नियमहरू प्राथमिकता क्रममा मूल्याङ्कन गरिन्छ, र पहिलो मिल्ने नियमले परामर्श गर्ने तालिकाको नाम दिन्छ; त्यो तालिकाले त्यसपछि सबैभन्दा लामो प्रिफिक्स मिलान गर्छ। नियम स्रोत, गन्तव्य, फायरवाल मार्क, इन्टरफेस वा तिनको संयोजनमा मिल्न सक्छ, त्यसैले मुख्य तालिकाको डम्प पूर्ण रूपमा सही र तपाईंले अनुसन्धान गरिरहेको प्याकेटका लागि पूर्ण रूपमा अप्रासंगिक हुन सक्छ।

ip rule show
ip route show table all | head -40
ip route show table 100

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

IPv6 का आफ्नै नियम र तालिकाहरू छन्। दुवै परिवार चलाउने डिजाइनलाई दुवै खोज चाहिन्छ, र काम गर्ने IPv4 जवाफले v6 बाटोबारे केही भन्दैन जुन दोहोरो-स्ट्याक क्लाइन्टले रुचाउन सक्छ।

VPN क्लाइन्टले के स्थापना गर्छ

क्लाइन्टहरू सामान्यतया पूर्वनिर्धारित रुट परिवर्तन गर्दैनन्, किनकि त्यसले सुरुङको आफ्नै बाहिरी बाटो तोड्छ। तिनीहरू अझ विशिष्ट कुरा स्थापना गर्छन् जुन प्रिफिक्स लम्बाइले जित्छ: 0.0.0.0/1 र 128.0.0.0/1 ढाक्ने आधा-पूर्वनिर्धारित जोडी क्लासिक चाल हो, किनकि दुवै 0.0.0.0/0 भन्दा लामा प्रिफिक्स हुन् र सँगै सम्पूर्ण स्थान ढाक्छन्। अरूले विशिष्ट निजी प्रिफिक्स र नीति नियम स्थापना गर्छन्, र केहीले छानिएको ट्राफिक मात्र समातिने गरी मार्क थप्छन्।

त्यसैले "VPN ले मेरो पूर्वनिर्धारित रुट परिवर्तन गरेन" असफलताको प्रमाण होइन। यसले वास्तवमा के थप्यो, र प्रश्नमा रहेको गन्तव्य ती प्रिफिक्सभित्र पर्छ कि पर्दैन जाँच्नुहोस्:

ip route show | grep -E 'tun|wg|ppp|ipsec'
ip route get 10.20.30.40 from 10.80.0.25

डम्पमा दुई आधा-रुट सजिलै छुट्न सक्छन् किनकि तिनीहरू पूर्वनिर्धारितजस्तो देखिँदैनन्। प्रिफिक्स समावेश गर्न बिर्सेको स्प्लिट-टनेल कन्फिगरेसनले तपाईंले खोजिरहेको लक्षण ठ्याक्कै उत्पन्न गर्छ: सुरुङ प्रयोग गर्नुपर्ने अनुप्रयोगले बरु स्थानीय रूपमा समाधान गरी जोडिन्छ। स्थापित प्रिफिक्सहरूलाई प्रयोगकर्तालाई वास्तवमा आवश्यक गन्तव्यसँग तुलना गर्नुहोस्, तपाईंले संयोगवश परीक्षण गरेका ठेगानासँग होइन। फाइल सर्भर ढाक्ने तर त्यसको रिजोल्भर नढाक्ने स्प्लिट-टनेल सूचीले सार्वजनिक ठेगानामा समाधान हुने र त्यसपछि प्रमाणीकरणमा असफल हुने जडान उत्पन्न गर्छ, जुन पासवर्ड समस्याजस्तो देखिन्छ तर बाटोको समस्या हो।

बाहिरी रुट पनि बाँच्नुपर्छ

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

भित्री गन्तव्य जाँचेझैं पीयरको ठेगाना जाँच्नुहोस्, र त्यो सुरुङमा होइन, भौतिक इन्टरफेसमा समाधान हुन्छ भनी पुष्टि गर्नुहोस्:

ip route get 203.0.113.10
traceroute -n -m 5 203.0.113.10

पुनरावृत्ति रुट, पीयर समात्ने नीति नियम, वा पूर्ण-सुरुङ क्लाइन्टले प्रतिस्थापन गरेको पूर्वनिर्धारित तीन सामान्य कारण हुन्। तीनवटै बाहिरी खोजमा देखिन्छन्, र घटनापछि लिइएको मुख्य तालिकाको डम्पमा कुनै पनि देखिँदैन।

राउटिङ आउटपुटले तपाईंलाई के भन्न सक्दैन

सही खोजको अर्थ कर्नेलले प्याकेटलाई कतै उपयुक्त ठाउँमा पठाउँछ। यसको अर्थ फायरवालले अनुमति दिन्छ, IPsec नीतिले ढाक्छ, NAT नियमले अनुवाद गर्छ, वा दूरको पक्षसँग फर्कने रुट छ भन्ने होइन। तीमध्ये प्रत्येक पछिल्लो चरण हो, र strongSwan का फर्वार्डिङ नोटहरू ले प्याकेटले दुवै छेउमा पार गर्नुपर्ने शृंखलाको वर्णन गर्छन्।

यसले अनुप्रयोग-स्तरीय बाइन्डिङ पनि विचार गर्दैन। कुनै प्रक्रियाले इन्टरफेसमा बाइन्ड हुन, मार्क सेट गर्न, वा आफ्नै रिजोल्भर प्रयोग गरी तपाईंले परीक्षण गरेभन्दा फरक तरिकाले समाधान हुने नामबाट जोडिन सक्छ। जब खोज सही छ र जडान अझै असफल हुन्छ, अर्को प्रश्न कुन प्रक्रियाले त्यो गरिरहेको छ र त्यो प्रक्रियाले तपाईंले देखेको त्यही तालिका देख्छ कि देख्दैन भन्ने हो।

त्यसैले निदान क्रममा राख्नुहोस्: गन्तव्य र स्रोतको नाम दिनुहोस्, खोज चलाउनुहोस्, खोजले नाम दिएको तालिका र नियम मात्र पढ्नुहोस्, त्यसपछि अर्को चरण परीक्षण गर्नुहोस्। त्यो क्रमले राउटिङ अनुसन्धानलाई मिनेटभित्र राख्छ र अरूले पछ्याउन सक्ने अभिलेख छोड्छ, जुन पेस्ट गरिएको तालिकाले कहिल्यै गर्दैन।