VPN मा IPv6 link-local काम गर्दैन: fe80 लिङ्कमा किन रोकिन्छ
fe80:: ठेगानाको अर्थ एउटै लिङ्कमा मात्र हुन्छ। रुटेड VPN ले यसलाई किन बोक्न सक्दैन, विफलता कस्तो देखिन्छ र यसको सट्टा कुन ठेगाना प्रयोग गर्ने हेर्नुहोस्।
तपाईं टनेल माथि उठाउनुहुन्छ, टनेललाई स्रोत इन्टरफेस बनाएर fe80::1 मा ping गर्नुहुन्छ, र केही पनि फर्किएर आउँदैन। यो तपाईंले बिर्सनुभएको firewall नियम होइन। Link-local ठेगानाको अर्थ त्यो बनेको एउटै लिङ्कमा मात्र हुन्छ, र रुटेड VPN त्यो लिङ्क होइन। टाढाको राउटरको fe80::1 टाढाको LAN खण्डमा बस्छ; तपाईं अर्को खण्डमा एक हप टाढा हुनुहुन्छ, र IPv6 मा राउटरले link-local प्याकेट अगाडि पठाउने कुनै संयन्त्र नै छैन।
fe80 उपसर्गले दायरा बताउँछ, श्रेणी होइन
Link-local unicast भनेको fe80::/10 हो, र परिभाषित गर्ने गुण संख्या होइन, दायरा हो। ठेगाना एउटै लिङ्कमा मात्र मान्य हुन्छ, र प्रत्येक इन्टरफेसले आफ्नै पहिचानबाट एउटा बनाउँछ, त्यसैले दुई असम्बन्धित सञ्जालका दुई असम्बन्धित मेसिनले कुनै द्वन्द्वै बिना दुवैले fe80::1 लाई जवाफ दिन सक्छन्। उपसर्गले मूलतः “कुनै लिङ्कमा” भन्छ; लिङ्क आफै सन्दर्भबाट आउँछ।
होस्टमा त्यो सन्दर्भ प्रतिशत चिन्हपछि थपिने जोन, वा scope ID हो: Linux मा fe80::1%eth0, Windows मा र इन्टरफेस इन्डेक्स देखाउने उपकरणहरूमा fe80::1%3 वा fe80::1%12। कर्नेलले ठेगानालाई इन्टरफेस इन्डेक्ससँगै समाधान गरेर त्यसपछि पठाउँछ। जोन हटाउनुभयो भने गन्तव्य अस्पष्ट हुन्छ, त्यसैले स्ट्याकसँग खण्ड छान्ने कुनै उपाय हुँदैन।
रुटेड टनेलले यसलाई किन पुर्याउन सक्दैन
रुटेड VPN आफ्नै ठेगाना बोक्ने बिन्दु-देखि-बिन्दु इन्टरफेस हो, सामान्यतया टनेलभित्रको unique-local वा निजी IPv6 ठाउँको /64। टाढाको LAN छुट्टै लिङ्क हो, जहाँ टनेलको अन्त्यले तपाईंको तर्फबाट रुटिङ र फर्वार्डिङ गरेर पुग्छ। यी दुई फरक खण्ड हुन्, त्यसैले एउटाको ठेगाना अर्कोमा वैध गन्तव्य होइन।
फर्वार्डिङ नियम तपाईंको क्लाइन्टको विचित्रता होइन, मानकमा स्पष्ट छ: राउटरहरूले link-local स्रोत वा गन्तव्य भएका प्याकेट अगाडि पठाउँदैनन्। त्यसैले रुट तालिका सही देखिए पनि प्याकेट मर्छ। fe80::/64 का लागि टनेलतर्फ रुट थप्नुभयो भने मानक पालना गर्ने स्ट्याकले त्यसलाई या त अस्वीकार गर्छ वा स्वीकार गरेर मिल्ने हरेक प्याकेट खसाल्छ: गन्तव्यको दायरा “यही लिङ्क मात्र” भन्छ, र बाहिर जाने इन्टरफेस त्यो लिङ्क होइन।
छिमेकी पत्ता लगाउने प्रक्रियाले त्यही सीमालाई बलियो बनाउँछ। होस्टहरूले link-local अर्को हपहरू 255 हप सीमासहित लिङ्क-दायरा multicast मा पठाइने छिमेकी अनुरोधबाट समाधान गर्छन्, त्यसैले राउटरहरूले अगाडि पठाइएको जे पनि अस्वीकार गर्न सक्छन्। यसलाई टनेलभरि चलाउनु भनेको टाढाको खण्डका लागि पत्ता लगाउने काम प्रोक्सी गर्नु हो, जुन अर्कै टोपी लगाएको Layer 2 ब्रिजिङ हो।
अर्को, बढी शान्त विफलता छ, र त्यसले रुट जबरजस्ती लाद्न खोज्नेहरूलाई समात्छ: जोन। तपाईंले स्थानीय रूपमा जुनसुकै जोन टाइप गर्नुभए पनि त्यसले टनेल इन्टरफेसको नाम लिन्छ, जबकि तपाईंले चाहेको ठेगाना टाढाको LAN इन्टरफेसमा बाँधिएको हुन्छ। दुवै कहिल्यै मिल्दैनन्, त्यसैले प्याकेटलाई टाढाको छेउमा सही इन्टरफेसमा पुर्याउन सकिँदैन।
व्यवहारमा विफलता कस्तो देखिन्छ
दायराको गल्तीको उपकरण आउटपुट रुटिङ वा firewall त्रुटिजस्तो पढिन्छ, र त्यसैले मानिसहरू गलत तहमा दिउँसो बिताउँछन्।
| What you run | What you see | What it means |
|---|---|---|
| ping fe80::1 with no zone | Invalid argument on Linux, or a transmit failure on Windows | The stack cannot pick an interface for an ambiguous destination |
| ping -6 -I tun0 fe80::1 | Destination unreachable, or a silent timeout | The address is not on the tunnel link, so there is nothing on-link to answer |
| ssh user@fe80::1 after the tunnel is up | Hangs, then no route to host | The SYN never left the machine in a deliverable form; the server logs nothing |
| ip -6 neigh show dev tun0 | Empty table | No neighbor entry can exist for a link-local host that is not on this link |
| fe80::/64 inside AllowedIPs or route-ipv6 | Config accepted, traffic still dropped | The tunnel carried the packet; the receiving stack refused to forward it |
तेस्रो पङ्क्तिले सबैभन्दा धेरै समय बर्बाद गर्छ, किनकि आउटपुट नभएको ssh क्लाइन्ट सुनिरहेको सेवाको समस्या जस्तो देखिन्छ। भित्र पस्ने कुनै उपाय छ भने टाढाको पक्ष जाँच्नुहोस् र sshd सबै ठेगानामा बाँधिएको छ वा एउटामा मात्र भनी पुष्टि गर्नुहोस्।
रुटिङका लागि बनाइएको ठेगाना प्रयोग गर्नुहोस्
टनेलबाट पुग्नुपर्ने जे पनि हो, सेवालाई त्यही उद्देश्यका लागि दिइएको ठेगाना प्रयोग गर्नुहोस्: विश्वव्यापी unicast ठेगाना, वा fc00::/7 बाट unique-local ठेगाना, ठ्याक्कै यही आन्तरिक अवस्थाका लागि आरक्षित दायरा। सुन्नेले यसलाई साँच्चै बाँध्छ कि भनी पुष्टि गर्नुहोस्, र फर्किने बाटो तथा होस्टको कुनै पनि firewall नियम जाँच्नुहोस्।
अनुमान लगाउनुको सट्टा टाढाको होस्ट हेर्नुहोस्। ip -6 addr show ले अवस्थित ठेगानाहरू सूचीबद्ध गर्छ, र ss -6 -ltn ले डेमनले के सुनिरहेको छ सूचीबद्ध गर्छ। fe80:: मा मात्र बाँधिएको सेवा आफ्नै खण्डबाट मात्र पुग्न सकिन्छ, जुन सामान्यतया कसैले जानाजान छानेको नभएको पूर्वनिर्धारित मान हो र प्रशासकको सहमतिमा बदल्न सकिन्छ।
सेवा साँच्चै पुनः बाँध्न नसकिने भए ब्रिजलाई नेटवर्क तहको सट्टा अनुप्रयोग तहमाथि सार्नुहोस्। टाढाको होस्टमा रुट गर्न सकिने ठेगानामा सुनेर link-local मा जोडिने रिलेले कुनै खण्ड नबढाई समस्या समाधान गर्छ:
socat TCP6-LISTEN:8080,bind=[fd00:1:2::10] TCP6:[fe80::1%eth0]:80यहाँ जोन सही पक्षमा छ, त्यो होस्टमा जससँग त्यो लिङ्कमा साँच्चै eth0 छ। तपाईंको क्लाइन्टले fd00:1:2::10 सँग कुरा गर्छ, जो सामान्य रूपमा रुट हुन्छ, र रिलेले link-local हप स्थानीय रूपमा गर्छ। त्यही चाल उपकरणको वेब UI वा link-local ठेगाना मात्र घोषणा गर्ने पुरानो BMC का लागि पनि काम गर्छ।
ब्रिजिङ साँच्चै उत्तर हुँदा, र के जाँच्ने
केही परिनियोजनलाई साँच्चै एउटै साझा खण्ड चाहिन्छ: link-local पत्ता लगाउने मात्र कुरा गर्ने उपकरण, multicast मा निर्भर उपकरण, समतल LAN पुनःउत्पादन गर्ने प्रयोगशाला। त्यो Layer 2 समस्या हो र त्यसलाई Layer 2 को उत्तर चाहिन्छ, जस्तै टाढाको इन्टरफेसमा ब्रिज गरिएको tap उपकरण वा स्पष्ट ब्रिज्ड मोड भएको क्लाइन्ट उत्पादन। यसले तपाईंलाई टनेल तर्ने broadcast र multicast ट्राफिक र टुप्पोदेखि टुप्पोसम्म चल्नुपर्ने छिमेकी पत्ता लगाउने खर्च लाग्छ।
रुटेड प्रोफाइलमा fe80::/64 थपेर यसलाई नजिक बनाउने प्रयास नगर्नुहोस्। त्यसले सबैभन्दा नराम्रो अवस्था बनाउँछ: कन्फिग सकिएको जस्तो देखिन्छ, रुट तालिकाले प्रविष्टि देखाउँछ, र हरेक प्याकेट अझै दुवै सही व्यवहार गरिरहेका दुई स्ट्याकबीच कतै खसालिन्छ।
ping नभई इन्टरफेसबाट पुष्टि गर्नुहोस्। ip -6 addr show tun0 ले टनेल लिङ्कले आफ्नै link-local ठेगाना बनायो कि भनी बताउँछ, र ip -6 route get fe80::1%tun0 ले दायरा भएको गन्तव्यसँग कर्नेलले वास्तवमा के गर्छ भनी बताउँछ। कर्नेलले त्यो इन्टरफेसमा गन्तव्य अगम्य छ भन्यो भने कुनै पनि टनेल सेटिङले त्यो बदल्दैन, र प्रोफाइल सम्पादन रोक्ने समय आएको छ।
प्रश्न टुङ्ग्याउने छोटो क्रम:
- टाढाको होस्टमा ठेगाना पढ्नुहोस् र त्यो fe80:: हो वा रुट गर्न सकिने उपसर्ग हो भनी ध्यान दिनुहोस्।
- fe80:: भए सेवा पुनः बाँध्नुहोस्, त्यो होस्टमा रिले गर्नुहोस्, वा खण्ड ब्रिज गर्नुहोस्; रुट गर्न सकिने भए रुट, firewall वा बाइन्ड ठेगाना सुधार्नुहोस्।
- पुनः परीक्षण गर्दा हरेक पटक जोन फेरि जाँच्नुहोस्, किनकि प्रतिलिपि गरिएको आदेशले सामान्यतया गलत इन्टरफेस राख्छ।
स्रोत: RFC 4291, IPv6 ठेगाना संरचना.