आपका GCP VM OpenVPN IPv6 पूल को उत्तर क्यों नहीं दे सकता

आपका IPv6 VPN क्लाइंट वर्कलोड तक पहुँचता है, वर्कलोड टनल के भीतर उत्तर देता है, और उत्तर कभी नहीं पहुँचता। पहली प्रवृत्ति फ़ायरवॉल या टनल को दोष देना है, और आमतौर पर इनमें से कोई दोषी नहीं होता। OpenVPN जो पता देता है वह एक आंतरिक नेटवर्क है जो केवल टनल के भीतर मौजूद है; Google Cloud को पता नहीं है कि fd42:90::/64 को किसी विशेष VM के पीछे होना चाहिए, जब तक आप उसे न बताएँ।

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

पूल एक आंतरिक नेटवर्क है, सबनेट नहीं

OpenVPN आपके चुने हुए रेंज से IPv6 पते दे सकता है, और वह रेंज एक कल्पना है जिस पर टनल के दोनों सिरे सहमत होते हैं। यह Google Cloud सबनेट नहीं है, यह VPC सबनेट सूची में नहीं दिखता, और VM का नेटवर्क इंटरफ़ेस वे पते नहीं पाता। इसलिए क्लाइंट को उत्तर देने वाला वर्कलोड एक ऐसे पते पर पैकेट भेजता है जिसे नेटवर्क अरूटेबल मानता है।

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

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

VPC को गंतव्य और अगला हॉप दें

उत्तर के लिए एक VPC रूट चाहिए जिसका गंतव्य पूल हो और जिसका अगला हॉप VPN VM हो। वर्तमान स्टैटिक-रूट दस्तावेज़ 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 के ज़रिए सार्वजनिक इंटरनेट तक कोई मार्ग नहीं है, क्योंकि क्लाउड गेटवे मनमाने टनल स्रोत को अपना नहीं मानेगा।

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