रूटिंग तालिका बनाम वास्तविक लुकअप: 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 की फ़ॉरवर्डिंग टिप्पणियाँ उस शृंखला का वर्णन करती हैं जिससे पैकेट को दोनों सिरों पर गुज़रना होता है।

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

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