VPN के ज़रिए 169.254: यह पता कभी रूट होने योग्य नहीं था
लिंक-लोकल गंतव्य टनल तक पहुँचने से पहले ही गिरा दिया जाता है, इसलिए रूट जोड़ना सिर्फ़ विफलता को चौड़ा करता है। सबनेट ठीक करने और ब्रिज बनाने में से चुनें।
आप रूट जोड़ते हैं, टनल ऊपर आती है, और फिर भी दूसरी तरफ़ का ping पूरी हानि के साथ मरता है, «network unreachable» नहीं। यह अंतर मायने रखता है, क्योंकि यह ध्यान रूटिंग तालिका से हटाकर पते पर ले जाता है। 169.254 गंतव्य लिंक-लोकल है, और उसका दायरा डिज़ाइन से पहले hop पर खत्म होता है, गलत कॉन्फ़िगरेशन से नहीं।
इसके बाद का फ़ैसला सीमित है और उसे स्पष्ट रूप से लेना चाहिए: सर्वर की तरफ़ का सबनेट ठीक करें, या लेयर 2 खंड को बढ़ाएँ ताकि पता फिर स्थानीय अर्थ रखे। बाकी सब, चौड़ा रूट जोड़ना भी, उसी विफलता को ज़्यादा गंतव्यों तक फैलाता है।
पता रूट से रहित नहीं, वह रूट होने योग्य नहीं है
IPv4 लिंक-लोकल पते तब खुद को सौंपते हैं जब कोई बेहतर उत्तर नहीं देता; Windows में स्वचालित निजी पता-निर्धारण की जड़ यही है और दूसरे सिस्टम में भी उसका समतुल्य है। यह श्रेणी हर लिंक पर एक साथ इस्तेमाल होती है, और इसी वजह से काम करती है: एक ही खंड के दो होस्ट बिना किसी समन्वय के बात कर सकते हैं।
इसी गुण के कारण राउटर को ये पैकेट नेटवर्क के बीच आगे नहीं भेजने चाहिए। लिंक-लोकल गंतव्य के लिए भेजे गए पैकेट को लेकर दूसरे इंटरफ़ेस से बाहर भेजने से अस्पष्टता बनेगी, क्योंकि भेजने वाले का «स्थानीय» और पाने वाले का «स्थानीय» अलग जगहें हैं। कोई खोज तय नहीं कर सकती कि कौन-सा मतलब था। यहाँ अग्रेषण ऐसा नीति-विकल्प नहीं जिसे व्यवस्थापक चालू कर सके; पता वर्ग इसे बाहर रखता है।
इसलिए जो गेटवे 169.254.1.10 को टनल से पहुँचने योग्य के रूप में सेट करता है, वह कर्नेल से वह करने को कहता है जिसे पते का प्रारूप मना करता है। पैकेट दूर के होस्ट तक पहुँचने से बहुत पहले गिरा दिया जाता है, और रूट की कोई बारीकी इसे नहीं बदलती।
टनल दायरे की समस्या क्यों दिखा देती है
TUN इंटरफ़ेस दो साथियों के बीच IP पैकेट ले जाता है और उसके पीछे कोई साझा खंड नहीं होता। कोई ब्रॉडकास्ट नहीं, दूसरी तरफ़ के लिए ARP नहीं, और पड़ोसी खोज भी नहीं जो लिंक-लोकल गंतव्य को लिंक-परत पते में बदल सके।
संकेत ठीक मिलते हैं जब पता हो क्या देखना है। रूट तालिका में है, ping पूरी हानि बताता है, पड़ोसी तालिका अधूरी प्रविष्टि दिखाती है। टनल पर कैप्चर पैकेट को जाते दिखाता है, जो लोगों को पता वर्ग की जगह दूर के सिरे की ओर भेजता है।
Windows में उसी जड़ का दूसरा संकेत है: सिर्फ़ लिंक-लोकल पता रखने वाले एडाप्टर के पास कोई उपयोगी गेटवे नहीं होता, इसलिए नेटवर्क पहचान कनेक्शन को वर्गीकृत नहीं कर पाती और फ़ायरवॉल प्रोफ़ाइल public पर गिर जाती है। टनल कारण नहीं है; पता कारण है।
तीन सवालों से तय करें
सबनेट ठीक करने और लिंक को ब्रिज करने के बीच चुनाव तीन शर्तों पर टिका है, और इनमें से कोई भी कॉन्फ़िगरेशन फ़ाइल खोलने से पहले फ़ैसला दे सकती है।
| Question | If yes | If no |
|---|---|---|
| Can the far-side host be given a routable address? | Change the host or fix DHCP and route normally | Continue to the next question |
| Does the device accept a static address at all? | Assign one from the site's real prefix | Bridging is the only remaining option |
| Can you accept broadcast crossing the tunnel? | A bridge is viable for a small segment | Replace the device or accept no remote access |
ज़्यादातर मामले पहले सवाल पर रुक जाते हैं। लिंक-लोकल पता दिखाने वाला होस्ट आम तौर पर बताता है कि DHCP ने जवाब नहीं दिया, केबल या VLAN गलत है, या किसी ने पता हाथ से लिखा। इसे ठीक करना किसी भी टनल काम से सस्ता है और समस्या हर भावी क्लाइंट से हटाता है, सिर्फ़ इससे नहीं।
कुछ मानने से पहले सर्वर पक्ष देखें। होस्ट पर ip addr show और ip route चलाएँ, और क्लाइंट पर arp -n या route print -4, ताकि दिखे कि prefix वाकई है या सिर्फ़ पुरानी प्रविष्टि ऐसा कहती है।
ब्रिज सही उत्तर हो तो उसकी कीमत
भौतिक एडाप्टर को TAP एडाप्टर के साथ ब्रिज करने पर दूर का क्लाइंट स्थानीय ब्रॉडकास्ट डोमेन का हिस्सा बन जाता है। तब ब्रॉडकास्ट और पड़ोसी खोज काम करते हैं, और लिंक-लोकल पता फिर अर्थपूर्ण होता है।
लागत वास्तविक है और किसी की सहमति से पहले बताई जानी चाहिए। ब्रॉडकास्ट ट्रैफ़िक टनल पार करता है, क्लाइंट स्थानीय खंड के सामने हर मकसद से खुला रहता है, और सर्वर को अब पैकेट रूट करने की जगह फ़्रेम आगे भेजने पड़ते हैं। लैब बेंच या रूट-योग्य कॉन्फ़िगरेशन रहित डिवाइस के लिए यह ठीक सौदा है, दूरस्थ पहुँच के लिए खराब डिफ़ॉल्ट।
ब्रिज करते समय दोनों आधे चाहिए: सर्वर पर ब्रिज, और क्लाइंट प्रोफ़ाइल में रूट जो बताए कौन-से गंतव्य दूसरी तरफ़ हैं। सिर्फ़ ब्रिज क्लाइंट को अनुमान में छोड़ता है, और सिर्फ़ रूट पता वर्ग ठीक नहीं कर सकता।