VPN रूट ip route के आउटपुट में कोई गेटवे क्यों नहीं दिखाता
इंटरफ़ेस वाली पर गेटवे रहित पंक्ति सीधा रूट है, टूटा हुआ नहीं। गंतव्य, dev और scope पढ़ें, फिर ip route get से पुष्टि करें।
जब भी गेटवे स्तंभ खाली दिखता है, रूटिंग तालिकाओं को टूटा हुआ पढ़ा जाता है, जबकि पंक्ति सामान्यतः अपने आप में पूरी होती है। via फ़ील्ड केवल तब दिखता है जब कर्नेल पैकेट को अगली हॉप के पते पर सौंपता है; किसी इंटरफ़ेस से जुड़ा रूट अपने गंतव्यों तक लिंक-लेयर विश्लेषण या पॉइंट-टू-पॉइंट साथी के ज़रिये पहुँचता है। स्तंभों को बाएँ से दाएँ पढ़ना बताता है कि आप किस स्थिति में हैं, और यह पढ़ना किसी के द्वारा डिफ़ॉल्ट रूट संपादित करने से पहले होना चाहिए। गुम गेटवे के बारे में अधिकांश टिकट इसी अंतर पर समाप्त होते हैं।
रूट पंक्ति को स्तंभ-दर-स्तंभ पढ़ें
प्रत्येक प्रविष्टि गंतव्य और उसकी प्रीफ़िक्स लंबाई से शुरू होती है, फिर स्थिर शब्दावली में संशोधक जोड़ती है: via, dev, proto, scope, src और metric। 198.51.100.0/24 dev tun0 proto kernel scope link src 198.51.100.2 जैसी पंक्ति घनी पर पूरी तरह निर्दिष्ट है। उसमें कुछ भी अनुपस्थित नहीं है, और कोई राउटर पता निहित नहीं है।
via का अनुपस्थित होना दिलचस्प हिस्सा है। अगली हॉप के बिना कर्नेल गंतव्य को सीधे नामित इंटरफ़ेस पर हल करता है, जिसका टनल के लिए अर्थ है फ़्रेम को टनल उपकरण को सौंपना और एन्कैप्सुलेशन को वहाँ से संभालने देना। proto kernel दर्ज करता है कि प्रविष्टि पता सौंपे जाने पर स्वतः स्थापित हुई थी, किसी व्यवस्थापक द्वारा टाइप नहीं की गई। scope link कहता है कि गंतव्य उस लिंक पर राउटर से गुज़रे बिना पहुँचा जा सकता है, और src उस पते का नाम लेता है जिसे कर्नेल मेल खाते ट्रैफ़िक के लिए स्रोत के रूप में पसंद करेगा।
अब डिफ़ॉल्ट रूट उसी तरह पढ़ें: default via 192.0.2.254 dev eth0 proto static metric 100। यहाँ via मौजूद है क्योंकि पैकेट को वास्तव में अगली हॉप चाहिए, और वह हॉप स्वयं eth0 पर पहुँचने योग्य होनी चाहिए। दोनों पंक्तियाँ एक-दूसरे के रूपांतर नहीं हैं; वे इस बारे में अलग-अलग प्रश्नों के उत्तर देती हैं कि ट्रैफ़िक कहाँ जाता है।
दो रूट आकार जिन्हें आपस में मिलाया जाता है
टनल सबनेट रूट और डिफ़ॉल्ट रूट स्क्रीनशॉट में समान दिखते हैं और बिल्कुल अलग व्यवहार करते हैं। नीचे दी तालिका को फ़ील्ड पढ़ने की सहायता के रूप में इस्तेमाल करें, फिर किसी मार्गदर्शिका के नमूने पर भरोसा करने के बजाय जिस मशीन को आप डीबग कर रहे हैं उसी पर वास्तविक संख्याएँ जाँचें।
| Piece of the line | What it settles | What it says nothing about |
|---|---|---|
| The destination and mask | Which packets are eligible to match | Where those packets leave the host |
via plus its address | Which next hop receives them, and therefore that a router is involved | Whether that router is reachable or sane |
dev | Which interface carries the encapsulated or raw packet | Whether the interface is up or has a carrier |
proto and scope | Who installed the entry and how far the destination is considered to be | Whether a firewall later drops the traffic |
तालिका जो नहीं बता सकती वह है मंशा। टनल के ज़रिये निजी श्रेणी तक सीधा रूट जानबूझकर बनाया गया स्प्लिट-टनल डिज़ाइन है; जिस होस्ट को सब कुछ VPN से भेजना चाहिए उस पर वही आकार दिखना एक लक्षण है। मंशा उस कॉन्फ़िगरेशन में रहती है जिसने प्रविष्टि बनाई, इसलिए यह निष्कर्ष निकालने से पहले कि कर्नेल ने कुछ गलत किया, उस उपकरण को देखें जिसने इसे स्थापित किया।
इसी तरह, गुम गेटवे किसी एक को गढ़ने की अनुमति नहीं है। यदि रूट को वास्तव में अगली हॉप चाहिए, तो वह हॉप उस इंटरफ़ेस पर पहुँचने योग्य होनी चाहिए जो उसे वहन करता है, और पॉइंट-टू-पॉइंट टनल के लिए साथी का पता स्थानीय पते जैसी वही वस्तु नहीं है। स्थानीय टनल पते को ईथरनेट राउटर मानना एक सही दिखने वाला पर कुछ भी अग्रेषित न करने वाला रूट बनाने का सामान्य तरीका है।
कर्नेल से पूछें कि वह वास्तव में कौन-सी पंक्ति इस्तेमाल करेगा
तालिका पढ़ना खोज करने के समान नहीं है, क्योंकि उत्तर देने से पहले कर्नेल नीति नियमों, कई तालिकाओं और कैश की गई प्रविष्टियों से परामर्श करता है। वास्तविक खोज करने वाली क्रिया ip route get है, और यह वह रूट छापती है जो उन गुणों वाला पैकेट लेगा।
ip route get 203.0.113.37 from 198.51.100.2 iif tun0जिस गंतव्य की आपको वास्तव में परवाह है उसे रखें, फिर जब ट्रैफ़िक स्रोत के आधार पर चुना जाए या अग्रेषित किया जाए तो from या iif जोड़ें, क्योंकि साधारण स्थानीय खोज अग्रेषित क्लाइंट से अलग पथ चुन सकती है। उत्तर इंटरफ़ेस, चुना गया स्रोत पता और कोई भी अगली हॉप बताता है, जो उस क्षण पैकेट को रूट करने में इस्तेमाल होने वाली वही जानकारी है।
यदि उत्तर आपको चौंकाए, तो कुछ भी बदलने से पहले नियम छापें: ip -4 rule show उन्हें प्राथमिकता क्रम में सूचीबद्ध करता है, और जो VPN क्लाइंट अपनी तालिका या चिह्नित पैकेटों के लिए नियम स्थापित करता है वह मुख्य तालिका में बिल्कुल नहीं दिखेगा। हर तालिका सूचीबद्ध करना उस खाई को भरता है।
ip -4 route show table all | grep -E 'tun|default'डिफ़ॉल्ट बदलने से पहले अंडरले जाँचें
टनल के अपने पैकेटों को दूरस्थ एंडपॉइंट तक पहुँचना है, और वे ऐसा भौतिक इंटरफ़ेस से उस रूट का उपयोग करके करते हैं जो VPN आने से पहले मौजूद था। उस एंडपॉइंट को पिन किए बिना पूरा डिफ़ॉल्ट रूट बदलने से एन्कैप्सुलेटेड पैकेट उसी टनल में चले जाते हैं जिसे उन्हें बनाना था, और कनेक्शन ढह जाता है। पहले केवल एंडपॉइंट पते की खोज से एंडपॉइंट का पथ पुष्ट करें।
बदलाव करते समय तीन चीज़ें अलग रखें: एंडपॉइंट का रूट जो भौतिक इंटरफ़ेस पर रहना चाहिए, निजी श्रेणियाँ जिन्हें टनल में जाना चाहिए, और डिफ़ॉल्ट जो बाकी सब तय करता है। उन्हें इसी क्रम में अलग करें, एक बार में एक लागू करें, और हर चरण के बाद खोज दोबारा चलाएँ। बाद में विफल पिंग अपने आप में बहुत कम साबित करता है, क्योंकि अनुमतियाँ, उत्तर रूटिंग, DNS और सेवा स्वयं सभी सही रूट के नीचे की ओर बैठे हैं।
संपादन से पहले पंक्ति ने आपको जो चार मान दिए उन्हें लिख लें: गंतव्य, अगली हॉप या उसका अभाव, उपकरण, और चुना गया स्रोत। यदि बाद का कोई बदलाव उनमें से किसी को हिलाए, तो आप जानते हैं कि कौन-सा निर्णय वास्तव में बदला, और पूरी तालिका का अनुमान लगाने के बजाय एक प्रविष्टि बहाल कर सकते हैं।