VPN पर IPv6 link-local काम नहीं कर रहा: fe80 लिंक पर क्यों रुक जाता है
fe80:: पता केवल एक लिंक पर अर्थ रखता है। देखें कि रूटेड VPN इसे क्यों नहीं ले जा सकता, विफलता कैसी दिखती है, और इसके बजाय कौन-सा पता उपयोग करें।
आप टनल को ऊपर लाते हैं, टनल को स्रोत इंटरफ़ेस बनाकर fe80::1 को पिंग करते हैं, और कुछ भी वापस नहीं आता। यह कोई फ़ायरवॉल नियम नहीं है जिसे आप भूल गए हों। लिंक-लोकल पता केवल उस एक लिंक पर अर्थ रखता है जहाँ वह बना था, और रूटेड VPN वह लिंक नहीं है। दूरस्थ राउटर का fe80::1 दूरस्थ LAN सेगमेंट पर रहता है; आप एक अलग सेगमेंट पर एक हॉप दूर बैठे हैं, और IPv6 में राउटर द्वारा लिंक-लोकल पैकेट आगे भेजने का कोई तंत्र ही नहीं है।
fe80 उपसर्ग एक दायरा बताता है, कोई श्रेणी नहीं
लिंक-लोकल यूनिकास्ट fe80::/10 है, और इसका परिभाषित गुण संख्या नहीं बल्कि दायरा है। पता केवल एक लिंक पर मान्य होता है, और हर इंटरफ़ेस अपने ही पहचानकर्ता से एक बनाता है, इसीलिए दो असंबंधित नेटवर्कों की दो असंबंधित मशीनें बिना किसी टकराव के fe80::1 का जवाब दे सकती हैं। उपसर्ग मूल रूप से कहता है “किसी लिंक पर”; लिंक स्वयं संदर्भ से आता है।
किसी होस्ट पर वह संदर्भ ज़ोन या स्कोप ID होता है जिसे आप प्रतिशत चिह्न के बाद जोड़ते हैं: Linux पर fe80::1%eth0, Windows और इंटरफ़ेस इंडेक्स दिखाने वाले टूल में fe80::1%3 या fe80::1%12। कर्नेल पते को इंटरफ़ेस इंडेक्स के साथ हल करता है और फिर भेजता है। ज़ोन हटा दें तो गंतव्य अस्पष्ट हो जाता है, इसलिए स्टैक के पास सेगमेंट चुनने का कोई तरीका नहीं बचता।
रूटेड टनल इसे क्यों नहीं पहुँचा सकती
रूटेड VPN एक पॉइंट-टू-पॉइंट इंटरफ़ेस है जो अपने स्वयं के पते ले जाता है, आमतौर पर टनल के भीतर यूनिक-लोकल या निजी IPv6 स्थान का /64। दूरस्थ LAN एक अलग लिंक है, जहाँ टनल एंडपॉइंट आपकी ओर से रूटिंग और फ़ॉरवर्डिंग करके पहुँचता है। ये दो अलग सेगमेंट हैं, इसलिए एक से लिया गया पता दूसरे पर वैध गंतव्य नहीं है।
फ़ॉरवर्डिंग नियम मानक में स्पष्ट है, यह आपके क्लाइंट की कोई विचित्रता नहीं: राउटर लिंक-लोकल स्रोत या गंतव्य वाले पैकेट आगे नहीं भेजते। इसीलिए पैकेट तब भी मर जाता है जब रूट तालिका सही दिखती है। टनल की ओर fe80::/64 के लिए रूट जोड़ें और अनुरूप स्टैक या तो उसे अस्वीकार करता है या स्वीकार करके हर मेल खाते पैकेट को गिरा देता है: गंतव्य का दायरा कहता है “केवल यह लिंक”, और आउटगोइंग इंटरफ़ेस वह लिंक नहीं है।
पड़ोसी खोज उसी सीमा को और मज़बूत करती है। होस्ट लिंक-लोकल अगली हॉप को 255 की हॉप सीमा वाले लिंक-स्कोप्ड मल्टीकास्ट पर भेजे गए पड़ोसी अनुरोध से हल करते हैं, ताकि राउटर आगे भेजी गई किसी भी चीज़ को अस्वीकार कर सकें। टनल के आर-पार इसे काम कराने का मतलब होगा दूरस्थ सेगमेंट के लिए खोज की प्रॉक्सी करना, जो अलग टोपी पहने Layer 2 ब्रिजिंग है।
एक दूसरी, ज़्यादा चुपचाप विफलता है, और वह उन लोगों को फँसाती है जो रूट को जबरदस्ती लागू करने की कोशिश करते हैं: ज़ोन। आप स्थानीय रूप से जो भी ज़ोन टाइप करते हैं वह टनल इंटरफ़ेस का नाम लेता है, जबकि आपका मनचाहा पता दूरस्थ LAN इंटरफ़ेस से बँधा है। दोनों कभी मेल नहीं खाते, इसलिए पैकेट दूर वाले सिरे पर सही इंटरफ़ेस पर नहीं लगाया जा सकता।
व्यवहार में विफलता कैसी दिखती है
स्कोप की गलती पर टूल आउटपुट रूटिंग या फ़ायरवॉल त्रुटि जैसा पढ़ता है, और ठीक इसी कारण लोग गलत परत में पूरी दोपहर बिता देते हैं।
| 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 सभी पतों से बँधा है या सिर्फ़ एक से।
ऐसा पता उपयोग करें जो रूट होने के लिए ही बना हो
टनल से जो भी पहुँचना है, उसके लिए वही पता उपयोग करें जो सेवा को इसी उद्देश्य के लिए दिया गया था: कोई ग्लोबल यूनिकास्ट पता, या fc00::/7 में से कोई यूनिक-लोकल पता, वह श्रेणी जो ठीक इसी आंतरिक स्थिति के लिए आरक्षित है। पुष्टि करें कि लिसनर वास्तव में उसे बाँधता है, और वापसी मार्ग तथा होस्ट के किसी भी फ़ायरवॉल नियम की पुष्टि करें।
अनुमान लगाने के बजाय दूरस्थ होस्ट को देखें। ip -6 addr show उन पतों की सूची दिखाता है जो मौजूद हैं, और ss -6 -ltn दिखाता है कि डेमन किस पर सुन रहा है। केवल fe80:: से बँधी सेवा केवल अपने ही सेगमेंट से पहुँच योग्य होती है, जो आमतौर पर ऐसा डिफ़ॉल्ट होता है जिसे किसी ने जानबूझकर नहीं चुना और प्रशासक की सहमति से बदला जा सकता है।
जब सेवा वास्तव में दोबारा बँध न सके, तो ब्रिज को नेटवर्क परत के बजाय एप्लिकेशन परत तक ऊपर ले जाएँ। दूरस्थ होस्ट पर एक रिले जो रूट होने योग्य पते पर सुनता है और लिंक-लोकल वाले से जुड़ता है, बिना कोई सेगमेंट बढ़ाए समस्या हल कर देता है:
socat TCP6-LISTEN:8080,bind=[fd00:1:2::10] TCP6:[fe80::1%eth0]:80यहाँ ज़ोन सही तरफ़ है, उस होस्ट पर जिसके पास वास्तव में उस लिंक पर eth0 है। आपका क्लाइंट fd00:1:2::10 से बात करता है, जो सामान्य रूप से रूट होता है, और रिले लिंक-लोकल हॉप को स्थानीय रूप से पूरा करता है। यही तरकीब किसी उपकरण के वेब UI या पुराने BMC के लिए भी काम करती है जो केवल लिंक-लोकल पता विज्ञापित करता है।
जब ब्रिजिंग वास्तव में उत्तर हो, और क्या जाँचें
कुछ परिनियोजनों को वास्तव में एक साझा सेगमेंट चाहिए: ऐसा उपकरण जो केवल लिंक-लोकल खोज की बात करता है, ऐसा उपकरण जो मल्टीकास्ट पर निर्भर है, ऐसी प्रयोगशाला जो सपाट LAN को दोहराती है। यह Layer 2 की समस्या है और इसे Layer 2 का उत्तर चाहिए, जैसे दूरस्थ इंटरफ़ेस से ब्रिज किया गया tap डिवाइस या स्पष्ट ब्रिज्ड मोड वाला क्लाइंट उत्पाद। इसकी कीमत है टनल के आर-पार जाने वाला ब्रॉडकास्ट और मल्टीकास्ट ट्रैफ़िक, साथ ही पड़ोसी खोज जिसे सिरे से सिरे तक काम करना ही होगा।
रूटेड प्रोफ़ाइल में fe80::/64 जोड़कर इसका अनुमान मत लगाइए। इससे सबसे बुरी स्थिति बनती है: कॉन्फ़िग पूरा दिखता है, रूट तालिका में प्रविष्टि दिखती है, और हर पैकेट अब भी दो ऐसे स्टैकों के बीच कहीं नष्ट होता रहता है जो दोनों सही व्यवहार कर रहे हैं।
पिंग के बजाय इंटरफ़ेस से पुष्टि करें। ip -6 addr show tun0 बताता है कि टनल लिंक ने अपना लिंक-लोकल पता बनाया या नहीं, और ip -6 route get fe80::1%tun0 बताता है कि कर्नेल स्कोप्ड गंतव्य के साथ वास्तव में क्या करेगा। जब कर्नेल कहे कि गंतव्य उस इंटरफ़ेस पर अगम्य है, तो कोई भी टनल सेटिंग इसे नहीं बदलेगी, और प्रोफ़ाइल संपादित करना बंद करने का समय आ गया है।
एक छोटा क्रम जो सवाल तय कर देता है:
- दूरस्थ होस्ट पर पता पढ़ें और ध्यान दें कि वह fe80:: है या रूट होने योग्य उपसर्ग।
- अगर वह fe80:: है, तो सेवा को दोबारा बाँधें, उस होस्ट पर रिले करें, या सेगमेंट को ब्रिज करें; अगर रूट होने योग्य है, तो रूट, फ़ायरवॉल या बाइंड पता ठीक करें।
- हर बार दोबारा परीक्षण करते समय ज़ोन फिर से जाँचें, क्योंकि कॉपी किया गया कमांड आमतौर पर गलत इंटरफ़ेस रखता है।