GCE پر OpenVPN: روٹس push کرنے سے پہلے alias IP شامل کریں

کلائنٹ Compute Engine VM پر OpenVPN سرور کو کال کرتا ہے، اسٹیٹس ونڈو کہتی ہے منسلک، اور VPC کے اندر کسی میزبان کو ping پھر بھی کہیں نہیں پہنچتا۔ فطرت کہتی ہے کہ ایک اور push لائن شامل کریں، اور یہ کبھی مسئلہ حل نہیں کرتا۔ Compute Engine فیصلہ کرتا ہے کہ پیکٹ کہاں جائیں، اپنی روٹ ٹیبل اور ان پتوں کی بنیاد پر جو VM کا انٹرفیس واقعی رکھتا ہے، اس لیے وہ tunnel pool جس کا VM مالک نہیں، ایسا pool ہے جہاں کوئی نہیں پہنچاتا۔

کنفیگریشن فائل کے بجائے ناکام ہونے والے پیکٹ کا پیچھا کریں، اور غائب حصے ترتیب سے سامنے آئیں گے۔

مرنے والے پیکٹ سے شروع کریں

SYN کلائنٹ سے نکلتا ہے، tunnel میں داخل ہوتا ہے اور VPC کے اندر کسی منزل کے لیے encapsulated پیکٹ کے طور پر VM تک پہنچتا ہے۔ OpenVPN اسے decapsulate کرتا ہے اور eth0 سے آگے بھیجنے کی کوشش کرتا ہے، جہاں fabric سب سے پہلے ایک سوال پوچھتا ہے: کیا یہ instance منزل کے پتے کا مالک ہے۔ کسی اور کے subnet سے کاٹا گیا tunnel pool اس سوال میں ناکام ہوتا ہے، اور پیکٹ کسی بھی روٹ یا firewall قاعدے کو دیکھنے سے پہلے ضائع ہو جاتا ہے۔

چنانچہ کلائنٹ سے VPC کی سمت کے دو الگ تقاضے ہیں، اور ان میں سے کوئی push ہدایت نہیں۔ VM کو alias رینج چاہیے جو tunnel pool کو ڈھانپے، اور یہی اسے ان پتوں کا جائز مالک بناتا ہے۔ VPC کو روٹ چاہیے جو ہر محفوظ prefix کے لیے VM کو next hop نامزد کرے۔ ایک بھی غائب ہو تو پیکٹ کہیں اور مرتا ہے، جبکہ کلائنٹ کو وہی خاموشی نظر آتی ہے۔

خرابی کو اسی ترتیب سے پڑھیں، کیونکہ کلائنٹ کی طرف سے دونوں شرطیں ایک جیسی لگتی ہیں۔ وہ tunnel جو منسلک بتاتا ہے جبکہ کوئی جواب نہیں دیتا، topology کے مسئلے کی نشانی ہے، بری cipher کی نہیں۔

کیا instance tunnel pool کا مالک ہے

VM کو اس کے اپنے subnet کے اندر ثانوی رینج دیں، پھر OpenVPN سے ٹھیک اسی رینج سے پتے تقسیم کروائیں۔ ایسے instance پر جس کا بنیادی پتہ 10.156.0.10/20 ہے، /28 alias pool کو ان پتوں سے الگ رکھتا ہے جو دوسرے instance پہلے ہی رکھتے ہیں:

gcloud compute instances network-interfaces update openvpn-vm \
  --zone=europe-west1-b \
  --aliases=eth0:10.156.1.0/28

پھر server ہدایت کو وہی بلاک بیان کرنا ہوگا۔ اس کا پہلا پتہ tunnel کا gateway بنتا ہے، اور باقی پتے کلائنٹس کو دیے جاتے ہیں۔ یہاں دو عدد ایک بلاک بیان کرتے ہیں، ایک نیٹ ورک اور ایک netmask، اور یہی وہ pool نحو ہے جس کی OpenVPN اب بھی توقع کرتا ہے۔

server 10.156.1.0 255.255.255.240

تصدیق کریں کہ پتہ واقعی interface پر پہنچا ہے، نہ کہ صرف OpenVPN کی کنفیگریشن میں۔ fabric وہی آگے بھیجتا ہے جو NIC بتاتی ہے، نہ کہ وہ جو daemon مانتا ہے۔ ایک حکم اسے طے کرتا ہے:

ip -4 addr show dev eth0

ثانوی پتہ جو کبھی eth0 تک نہیں پہنچتا، یا pool جو کسی دوسرے subnet سے اوورلیپ کرتا ہے، بعد میں وقفے وقفے سے ضیاع کے طور پر ظاہر ہوتا ہے، آغاز کی خرابی کے طور پر نہیں۔ daemon شروع ہوتا ہے، کلائنٹ جڑتے ہیں، اور صرف بعض منزلیں غلط برتاؤ کرتی ہیں۔ alias رینج چھوٹی رکھیں تاکہ pool روٹ ٹیبل میں آسانی سے پہچانا جائے۔ اسے کبھی ایسے subnet سے نہ کاٹیں جو پہلے سے کسی دوسرے instance کے زیر استعمال ہو۔

واپسی ٹریفک کو next hop دیں

VPC کے میزبان کا جواب tunnel pool میں کلائنٹ کے پتے کو بھیجا جاتا ہے، جو VPC کے کسی معلوم subnet سے تعلق نہیں رکھتا۔ اس pool کے لیے روٹ کے بغیر جواب پہلے ایسے hop پر رک جاتا ہے جہاں کوئی مماثلت نہیں، اور درخواست دور کے سرے پر کامیاب بھی ہو سکتی ہے۔

gcloud compute routes create openvpn-return \
  --network=prod-vpc \
  --destination-range=192.168.127.0/24 \
  --next-hop-instance=openvpn-vm \
  --next-hop-instance-zone=europe-west1-b \
  --priority=800

یہی روٹ ہر اس prefix کے لیے درکار ہے جو کلائنٹ کے پیچھے ہو، VPC کے اندر نہ ہو۔ ان prefixes کو اس کلائنٹ کی ccd فائل میں iroute اندراج بھی چاہیے۔ وہ اندراج سرور کی طرف کا حساب ہے: یہ سرور کو بتاتا ہے کہ کون سا کلائنٹ prefix کا مالک ہے، اور خود کلائنٹ پر کچھ نصب نہیں کرتا۔

push فہرست گفتگو کے کلائنٹ کی طرف کے لیے رکھیں، کیونکہ یہ صرف جڑنے والی مشین پر روٹس شامل کرتی ہے۔ VPC subnet کے لیے push لائن اور pool کی طرف واپس VPC روٹ ایک ہی راستے کے دو نصف ہیں، اور کوئی بھی نصف اکیلا ایسا tunnel بناتا ہے جو درخواستیں لے جاتا ہے مگر جواب نہیں۔

فائر والز، فارورڈنگ اور درمیانی hops

VPC کا firewall decapsulated پیکٹ کا جائزہ لیتا ہے، اس لیے ingress قاعدے کو tunnel pool اور ہر site prefix کی اجازت دینی ہوگی جو اس راستے سے VM تک پہنچے۔ default-deny رویہ یہاں خاموشی سے ناکام ہوتا ہے: پیکٹ decapsulation کے بعد ضائع ہو جاتا ہے، اور OpenVPN لاگ صحت مند سیشن دکھاتا ہے۔

ہر ایسے Linux میزبان پر جو forward کرتا ہے، ختم نہیں کرتا، دیکھیں کہ net.ipv4.ip_forward فعال ہے۔ ملکیت کا قاعدہ وہاں بھی لاگو ہے: ایسی مشین جو ایسے subnet کے لیے forward کرے جو اس کے پاس نہیں، پیکٹ کو ویسے ہی ضائع کرتی ہے جیسے VM کرتا۔ tunnel کو الزام دینے سے پہلے قدر پڑھیں۔

جب بالکل ایک prefix ناکام ہو

جزوی ناکامی پڑھنے کا آسان ترین معاملہ ہے، کیونکہ راستے کی ہر دوسری چیز پہلے ہی ثابت ہو چکی ہے۔ روٹ فہرست سے شروع کریں اور اس اندراج کی منزل رینج اور next hop پڑھیں جو prefix کو ڈھانپنا چاہیے، پھر instance کی تفصیل پڑھیں اور اس کی alias رینج کا موازنہ سرور کے تقسیم کردہ pool سے کریں۔

gcloud compute routes list --filter=destination-range~10.164.0.0
 gcloud compute instances describe openvpn-vm --format=get(networkInterfaces[0].aliasIpRanges)

غائب روٹ prefix کے لیے next hop کی عدم موجودگی کے طور پر ظاہر ہوتا ہے، جبکہ غائب alias interface پر ضائع شدہ پیکٹ کے طور پر؛ کلائنٹ سے دونوں ایک جیسے لگتے ہیں اور ان دو outputs میں بالکل مختلف ہیں۔ اگر دونوں موجود ہوں، باقی مشتبہ اس کلائنٹ کا ccd iroute ہے جو prefix کا دعوی کرتا ہے۔

چار قدریں tunnel کے پاس لکھیں: alias رینج، سرور pool، push شدہ prefixes، VPC روٹس۔ پرانا alias pool کے ہر پتے کو توڑتا ہے، پرانا روٹ ایک سمت توڑتا ہے، غائب push کلائنٹ سے prefix چھپاتا ہے، اور غلط iroute prefix کو غلط peer تک بھیجتا ہے۔ اگلا شخص جو subnet شامل کرے گا اسے یہ چاروں ایک جگہ چاہیے ہوں گے، اور یہ نوٹ شام سے سستا ہے۔