OpenVPN बोगद्यातून IPv6: घरगुती राउटरसाठी टप्प्याटप्प्याने मार्गदर्शन

लॅपटॉपला IPv6 पत्ता आहे, बोगदा IPv4 वर चालू आहे, तरीही प्रत्येक IPv6 चाचणी अयशस्वी होते। किंवा त्याहून वाईट: चाचणी यशस्वी होते आणि रहदारी बोगद्यात कधीही न शिरता ISP च्या मार्गाने बाहेर जाते। दोन्ही निकाल एकाच गहाळ निर्णयाकडे परत येतात: कोणीही राउटरला क्लायंटकडे राउट करता येईल असा उपसर्ग दिला नाही। क्लायंटपासून बाहेरच्या दिशेने मार्ग चालल्यास कोणता भाग गहाळ आहे ते सापडते।

क्लायंट जिथे आहे तिथूनच सुरुवात करा

सर्व्हरला स्पर्श करण्यापूर्वी क्लायंट पाहा। ip -6 addr ने पूलमधील बोगदा पत्ता दाखवावा, आणि ip -6 route ने बोगदा उपकरणाकडे निर्देश करणारा ढकललेला उपसर्ग दाखवावा। पत्ता असून मार्ग नसेल, तर ढकलणी गहाळ आहे किंवा क्लायंटने ती दुर्लक्षित केली। दोन्ही नसल्यास सर्व्हरने काहीच वाटले नाही।

नंतर क्लायंट बाहेरच्या जगाबद्दल काय मानतो ते तपासा। बोगद्यावरील डीफॉल्ट मार्ग सर्व IPv6 रहदारीचा दावा करतो, तर 2000::/3 साठीचा मार्ग फक्त जागतिक युनिकास्टचा दावा करतो। दोन्ही बरोबर असू शकतात, आणि ते गळतीबद्दल वेगवेगळ्या प्रश्नांची उत्तरे देतात।

IPv6 डीफॉल्ट नसलेला क्लायंट बोगदा स्वतः पूर्णपणे निरोगी असतानाही प्रत्येक सार्वजनिक चाचणीत अयशस्वी होतो। ही धोरणातील त्रुटी आहे, तुटलेला बोगदा नाही।

सर्व्हर खरोखर राउट करू शकतो तो पूल तपासा

सर्व्हर फक्त स्वतः खरोखर नियंत्रित करतो त्या उपसर्गातूनच वाटू शकतो। ISP ने /56 सोपवले तर बोगद्यासाठी एक /64 राखून ठेवा आणि उर्वरित LAN साठी ठेवा। ISP WAN वर फक्त एक /64 देत असेल आणि पुढे काहीच राउट करत नसेल, तर LAN उपसर्ग तसाच ठेवा आणि बोगद्याला अद्वितीय स्थानिक श्रेणी द्या, क्लायंटना जागतिक बाहेर पडण्याचा मार्ग नसेल हे मान्य करून।

पूल आणि ढकलणी एकत्र जातात। server-ipv6 2001:db8:80:10::/64 पत्ते वाटतो, आणि push "route-ipv6 2000::/3" क्लायंटना बोगद्यात काय पाठवायचे ते सांगतो। 2000::/3 ढकलल्यास जागतिक युनिकास्ट व्यापले जाते आणि link-local व multicast श्रेणी बोगद्याबाहेर राहतात।

निवडलेला उपसर्ग तैनाती नोंदीत लिहा। पुढच्या वेळी ISP हस्तांतरण बदलणाऱ्याला बोगदा आधीच कोणता /64 व्यापतो हे माहीत असणे आवश्यक आहे।

दुसऱ्या कुटुंबासाठी फॉरवर्डिंग सुरू करा

IPv4 फॉरवर्डिंगचा अर्थ IPv6 फॉरवर्डिंग नाही। net.ipv6.conf.all.forwarding=1 सेट करा आणि IPv4 FORWARD धोरण आधीच परवानगी देते ते सर्व प्रतिबिंबित करा। ज्या राउटरची FORWARD साखळी डीफॉल्टने टाकून देते, तिथे नियमांचा संच गहाळ असणे मृत बोगद्यासारखेच दिसते।

हँडशेक यशस्वी होतो, क्लायंटला पत्ता मिळतो, आणि परत काहीच येत नाही। दोन्ही दिशांसाठी आणि WAN भागासाठी नियम जोडा, कारण LAN पर्यंत पोहोचून इंटरनेटपर्यंत न पोहोचणारा बोगदा तिसऱ्या चाचणीत अयशस्वी होतो। अयशस्वी प्रयत्नानंतर साखळीचे काउंटर पाहा, कारण कधीही जुळला नाही असा नियम जुळून टाकून दिलेल्या नियमापेक्षा वेगळी समस्या आहे।

ip6tables -A FORWARD -i br0 -o tun0 -j ACCEPT
ip6tables -A FORWARD -i tun0 -o br0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
ip6tables -A FORWARD -i tun0 -o wan0 -j ACCEPT

एक दुष्परिणाम शेवटी बोगद्याला दोष देणाऱ्यांना पकडतो। फॉरवर्डिंग सुरू केल्यावर कर्नेल Router Advertisement द्वारे पत्ता संरचना वगळते, वेगळे सांगितले नाही तर, आणि अशा प्रकारे शिकलेला डीफॉल्ट मार्ग त्याच्यासोबत नाहीसा होतो। एकतर WAN इंटरफेसवर स्पष्ट डीफॉल्ट मार्ग पिन करा, किंवा तिथे जाणूनबुजून accept_ra 2 वर ठेवा। कोणत्याही बदलानंतर क्लायंट पुन्हा तपासण्यापूर्वी राउटरकडे अजूनही वापरण्यायोग्य IPv6 बाहेरचा मार्ग आहे याची खात्री करा।

वरचा भाग राउट करत नसेल तेव्हा शेजारी शोधाला उत्तर द्या

वरच्या भागातील उपकरणे कधीकधी सोपवलेल्या /64 ला स्वतःच्या दुव्याचे मानतात आणि VPN बॉक्सकडे कोणताही उप-उपसर्ग राउट करण्यास नकार देतात। असे झाल्यास प्रत्येक क्लायंट पत्त्यासाठी स्वतंत्रपणे शेजारी विनंत्या कुणीतरी उत्तर देणे आवश्यक आहे।

OpenVPN वाटलेला पत्ता client-connect हुकला उघड करते, त्यामुळे नोंदी हाताने ठेवलेल्या यादीऐवजी खऱ्या पूलचे अनुसरण करू शकतात। हुक ip -6 neigh add proxy $ifconfig_pool_remote_ip6 dev eth0 जोडतो, आणि जुळणारा client-disconnect हुक तो काढून टाकतो। काढून न टाकल्यास प्रॉक्सी तक्ता जुना होतो आणि नंतरचा क्लायंट कधीही न मिळालेल्या पत्त्याची नोंद वारसाहक्काने मिळवू शकतो। ip -6 neigh show proxy ने स्थितीची खात्री करा।

प्रॉक्सीला तात्पुरता उपाय माना। बोगद्याच्या /64 साठी राउटरकडे निर्देशित स्थिर मार्ग क्लायंट बदलांना तोंड देतो आणि विशेषाधिकारित शेल हुकची गरजच नसते।

बाहेरचा मार्ग अनुसरा, एका हॉपने

तीन टप्प्यांत बाहेरची चाचणी करा: प्रथम राउटरचा बोगदा पत्ता, नंतर LAN यजमान, आणि तिसरे म्हणजे traceroute6 द्वारे सार्वजनिक गंतव्य। पूल पहिल्याने, फॉरवर्डिंग आणि LAN फायरवॉल दुसऱ्याने, आणि वरच्या भागातून परतीचा मार्ग तिसऱ्याने सिद्ध होतो। प्रत्येक अपयश संपूर्ण रचना पुन्हा उघडण्याऐवजी शोध एका उपकरणापर्यंत मर्यादित करते।

बोगद्याच्या MTU कडे लक्ष द्या, कारण मार्गातील IPv6 राउटर तुमच्यासाठी तुकडे करणार नाहीत। खूप मोठा MTU स्वच्छ अपयशाऐवजी packet-too-big त्रुटी आणि थांबलेले TLS म्हणून दिसतो। तो स्पष्टपणे सेट करा आणि मर्यादेजवळच्या पेलोडसह चाचणी करा।