OpenVPN पुन्हा सुरू झाल्यानंतर IPv6 आउटगोइंग थांबते: प्रीफिक्सची मालकी तपासा
टनेल पुन्हा तयार झाल्यानंतर IPv6 थांबते। काहीही पुन्हा सुरू करण्यापूर्वी डेलिगेट केलेला प्रीफिक्स, क्लायंट पत्ते आणि परतीचा मार्ग कोणाचा आहे हे ठरवा।
IPv6 ज्या क्षणी OpenVPN पुन्हा सुरू होते त्या क्षणीच ट्राफिक पुढे जाऊ द्यायचे थांबवते, आणि IPv4 काम करत राहते। टनेल इंटरफेस पुन्हा तयार झाला, आणि त्याची IPv6 स्थिती सांभाळणारी दुसरी गोष्ट एकतर पत्ता गमावली किंवा प्रीफिक्स पोहोचण्यायोग्य करणारा मार्ग गमावला। तीन वेगवेगळे स्थितीचे भाग यात आहेत, आणि प्रत्येकाचा वेगळा मालक आहे: प्रदात्याचा डेलिगेट केलेला प्रीफिक्स आणि त्याचे आयुष्य, VPN क्लायंटना दिलेले पत्ते, आणि तो क्लायंट प्रीफिक्स सर्व्हरकडे परत पाठवणारा वरचा मार्ग। कोणत्याही डेमनला स्पर्श करण्यापूर्वी प्रत्येकाचा मालक ओळखा, कारण चुकीचा पुन्हा सुरू केल्यास समस्या एका दिवसासाठी लपते आणि पुढच्या जोडणीत परत येते।
IPv6 स्थितीचे तीन भाग, तीन मालक
| State | Typical owner | What breaks when it is wrong |
|---|---|---|
| Delegated prefix and lifetime | Upstream router or provider via DHCPv6-PD | Clients keep addresses that the upstream no longer routes |
| Client addresses inside the tunnel | OpenVPN server config or a delegation daemon | No global address, or an address outside the routed prefix |
| Return route for the client prefix | Upstream router, or the server's own routing table | Outbound works, replies never arrive |
टनेलच्या आत जागतिक व्याप्तीचा पत्ता एकटा पुरत नाही। वरच्या राउटरना तो प्रीफिक्स परत VPN सर्व्हरकडे पाठवावा लागतो, आणि सर्व्हरकडे त्यातील एक पत्ता योगायोगाने आहे म्हणून ते तसे करणार नाहीत।
म्हणूनच सार्वजनिक /64 टनेल पूलमध्ये कॉपी करणे धोकादायक आहे। सर्व्हरकडे राउट केलेला प्रीफिक्स हा वरची बाजू on-link मानत असलेल्या प्रीफिक्ससारखा नाही, आणि शेजारी शोध ही तफावत भरणार नाही।
काहीही बदलण्यापूर्वी सर्व्हरची स्थिती वाचा
स्थिती दोन वेळा कॅप्चर करा, एकदा IPv6 काम करत असताना आणि एकदा पुन्हा सुरू केल्यानंतर, नंतर तुलना करा। फक्त-वाचन दृश्ये पुरेशी आहेत, आणि देखभाल विंडोमध्ये त्यांचा काही खर्च होत नाही:
ip -6 addr show
ip -6 route show table all
ip -6 rule show
sysctl net.ipv6.conf.all.forwardingतीन ठोस फरक शोधा: गायब झालेला मार्ग, जुना किंवा अवैध आयुष्यात गेलेला पत्ता, आणि पुन्हा डेलिगेशननंतर बदललेला प्रीफिक्स जेव्हा VPN कॉन्फिगरेशन अजूनही जुन्याची जाहिरात करते।
पत्ता गायब झाला पण प्रीफिक्स बदलला नाही, तर तो नेमून देणारा डेमन इंटरफेस सांभाळणे थांबवला। प्रीफिक्स बदलला पण पत्ते बदलले नाहीत, तर क्लायंट कॉन्फिगरेशन जुने आहे। दोन्ही अपयश ब्राउझरवरून सारखीच दिसतात आणि त्यांच्यात काहीही सामायिक नाही।
dhcpcd ने टनेल सांभाळावे का ते ठरवा
dhcpcd इंटरफेस शोधू शकतो आणि DHCPv6 प्रीफिक्सचे भाग खालच्या इंटरफेसना डेलिगेट करू शकतो, आणि त्याचे कॉन्फिगरेशन डेलिगेशनची लक्ष्ये स्पष्टपणे नाव देऊ शकते। स्पष्ट लक्ष्य नसल्यास, त्याचे दस्तऐवजीकृत वर्तन इतर इंटरफेसना सामावून घेऊ शकते, आणि अशा प्रकारे टनेलला कोणीही नियोजित न केलेला पत्ता मिळतो।
दोन अटींनी तुम्हाला टनेलचे स्थिर अॅड्रेसिंग OpenVPN कडे ठेवण्याकडे ढकलले पाहिजे: सर्व्हर त्याच्या कॉन्फिगरेशनमध्ये निश्चित पत्ते ढकलतो, आणि पुन्हा जोडणीत टनेलचे नाव बदलते। दोन्ही खरे असल्यास, टनेल डेलिगेशन डेमनमधून जाणीवपूर्वक वगळा, कारण सांगणाऱ्या टिप्पणीसह।
जर त्याऐवजी टनेलकडे डेलिगेशन जाणीवपूर्वक असेल, तर प्रीफिक्स बदलाची हाताळणी अंमलात आणा। याचा अर्थ डेलिगेट केलेला प्रीफिक्स किंवा त्याचे आयुष्य बदलले तेव्हा प्रतिक्रिया देणे, सर्व्हरचा जाहीर केलेला क्लायंट प्रीफिक्स अद्ययावत करणे, आणि मार्ग पुन्हा जोडणे। त्या रचनेत इंटरफेस वगळल्यास नवीन प्रीफिक्स जाणणारा एकमेव घटक काढून टाकला जातो।
dhcpcd पुन्हा सुरू केल्याने स्थिती पुन्हा तयार होते म्हणून गोष्टी सुटल्यासारखे वाटू शकते, पण ते तुम्ही विचार न केलेल्या इंटरफेसचे कॉन्फिगरेशनही नूतनीकरण किंवा मागे घेते। ती पुनर्प्राप्ती प्रत्येक VPN पुनःसुरू नंतर ते आवश्यक ठरवत नाही। ते पुरावा म्हणून वापरलेले काउंटरही शून्य करते। तुम्ही खरोखर बदललेल्या इंटरफेसची लक्ष्यित पुन्हा लोडिंग पसंत करा।
IPv6 ची IPv4 NAT पासून स्वतंत्रपणे पडताळणी करा
फॉरवर्डिंग सुरू आहे आणि वरचा मार्ग खऱ्या क्लायंट प्रीफिक्सकडे निर्देश करतो याची खात्री करा, नंतर नवीन परवानगी दिलेले IPv6 कनेक्शन करा। क्लायंटचे स्वतःचे IPv6 मार्ग सारणीही तपासा, कारण सार्वजनिक पत्ता दाखवणारा क्लायंट त्याची विनंती टनेलने वापरली हे सिद्ध करत नाही।
IPv4 मास्करेडिंग वेगळी समस्या सोडवते: खाजगी स्रोतांसाठी परतीचा मार्ग। मागे घेतलेल्या IPv6 प्रीफिक्ससाठी ते काहीही करत नाही, आणि ते जोडल्याने IPv6 परत येणार नाही।
मालकीच्या नोंदीने समाप्त करा: कोणता घटक प्रीफिक्स डेलिगेट करतो, कोणता क्लायंट पत्ते नेमतो, कोणता परतीचा मार्ग धरतो, आणि पुन्हा जोडणीत प्रत्येकाचे काय होते। रनबुकमधील चार ओळी पुढच्या व्यक्तीला महत्त्वाचा असलेला डेमन शोधण्यासाठी तीन डेमन पुन्हा सुरू करण्यापासून वाचवतात।