तुमचा 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 ला गंतव्य आणि पुढील हॉप द्या

उत्तरासाठी अशा 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 मार्फत सार्वजनिक इंटरनेटकडे मार्ग नाही, कारण क्लाउड गेटवे अनियंत्रित टनल स्रोत आपल्या मालकीचा म्हणून स्वीकारणार नाही.

क्लायंटना इंटरनेट इग्रेसही हवा असल्यास, त्यासाठी समर्थित अ‍ॅड्रेसिंग आणि राउटिंग डिझाइनची योजना करा, ते खाजगी पूलपासून स्वतंत्र ठेवा आणि दोन्ही मार्ग वेगळे तपासा. एक चालणारा मार्ग दुसऱ्याबद्दल काहीही सांगत नाही, आणि दोन्ही एकत्र करणारे डिझाइन तुटलेल्या टनलसारखे दिसणाऱ्या पद्धतीने अयशस्वी होते.