VPN भित्र 169.254: त्यो ठेगाना कहिल्यै रुट गर्न योग्य थिएन
Link-local गन्तव्य टनेलसम्म पुग्नुअघि नै खारेज हुन्छ, त्यसैले रुट थप्दा असफलता मात्र फराकिलो बन्छ। सबनेट मर्मत गर्ने र ब्रिज गर्नेमध्ये छान्नुहोस्।
तपाईं रुट थप्नुहुन्छ, टनेल उठ्छ, र परपट्टिको ping अझै पनि “network unreachable” नभई पूर्ण प्याकेट हानिका साथ मर्छ। त्यो भिन्नता महत्त्वपूर्ण छ, किनभने यसले तपाईंको रुटिङ तालिकाबाट टाढा ठेगानातर्फै देखाउँछ। 169.254 गन्तव्य link-local हो, र link-local को दायरा डिजाइनैले पहिलो hop मा टुंगिन्छ, गलत कन्फिगरेसनले होइन।
यसपछिको निर्णय साँघुरो छ र यसलाई स्पष्ट रूपमा लिनु जरुरी छ: सर्भरतर्फको सबनेट मर्मत गर्ने, वा Layer 2 खण्ड विस्तार गरेर ठेगानालाई फेरि स्थानीय रूपमा अर्थपूर्ण बनाउने। बाँकी सबै, थप फराकिलो रुट थप्नेसमेत, त्यही असफलतालाई थप गन्तव्यहरूमा लागू गराउने उपाय मात्र हो।
ठेगाना रुट नगरिएको होइन, रुट गर्नै नसकिने हो
Link-local IPv4 ठेगानाहरू अरू केही राम्रो नभेटिँदा आफैँ तोकिन्छन्, Windows मा automatic private addressing व्यवहार यहीँबाट आउँछ र अन्य प्रणालीमा पनि यसैको समानान्तर fallback हुन्छ। यो दायरा हरेक link मा एकैसाथ प्रयोगमा हुन्छ, र यही कारणले यो काम गर्छ: एउटै खण्डका दुई host कुनै समन्वयबिना बोल्न सक्छन्।
यही गुणले गर्दा राउटरले यी प्याकेट सञ्जालहरूबीच अगाडि बढाउनु हुँदैन। link-local गन्तव्यमा सम्बोधित प्याकेट प्राप्त गरेर अर्को इन्टरफेसबाट पठाउँदा द्विविधा उत्पन्न हुन्छ, किनभने पठाउनेको “स्थानीय” र प्राप्त गर्नेको “स्थानीय” फरक ठाउँ हुन्। पठाउनेले कुन चाहिँ जनाएको हो भन्ने टुंगो लगाउने कुनै lookup छैन। यहाँ forwarding कुनै प्रशासकले सक्षम गर्न सक्ने नीतिगत विकल्प होइन; ठेगाना वर्गले नै यसलाई बाहिर राख्छ।
त्यसैले 169.254.1.10 लाई टनेलबाट reachable का रूपमा राख्ने gateway ले kernel लाई ठेगाना ढाँचाले निषेध गरेको काम गर्न भनिरहेको हुन्छ। प्याकेट टाढाको host सम्म पुग्नु धेरै अगाडि नै खारेज हुन्छ, र रुटको कति पनि विशिष्टताले त्यो परिणाम बदल्दैन।
टनेलले scope समस्या किन देखिने बनाउँछ
TUN इन्टरफेसले दुई peer बीच IP प्याकेट बोक्छ र यसको पछाडि कुनै साझा खण्ड हुँदैन। त्यहाँ न broadcast हुन्छ, न परपट्टिका लागि ARP, न त link-local गन्तव्यलाई link-layer ठेगानामा रिजोल गर्न सक्ने neighbour discovery हुन्छ। forwarding अनुमति भए पनि, कुन peer ले जवाफ दिनुपर्ने हो भन्ने कुरा client ले सिक्ने कुनै उपाय छैन।
के खोज्ने भन्ने थाहा भएपछि लक्षणहरू सफासँग मिल्छन्। रुट तालिकामा देखिन्छ, ping ले unreachable सञ्जाल नभई पूर्ण हानि देखाउँछ, र neighbour तालिकाले गन्तव्यका लागि अपूर्ण वा असफल प्रविष्टि देखाउँछ। टनेलमा capture गर्दा प्याकेट बाहिर जाँदै गरेको देखिन्छ, जसले मानिसहरूलाई ठेगाना वर्गतर्फ नभई परपट्टितर्फ हेर्न लगाउँछ।
Windows मा एउटै मूलको अर्को, फरक देखिने लक्षण पनि छ: link-local ठेगाना मात्र बाँकी भएको adapter सँग प्रयोगयोग्य gateway हुँदैन, त्यसैले network identification ले जडान वर्गीकृत गर्न सक्दैन र firewall profile public मा पर्छ। टनेल कारण होइन; ठेगाना नै कारण हो।
तीन प्रश्नले निर्णय गर्नुहोस्
सबनेट मर्मत गर्ने र link ब्रिज गर्नेबीचको छनोट तीन सर्तमा टिकेको छ, र तीमध्ये कुनै एउटाले पनि कन्फिगरेसन फाइल खोल्नुअघि नै निर्णय टुंग्याउन सक्छ।
| 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 |
अधिकांश अवस्था पहिलो प्रश्नमै रोकिन्छन्। link-local ठेगाना देखाउने host भनेको सामान्यतया DHCP ले जवाफ नदिएको, केबल वा VLAN गलत भएको, वा कसैले ठेगाना हातले टाइप गरेको संकेत हो। त्यसको मर्मत कुनै पनि टनेल कामभन्दा सस्तो छ, र यसले समस्या यो एउटा client का लागि मात्र नभई भावी सबै client का लागि हटाउँछ। यसले साइटलाई काम गर्ने DHCP scope पनि दिन्छ, जुन वास्तवमा तपाईंले चाहेको कुरा हो।
केही मान्नुअघि सर्भरतर्फ जाँच्नुहोस्। host मा ip addr show र ip route चलाउनुहोस्, र client मा arp -n वा route print -4, ताकि prefix नै अवस्थित छ कि पुरानो प्रविष्टिले मात्र त्यसो दाबी गरिरहेको हो भन्ने देखियोस्।
ब्रिज सही उत्तर हुँदा यसको मूल्य के हो
भौतिक adapter लाई TAP adapter सँग ब्रिज गर्दा टाढाको client स्थानीय broadcast domain को हिस्सा बन्छ। त्यसपछि broadcast र neighbour discovery काम गर्छन्, र link-local ठेगाना फेरि अर्थपूर्ण बन्छ, किनभने client साँच्चै त्यो link कै स्थानीय हुन्छ।
मूल्यहरू वास्तविक छन् र कसैले स्वीकार गर्नुअघि ती उल्लेख गर्नुपर्छ। broadcast ट्राफिक टनेल पार गर्छ, client आफूलाई चाहिने सेवामात्र नभई हरेक प्रयोजनका लागि स्थानीय खण्डमा खुला हुन्छ, र सर्भरले अब प्याकेट रुट गर्नुको सट्टा frame अगाडि बढाउनुपर्छ। यो lab bench वा routable कन्फिगरेसन मार्ग नभएको यन्त्रका लागि उपयुक्त सौदा हो, र टाढाको पहुँचका लागि खराब पूर्वनिर्धारित हो।
ब्रिज गर्दा दुवै भाग आवश्यक छन्: सर्भरमा ब्रिज, र client प्रोफाइलमा कुन गन्तव्य परपट्टि छन् भन्ने बताउने रुट। ब्रिज मात्रले client लाई अनुमानमा छोड्छ, र रुट मात्रले ठेगाना वर्गको समस्या सुधार्न सक्दैन।