VPN کے ذریعے Google API: صرف subnet نہیں، VIP پر روٹ کریں

SSH کے ذریعے آن پریمائس سرور میں داخل ہوں، ٹنل اوپر لائیں اور نجی VM جواب دیتا ہے؛ پھر Google API کی پہلی کال راستے کے بغیر ناکام ہو جاتی ہے۔ VM کا subnet اور API کے VIP پتے الگ منزلیں ہیں، اس لیے ایک کا راستہ دوسرے کو منتخب نہیں کرتا۔ نجی API کال کے کام کرنے سے پہلے تین شرطیں پوری ہونی چاہئیں۔ API کا نام VIP میں حل ہونا چاہیے، VIP سابقہ ٹنل سے اعلان ہونا چاہیے، اور VPC کو معلوم ہونا چاہیے کہ جواب کیسے واپس بھیجنا ہے۔ ping ان میں سے کچھ نہیں بتاتا، اور subnet میں مشین تک کام کرنے والا SSH سیشن بھی نہیں بتاتا۔

API کے VIP پتے الگ منزلیں ہیں

Google مقامی نیٹ ورک سے API تک رسائی کے لیے مخصوص VIP پتے شائع کرتا ہے، اور API ناموں کے لیے آپ کے DNS کو وہی پتے واپس کرنے ہوتے ہیں۔ دونوں چھوٹے سابقے ہیں اور کوئی بھی RFC 1918 فضا نہیں:

عوامی نظر آنے والے پتے اس بات کا مطلب نہیں کہ راستہ ٹنل چھوڑ دے عام انٹرنیٹ کے لیے۔ یہ سابقے اس لیے ہیں کہ مقامی کلائنٹ کسی من مانی ایگریس پوائنٹ کے بجائے معاون راستے سے Google کے سامنے والے حصوں تک پہنچ سکے۔ انہیں ٹنل سے وابستہ منزلیں سمجھیں، جانچنے کے لیے ہوسٹ نہیں۔ انٹرنیٹ ایگریس کے لیے لکھا گیا فائر وال اصول عام طور پر انہیں گرا دیتا ہے، اور یہی کال کے شروع ہونے سے پہلے ناکام ہونے کی ایک عام وجہ ہے۔

آپ کس اینڈ پوائنٹ تک پہنچتے ہیں، یہ DNS طے کرتا ہے

مقامی resolver کو ان ریکارڈز کی طرف موڑیں جو Google منتخب اینڈ پوائنٹ کے لیے دستاویز کرتا ہے، تاکہ ایپلیکیشن کو درکار نام اسی VIP کے ساتھ جواب دیں۔ محض googleapis.com کرنا کوئی فہرست نہیں: پیکیج رجسٹریاں، کنٹینر رجسٹریاں اور ہجرت کے کنیکٹر اپنے دستاویزی نام رکھتے ہیں۔ محدود VIP بھی ہر سروس نہیں اٹھاتا، اس لیے حل ہونے والا نام اب بھی غیر معاون ہو سکتا ہے۔ resolver کو چھونے سے پہلے وہ ڈومین لکھ لیں جن سے ایپلیکیشن واقعی رابطہ کرتی ہے۔

سروس نام کی جگہ VPC VM پتہ اندازہ لگانا حل نہیں، اور یہ عام طور پر DNS کے خلا کو تب تک چھپاتا ہے جب تک کوئی دوسرا کلائنٹ ناکام نہ ہو۔

VIP سابقہ کا اعلان کریں، باقی رکھیں

BGP پر مبنی کنکشن میں، Cloud Router کو منتخب VIP سابقہ کا اعلان کرنا ہوتا ہے تاکہ مقامی روٹر وہ حد مطلوبہ سیشن کے ذریعے سیکھ سکے۔ صرف VPC subnets کا اعلان اس حد کو شامل نہیں کرتا، اور مقامی روٹر ان پتوں کے لیے اپنا طے شدہ راستہ استعمال کرتا رہتا ہے۔ روٹنگ جدول میں سابقہ ہی واحد ثبوت ہے کہ اعلان سیشن سے گزرا۔

نیا شامل کرتے وقت موجودہ اعلانات برقرار رکھیں، کیونکہ روٹر سطح اور پیر سطح کے اختیارات کا دائرہ مختلف ہے، اور سیٹ بدلنے سے وہ نیٹ ورک واپس لیے جا سکتے ہیں جو پہلے سے کام کر رہے تھے۔ پھر پورے روٹر پر نہیں، ہر سیشن پر مؤثر اعلان دیکھیں۔ غائب سابقہ اور واپس لیا گیا سابقہ مقامی طرف سے یکساں دکھتے ہیں، اس لیے سیشن کا منظر ہی رہ جانے کو رگریشن سے الگ کرتا ہے۔

VPC طرف کو اپنا راستہ اور واپسی کا راستہ چاہیے

VPC کے اندر، VIP کا راستہ اگلے hop کے طور پر طے شدہ انٹرنیٹ گیٹ وے استعمال کرنا چاہیے، اور نام کے باوجود وہ ٹریفک Google کے نیٹ ورک ہی میں رہتا ہے۔ VPC کو VPN کے ذریعے مقامی ماخذ تک واپسی کا راستہ بھی چاہیے، جو اعلان شدہ سابقے سے الگ شے ہے۔ جب ٹنل اور کلائنٹ ایک ہی علاقے میں نہ ہوں تو دستاویزی علاقائی روٹنگ تقاضے مدنظر رکھیں۔

واپسی کا راستہ الگ سے جانچیں، کیونکہ کام کرنے والی درخواست کی سمت خراب جواب کی سمت چھپا سکتی ہے۔ دو سمتیں، دو راستے، اور ہر ایک اپنی علامت کے ساتھ ناکام ہوتا ہے۔

درخواست جانچیں، پھر انکار پڑھیں

ان VIP سے ICMP ایکو کو کوئی جواب نہیں ملتا، اس لیے ناکام ping کچھ ثابت نہیں کرتا اور کامیاب بہت کم۔ اصل کلائنٹ سے نام کا جواب اور منتخب راستہ دیکھیں، پھر جس سروس کی آپ کو پروا ہے اس پر مجاز HTTPS درخواست کریں۔ اگر درخواست سروس تک پہنچ کر مسترد ہو جائے تو اسناد، IAM اور لاگو ہونے والی سروس پیری میٹر پالیسی دیکھیں۔

نجی روٹنگ API کی اجازت نہیں دیتی اور یہ بھی نہیں بدلتی کہ شناخت کو کیا کرنے کی اجازت ہے۔ ٹرانسپورٹ کی کامیابی اور مجاز جواب الگ نتائج ہیں، اور آپ کو دونوں چاہئیں۔ IPv6 راستہ بھی واضح رکھیں، کیونکہ IPv4 سابقے ترتیب دینا IPv6 کو ترجیح دینے والے کلائنٹ کے بارے میں کچھ نہیں کہتا۔

Google کی مقامی نیٹ ورک سے Private Google Access کی رہنما DNS ریکارڈز اور روٹنگ تقاضوں کو ایک ساتھ محیط ہے، اس لیے اپنے resolver اور اعلان کی ترتیبات کا موازنہ کسی فورم پوسٹ سے نہیں، اسی سے کریں۔ پھر وہی درخواست دوبارہ چلائیں اور جواب اور راستہ اسی ٹکٹ میں درج کریں۔