तपाईंको GCP VM ले OpenVPN IPv6 पूललाई जवाफ किन दिन सक्दैन

तपाईंको IPv6 VPN क्लाइन्ट वर्कलोडसम्म पुग्छ, वर्कलोड सुरुङभित्र जवाफ दिन्छ, तर जवाफ कहिल्यै पुग्दैन। पहिलो प्रवृत्ति फायरवाल वा सुरुङलाई दोष दिने हो, र सामान्यतया दुवैमध्ये कोही दोषी हुँदैन। OpenVPN ले दिने ठेगाना सुरुङभित्र मात्र अस्तित्वमा रहने आन्तरिक नेटवर्क हो; fd42:90::/64 कुनै निश्चित VM पछाडि हुनुपर्छ भनी तपाईंले नभनेसम्म Google Cloud लाई थाहा हुँदैन।

यो तथ्य दुई छुट्टै प्रणालीले सिक्नुपर्छ, र तीमध्ये एउटा मात्र OpenVPN हो। VPC लाई केही फर्काएर पठाउनुअघि मार्ग चाहिन्छ, र VM लाई आउने कुरा फर्वार्ड गर्न अनुमति दिनुपर्छ। जुनसुकै आधामा गल्ती गरे पनि लक्षण उस्तै देखिन्छ।

पूल आन्तरिक नेटवर्क हो, सबनेट होइन

OpenVPN ले तपाईंले छानेको दायराबाट IPv6 ठेगाना दिन सक्छ, र त्यो दायरा सुरुङका दुई छेउले सहमति गरेको कल्पना हो। त्यो Google Cloud सबनेट होइन, VPC सबनेट सूचीमा देखिँदैन, र VM को नेटवर्क इन्टरफेसले ती ठेगाना पाउँदैन। त्यसैले क्लाइन्टलाई जवाफ दिने वर्कलोडले नेटवर्कले अरुटेबल ठान्ने ठेगानामा प्याकेट पठाउँछ।

पूललाई VPC पहिल्यै प्रयोग गर्ने हरेक दायराबाहिर राख्नुहोस्। तपाईंका अन्य सुरुङपछाडिका दायराबाट पनि बाहिर राख्नुहोस्। ओभरल्यापले सफा राउटिङ असफलतालाई लोडमुनि मात्र देखिने रोकिएको असफलतामा बदल्छ।

fd42:90::/64 जस्तो अद्वितीय स्थानीय ठेगानाकरण यो आन्तरिक नेटवर्कका लागि उचित छनोट हो। उपसर्गले डिजाइन स्वभावैले निजी छ भनी पनि सम्झाउँछ। ULA पूलमा केही पनि कुराले यसलाई सार्वजनिक इन्टरनेटमा वैध स्रोत बनाउँदैन।

VPC लाई गन्तव्य र अर्को हप दिनुहोस्

जवाफलाई गन्तव्य पूल र अर्को हप VPN VM भएको VPC मार्ग चाहिन्छ। हालको स्ट्याटिक-रुट कागजातले IPv6 गन्तव्य दायराहरू समेट्छ र कुन अर्को हप प्रकार योग्य छन् भनी सूचीबद्ध गर्छ, त्यसैले पुरानो IPv4 उदाहरण प्रतिलिपि गर्नुको सट्टा तपाईंको टोपोलोजीका लागि समर्थित स्वरूप जाँच्नुहोस्।

अर्को हपको ठेगाना वास्तवमै इन्स्टेन्सको क्लाउड इन्टरफेसमा तोकिएको हुनुपर्छ। VM को आन्तरिक सुरुङ ठेगाना त्यो ठेगाना होइन। त्यसैलाई प्रयोग गर्दा सफासँग इन्स्टल हुने र कहिल्यै कुनै प्याकेटसँग नमिल्ने मार्ग बन्छ। मार्ग लेख्नुअघि इन्टरफेस सूची पढ्नुहोस्।

मार्गको प्राथमिकता प्रविष्टिजत्तिकै महत्त्वपूर्ण छ। सबनेट मार्गहरू तपाईंले थप्ने अनुकूलित मार्गहरूभन्दा बढी विशिष्ट छन्, त्यसैले विद्यमान सबनेट दायराबाट काटिएको पूल अनुकूलित मार्ग जसरी लेखिए पनि सबनेट मार्गसँग हार्छ। छुट्टै पूल छान्नुहोस्, त्यसपछि मार्गले इन्स्टेन्सलाई अर्को हप र सही गन्तव्य उपसर्ग देखाउँछ भनी पुष्टि गर्नुहोस्:

gcloud compute routes create vpn6-return \
  --network=vpn-vpc \
  --destination-range=fd42:90::/64 \
  --next-hop-instance=openvpn-vm \
  --next-hop-instance-zone=europe-west1-b

फर्वार्डिङ दुई पटक सक्षम गर्नुपर्छ

मार्गले प्याकेट इन्स्टेन्ससम्म पुर्‍याउँछ। यसले इन्स्टेन्सलाई आफूलाई नठेगाना गरिएको कुरा फर्वार्ड गर्न तयार बनाउँदैन, र त्यो अनुमति दुई तहमा हुन्छ।

क्लाउडतर्फ इन्स्टेन्सको फर्वार्डिङ क्षमता सक्षम हुनुपर्छ; यो त्यो सेटिङ हो जसले VM लाई आफ्नो स्वामित्वमा नभएका ठेगानाका लागि ट्राफिक लिएर अगाडि पठाउन दिन्छ। गेस्टतर्फ आफ्नै IPv6 फर्वार्डिङ चाहिन्छ, किनकि प्याकेट आएपछि कर्नेलले छुट्टै निर्णय गर्छ। एउटै जवाफ सुरुङ पार गर्नुअघि दुवै खुला हुनुपर्छ।

sysctl -w net.ipv6.conf.all.forwarding=1

त्यसपछि फायरवाल नियमहरूले आन्तरिक स्रोत दायरालाई दुवै दिशामा अनुमति दिनुपर्छ। Google Cloud ले डिक्याप्सुलेट गरिएको प्याकेट मूल्याङ्कन गर्छ, त्यसैले केवल VPC सबनेट समेट्ने नियमले सुरुङ पहिल्यै सफल भइसकेपछि पूलको ट्राफिक खसाल्छ। पूललाई इनग्रेस नियममा स्रोत दायराका रूपमा थप्नुहोस्, र कुनै अनुकूलित इग्रेस नीतिले जवाफ अवरोध नगरेको जाँच्नुहोस्। निहित अनुमति नियमले पूर्वनिर्धारित केस समेट्छ, हातले लेखिएको इग्रेस नियमले समेट्दैन।

OpenVPN लाई कसको के छ भनी बताउनुहोस्

त्यो क्लाइन्टसँग गन्तव्यको स्वामित्व छ भनी थाहा भएपछि OpenVPN ले क्लाइन्टतर्फ फर्वार्ड गर्छ। पूलबाट आउने क्लाइन्ट ठेगाना पूल परिभाषित गर्ने सर्भर निर्देशनले सम्हाल्छ, तर क्लाइन्टपछाडिको सबनेट फरक व्यवस्था हो र त्यो क्लाइन्टका लागि स्पष्ट स्वामित्व प्रविष्टि चाहिन्छ।

दुवैलाई मिसाउँदा सर्भरमा पिङ चल्ने र त्यसपछाडि केही नचल्ने सुरुङ बन्छ। तपाईं कुन केस बनाउँदै हुनुहुन्छ त्यो निर्णय गर्नुहोस्, त्यसपछि दोस्रो push लाइन थपेर आशा गर्नुको सट्टा मिल्ने प्रविष्टि लेख्नुहोस्।

इन्टरनेट इग्रेस यो डिजाइनबाहिर राख्नुहोस्

निजी पहुँच र इन्टरनेट पहुँच छुट्टाछुट्टै योजना हुन्। राउटिङ र फर्वार्डिङ मिलेपछि ULA पूलले सुरुङमार्फत VPC वर्कलोडसम्म पुग्न सक्छ, र त्यही पूलको VPC मार्फत सार्वजनिक इन्टरनेटमा कुनै मार्ग हुँदैन, किनकि क्लाउड गेटवेले स्वेच्छाचारी सुरुङ स्रोतलाई आफ्नो मानेर स्वीकार गर्दैन।

क्लाइन्टलाई इन्टरनेट इग्रेस पनि चाहिएमा त्यसका लागि समर्थित ठेगानाकरण र राउटिङ डिजाइन योजना गर्नुहोस्, यसलाई निजी पूलबाट स्वतन्त्र राख्नुहोस् र दुई मार्ग अलग-अलग परीक्षण गर्नुहोस्। एउटा चल्ने मार्गले अर्कोबारे केही भन्दैन, र दुवैलाई मिसाउने डिजाइन भाँचिएको सुरुङजस्तो देखिने गरी असफल हुन्छ।