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 फर्केर आउँदैन।
स्वामित्वको रेकर्डसँग अन्त्य गर्नुहोस्: कुन घटकले प्रिफिक्स डेलिगेट गर्छ, कुनले क्लाइन्ट ठेगाना तोक्छ, कुनले फिर्ती मार्ग राख्छ, र पुनः जडानमा प्रत्येकलाई के हुन्छ। रनबुकका चार लाइनले अर्को व्यक्तिलाई महत्त्वपूर्ण डेमन खोज्न तीन डेमन पुनः सुरु गर्नबाट बचाउँछन्।