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 वापस नहीं आएगा।
स्वामित्व रिकॉर्ड के साथ समाप्त करें: कौन सा घटक प्रीफ़िक्स डेलिगेट करता है, कौन क्लाइंट पते असाइन करता है, कौन वापसी मार्ग रखता है, और रीकनेक्ट पर हर एक के साथ क्या होता है। रनबुक में चार पंक्तियाँ अगले व्यक्ति को यह ढूँढ़ने के लिए तीन डेमन रीस्टार्ट करने से बचाती हैं कि कौन मायने रखता था।