स्थानीय रूट VPN के डिफ़ॉल्ट रूट को क्यों हराता है

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

जुड़ा हुआ प्रीफ़िक्स डिफ़ॉल्ट रूट से अधिक विशिष्ट है

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

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

कर्नेल जो चुनाव करता, उसे पढ़ें

कर्नेल से पूछें कि सटीक गंतव्य के लिए वह कौन-सा रूट इस्तेमाल करेगा, बजाय टेबल को ऊपर से पढ़ने के। फिर ऐसे नीति नियम खोजें जो कोई दूसरी टेबल चुन सकें। दो कमांड कुछ सेकंड में दोनों सवालों का जवाब देते हैं।

ip route get 10.20.30.41
ip route show table all | grep -E '10\.|default'
ip rule show

पहला आउटपुट इंटरफ़ेस, अगला हॉप और वह स्रोत पता बताता है जो कर्नेल इस्तेमाल करेगा, और यही वह जवाब है जो मायने रखता है। dev का मान स्थानीय ब्रिज की ओर इशारा करे तो इसका अर्थ है कि पैकेट कभी टनल में नहीं जाता, चाहे VPN क्लाइंट का स्टेटस पैनल कुछ भी दावा करे। फ़िल्टर की गई टेबल सूची दिखाती है कि किसी दूसरी टेबल में वही प्रीफ़िक्स है या नहीं, और नियम सूची वह क्रम दिखाती है जिसमें उन टेबलों से सलाह ली जाती है। एक नीति नियम किसी प्रीफ़िक्स को किसी ख़ास टेबल से भेज सकता है तब भी जब मुख्य टेबल सहमत न हो, इसलिए वह क्रम जवाब का हिस्सा है।

स्थानीय पहुँच एक अलग अनुमति है

रूट होना उसका इस्तेमाल करने की अनुमति होना नहीं है। ज़्यादातर क्लाइंट टनल ऊपर रहने पर स्थानीय नेटवर्क संचार रोक सकते हैं, और वह सेटिंग रूटिंग का नतीजा नहीं, नीति का फ़ैसला है। जब कोई भरोसेमंद नज़दीकी सेवा डिज़ाइन का हिस्सा हो, तो रूट गढ़ने के बजाय समर्थित स्थानीय-पहुँच विकल्प चालू करें। जब डिवाइस सार्वजनिक Wi-Fi पर हो, तो उसे बंद रखें।

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

होस्ट रूट का ढेर लगाए बिना ओवरलैप ठीक करें

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

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