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 पत्ता रचना.