آپ کا 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 کے ذریعے عوامی انٹرنیٹ تک کوئی راستہ نہیں، کیونکہ کلاؤڈ گیٹ وے من مانی سرنگ ماخذ کو اپنا نہیں مانے گا۔

اگر کلائنٹس کو انٹرنیٹ اخراج بھی درکار ہو، تو اس کے لیے معاون ایڈریسنگ اور روٹنگ ڈیزائن کی منصوبہ بندی کریں، اسے نجی پول سے آزاد رکھیں اور دونوں راستے الگ الگ جانچیں۔ ایک چلتا راستہ دوسرے کے بارے میں کچھ نہیں بتاتا، اور دونوں کو ملانے والا ڈیزائن ٹوٹی سرنگ جیسا دکھنے والے طریقے سے ناکام ہوتا ہے۔