आपका पुराना डिफ़ॉल्ट रूट OpenVPN के बाद भी जानबूझकर टिका रहता है

आप टनल से जुड़ते हैं, ip route चलाते हैं, और मूल डिफ़ॉल्ट गेटवे अब भी वहीं मौजूद है। अगला विचार यह आता है कि क्लाइंट ने रूट नहीं संभाला, इसलिए आप डिफ़ॉल्ट को हाथ से हटा देते हैं और कनेक्टिविटी पूरी तरह खो देते हैं। वह प्रविष्टि रहनी चाहिए। redirect-gateway def1 के साथ OpenVPN दो अधिक विशिष्ट रूट लगाता है जो साधारण डिफ़ॉल्ट को बदलने के बजाय उससे ऊपर रहते हैं। पुराना गेटवे रहता है और जिस ट्रैफ़िक का आप परीक्षण कर रहे थे, उसे ले जाना बंद कर देता है।

def1 वास्तव में क्या करता है

यह फ़्लैग 0.0.0.0/1 और 128.0.0.0/1 जोड़ता है, दोनों टनल की ओर। 0.0.0.0/1 हर उस पते को लेता है जिसका पहला ऑक्टेट 0 से 127 तक है, और 128.0.0.0/1 128 से 255 तक लेता है, इसलिए हर IPv4 गंतव्य के पास पुराने डिफ़ॉल्ट से अधिक विशिष्ट मेल होता है। कौन-सा रूट जीतेगा, यह मीट्रिक नहीं, प्रीफ़िक्स की लंबाई तय करती है।

मूल डिफ़ॉल्ट को उसकी जगह रखना जानबूझकर है। क्लाइंट को याद नहीं रखना पड़ता कि उसने क्या बदला, और वह उस रूट को फिर से नहीं लिखता जो VPN सर्वर से अपना कनेक्शन ले जाता है। डिस्कनेक्ट पर यह दो आधे रूट हटा देता है और तालिका पहले जैसी हो जाती है।

क्यों /1 और /0 नहीं

रूटिंग सबसे लंबा मिलता प्रीफ़िक्स चुनती है, सबसे कम मीट्रिक नहीं, इसलिए डिफ़ॉल्ट की मीट्रिक कुछ भी कहे, /1 /0 को हरा देता है। दोनों आधे इसलिए हैं क्योंकि एक /1 केवल आधा स्थान ढकता है; केवल 0.0.0.0/1 मौजूद होने पर 128.0.0.0 से ऊपर का सब कुछ अभी भी पुराने डिफ़ॉल्ट का पालन करता है, जिससे वह भ्रमित करने वाला लक्षण बनता है जहाँ कुछ साइटें काम करती हैं और कुछ नहीं।

पुराने डिफ़ॉल्ट की मीट्रिक बढ़ाने या घटाने से कुछ नहीं बदलता, और दूसरे इंटरफ़ेस पर कम मीट्रिक वाला डिफ़ॉल्ट भी ट्रैफ़िक नहीं चुराता। पहले प्रीफ़िक्स की लंबाई तय करती है, और केवल बराबर प्रीफ़िक्स ही मीट्रिक पर लौटते हैं।

एक वास्तविक रूटिंग तालिका पढ़ें

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

default via 192.168.50.1 dev wlan0
0.0.0.0/1 via 10.8.0.1 dev tun0
128.0.0.0/1 via 10.8.0.1 dev tun0

महत्वपूर्ण संबंध है: एक सामान्य डिफ़ॉल्ट के ऊपर दो विशिष्ट आधे। पुराने गेटवे की पंक्ति रहती है क्योंकि किसी ने उसे नहीं बदला।

जाँचें कि पैकेट वास्तव में कौन-सा रूट लेता है

अधिक विशिष्ट रूट अब भी जीत सकते हैं: निजी रेंज, स्थानीय सबनेट के लिए रूट या VPN सर्वर का अपना पता /1 से लंबा है। टनल को अपने सर्वर तक बाहरी रास्ता चाहिए, और उस कनेक्शन को वापस टनल में भेजना उसे तुरंत तोड़ देगा। Linux पर तालिका आँखों से पढ़ने के बजाय कर्नेल से पूछें: जिस गंतव्य में आपकी रुचि है उसके साथ ip route get चुना गया रूट, इंटरफ़ेस और स्रोत छापता है। अगर नीति-आधारित रूटिंग कॉन्फ़िगर है, तो नियम भी देखें, क्योंकि कोई नियम मुख्य तालिका देखे जाने से पहले दूसरी तालिका चुन सकता है।

अगर IPv4 का केवल एक हिस्सा गलत व्यवहार करता है, तो पुष्टि करें कि दोनों आधे इंस्टॉल हैं और फिर विफल गंतव्य से मेल खाने वाला अपवाद खोजें। पुराने डिफ़ॉल्ट को हटाना समाधान नहीं है, और यह वह रूट हटा देता है जिसकी क्लाइंट को टनल साफ़ तरीके से खोलने के लिए ज़रूरत होती है।

def1 क्या कवर नहीं करता

दो IPv4 प्रविष्टियाँ IPv6 के बारे में कुछ नहीं कहतीं: IPv6 कनेक्टिविटी वाला होस्ट अपना डिफ़ॉल्ट तब तक इस्तेमाल करता रहता है जब तक कोई उस परिवार को अलग से न मोड़े, इसीलिए दोहरे स्टैक वाले नेटवर्क पर कुछ ट्रैफ़िक टनल को बचता हुआ दिखता है। अन्य क्लाइंट और नेटवर्क प्रबंधक पूर्ण-टनल रूटिंग अलग तरह से लागू करते हैं, और उनकी तालिकाएँ मेल नहीं खाएँगी। यहाँ वर्णित def1 व्यवहार OpenVPN के प्रलेखित फ़्लैग का है, मशीन पर हर VPN का नहीं।

किल स्विच एक अलग सवाल का जवाब देता है: टनल गिरने पर मशीन क्या करती है। रूट प्राथमिकता तय करती है कि टनल चालू रहने पर ट्रैफ़िक कहाँ जाएगा; यह नहीं तय करती कि बाद में फ़ायरवॉल क्या करेगा। काम का क्रम: तालिका पढ़ें, पुष्टि करें कि दोनों आधे मौजूद हैं, विफल गंतव्य के लिए ip route get चलाएँ, नीति नियम देखें, फिर IPv6 को अलग से देखें। पुराने डिफ़ॉल्ट को जहाँ है वहीं रहने दें।