एक सबनेट अब भी आपके VPN डिफ़ॉल्ट रूट को क्यों बायपास करता है

आप VPN को पूर्ण टनल पर स्विच करते हैं, ज़्यादातर ट्रैफ़िक मानता है, और फिर एक पता सीधे जवाब देता है — एक प्रिंटर, NAS, 10.x पर जंप होस्ट। स्पष्ट पाठ यह है कि टनल लीक कर रही है, इसलिए आप डिफ़ॉल्ट रूट पर मीट्रिक कम करते हैं और कुछ नहीं बदलता। वही असफल प्रयास सुराग है: डिफ़ॉल्ट रूट एक फ़ॉलबैक है, फ़ैसला नहीं। रूट लुकअप मीट्रिक की तुलना करने से पहले ही सबसे लंबा मेल खाता प्रीफ़िक्स लेता है, इसलिए /24 किसी भी संख्या के साथ /0 के ख़िलाफ़ जीतता रहता है। एक बार यह क्रम स्पष्ट हो जाने पर, लीक आम तौर पर कोई ऐसा रूट होता है जिसे किसी ने जानबूझकर इंस्टॉल किया, या ऐसा प्रीफ़िक्स जिसे क्लाइंट ने कभी ढकने का इरादा नहीं किया।

डिफ़ॉल्ट रूट वास्तव में क्या वादा करता है

0.0.0.0/0 हर IPv4 गंतव्य से शून्य बिट विशिष्टता के साथ मेल खाता है। यह इसलिए है ताकि होस्ट वह सब तक पहुँच सके जिसे उसकी तालिका बेहतर ढंग से नहीं बताती। 192.168.1.0/24 तक का रूट 24 मेल खाते बिट ले जाता है, इसलिए 192.168.1.40 के लिए यह किसी के मीट्रिक, प्रशासनिक दूरी या क्लाइंट जिसे प्राथमिकता फ़ील्ड कहता है, उसकी तुलना करने से पहले ही जीत जाता है। यही नियम Linux FIB, Windows रूटिंग तालिका और macOS के पीछे BSD स्टैक में लागू होता है।

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

आधे-डिफ़ॉल्ट, या डिफ़ॉल्ट प्रविष्टि अछूती क्यों दिख सकती है

सबसे साफ़ उदाहरण redirect-gateway def1 OpenVPN में है। आपके डिफ़ॉल्ट को हटाकर बदलने के बजाय, यह 0.0.0.0/1 और 128.0.0.0/1 जोड़ता है। साथ में यह जोड़ी पूरा IPv4 ढक लेती है, हर प्रीफ़िक्स /0 से लंबा है, और दोनों राउटर के डिफ़ॉल्ट को उसकी जगह छोड़ते हुए उसे हरा देते हैं। बाद में रूट सूची चलाएँ और मूल डिफ़ॉल्ट अब भी वहीं है, अब भी आपके गेटवे की ओर इशारा करता है; बस इंटरनेट गंतव्यों के लिए इसे कभी चुना नहीं जाता।

WireGuard का wg-quick नीति-आधारित रूटिंग से वही परिणाम पाता है। जब AllowedIPs 0.0.0.0/0 ढकता है तो यह अपनी तालिका बनाता है, चिह्नित पैकेट वहाँ भेजता है, और एक नियम जोड़ता है जो मुख्य तालिका के शून्य-लंबाई प्रीफ़िक्स को अनदेखा करता है। मुख्य तालिका अपनी डिफ़ॉल्ट प्रविष्टि रखती है, और नियम तय करते हैं कि इंटरफ़ेस के स्वामित्व वाले ट्रैफ़िक के लिए पहले टनल तालिका से परामर्श लिया जाता है।

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

मीट्रिक बराबरी तय करते हैं, प्रीफ़िक्स विजेता तय करते हैं

मीट्रिक की तुलना केवल उन्हीं उम्मीदवारों के बीच होती है जो गंतव्य से समान रूप से मेल खाते हैं। Linux पर, ip route get 10.20.5.9 विजेता को उसकी तालिका के साथ प्रिंट करता है, और ip route show table all उम्मीदवारों को सूचीबद्ध करता है, जिसमें कोई भी आधा-डिफ़ॉल्ट और कोई भी ऐसी तालिका शामिल है जिसकी ओर कोई नियम इशारा करता है। Windows पर, Find-NetRoute -RemoteIPAddress 10.20.5.9 चुना गया रूट और स्रोत पता लौटाता है, जबकि Get-NetRoute कच्ची तालिका दिखाता है — लेकिन प्रभावी लागत रूट मीट्रिक प्लस इंटरफ़ेस मीट्रिक है, इसलिए धीमा अनुकूलक वह बराबरी हार सकता है जिसे वह जीतता दिखता है।

तीन मामले आपके द्वारा देखे जाने वाले अधिकांश हिस्से को ढकते हैं:

• वही गंतव्य, /24 बनाम /0: /24 प्रीफ़िक्स लंबाई पर जीतता है, मीट्रिक जो कहें।
• वही गंतव्य, अलग-अलग मीट्रिक वाले दो /24: कम प्रभावी मीट्रिक जीतता है।
• वही गंतव्य, दो तालिकाएँ, एक नीति नियम द्वारा चुनी गई: नियम पहले तालिका चुनता है, और प्रीफ़िक्स तुलना उसके अंदर होती है।

तीसरा मामला वही है जहाँ इनमें से ज़्यादातर रिपोर्टें ख़त्म होती हैं। Linux का ip rule या Windows VPN ट्रैफ़िक फ़िल्टर ट्रैफ़िक को ऐसी तालिका में भेज सकता है जिसमें कभी टनल का डिफ़ॉल्ट नहीं था, और मुख्य तालिका पूरे समय बेदाग़ दिखती है।

आम तौर पर इस बायपास का मालिक कौन होता है

तालिका से नहीं, प्रोफ़ाइल से शुरू करें। Split-tunnel कॉन्फ़िगरेशन और प्रति-ऐप VPN सेटिंग्स जानबूझकर नामित प्रीफ़िक्स को टनल के बाहर छोड़ते हैं; एक कार्य प्रोफ़ाइल जो एक निजी सबनेट की रक्षा करता है और सामान्य ब्राउज़िंग को सीधे जाने देता है, वैसे ही व्यवहार करता है जैसे उसे डिज़ाइन किया गया था, और उसे ओवरराइड करना उस नीति को तोड़ता है जिसे लागू करने के लिए वह बना था। Microsoft की VPN रूटिंग मार्गदर्शिका ज़बरदस्ती टनल किए गए ट्रैफ़िक और स्पष्ट अपवादों के बीच वही रेखा खींचती है, जो कुछ भी संपादित करने से पहले इसे उपयोगी क्रॉस-चेक बनाती है।

फिर बचे हुए अवशेष खोजें। ऐसे इंटरफ़ेस की ओर इशारा करने वाला रूट जो अब नहीं है, या पिछले नेटवर्क का पता, डॉकिंग स्टेशन, USB अनुकूलक और कंटेनर ब्रिज आने-जाने के बाद दिखता है। इसे एक बार हटाना अंत नहीं है: NetworkManager कनेक्शन प्रोफ़ाइल, netplan फ़ाइलें और Windows के स्थायी रूट अगले कनेक्शन या बूट पर इसे फिर से इंस्टॉल करते हैं, इसलिए कुछ भी संपादित करने से पहले वह फ़ाइल या प्रोफ़ाइल खोजें जो इसका मालिक है।

फिर IPv6 को अलग से जाँचें। ip -6 route और Get-NetRoute -AddressFamily IPv6 अलग स्थिति, अलग डिफ़ॉल्ट और अलग क्लाइंट व्यवहार रखते हैं। केवल IPv4 का ऑडिट ऐसे दोहरे-स्टैक होस्ट के बारे में कुछ नहीं कहता जो चुपचाप मूल IPv6 पथ पसंद करता है, और अकेले यह किसी क्लाइंट को split-tunnel जैसा दिखा सकता है।

ऐप के अपने प्रवाह से पुष्टि करें

वह गंतव्य लिखें जो ऐप वास्तव में उपयोग करता है, फिर सिस्टम से वह पथ पूछें जो वह उस स्रोत पते से लेगा जिससे वह ऐप बंधा है। ip route get 10.20.5.9 from 192.168.1.40 Linux पर इसका जवाब देता है; Find-NetRoute -RemoteIPAddress 10.20.5.9 प्लस स्थानीय पता Windows पर यह करता है। परिणाम की तुलना उससे करें जो प्रोफ़ाइल दावा करता है। ब्राउज़र का सार्वजनिक-IP पेज एक प्रोटोकॉल पर एक गंतव्य का परीक्षण करता है और उस निजी पते के बारे में कुछ नहीं कहता जिसने शिकायत शुरू की।

अंतर समझाने वाली सबसे संकरी वस्तु ठीक करें। अगर अपवाद स्वीकृत है, तो प्रीफ़िक्स लिख लें और उसे छोड़ दें; अगर नहीं, तो रूट हटाएँ या डिफ़ॉल्ट का मीट्रिक घटाने के बजाय टनल से होकर स्पष्ट संकरा रूट जोड़ें। मीट्रिक घटाना लंबे प्रीफ़िक्स से आगे नहीं निकल सकता, और दो /1 रूट के इंटरनेट पथ के मालिक होने के दौरान डिफ़ॉल्ट संपादित करना भी कुछ नहीं बदलता।

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

• उस गंतव्य और स्रोत पते को नाम दें जो ऐप वास्तव में उपयोग करता है।
• जीतने वाला रूट ip route get या Find-NetRoute से प्रिंट करें।
• जाँचें कि इंटरनेट पथ का मालिक /1 जोड़ी है या नीति तालिका।
• /0 से लंबा और गंतव्य से मेल खाता हर प्रीफ़िक्स सूचीबद्ध करें।
• IPv6 जाँच अलग से दोहराएँ।
• बचे हुए रूट को उस फ़ाइल, प्रोफ़ाइल या फ़िल्टर तक ट्रेस करें जो इसे इंस्टॉल करता है।
• ठीक हुआ कहने से पहले दोबारा कनेक्ट करें और क्वेरी फिर चलाएँ।

अगर सातों प्रोफ़ाइल से सहमत हैं, तो टनल ठीक वही कर रही है जिसके लिए उसे कॉन्फ़िगर किया गया था, और सुधार मीट्रिक में नहीं, प्रोफ़ाइल में है।