VPC میں VPN کام کرتا ہے، لیکن منظم سروس کا وقت ختم ہو جاتا ہے
ٹنل آپ کے کنارے پر ختم ہوتا ہے، فراہم کنندہ کے سامنے والے دروازے پر نہیں۔ راستہ بدلنے سے پہلے ہدف کو VM پر میزبانی شدہ، VPC سے منسلک یا صرف عوامی کے طور پر درجہ بندی کریں۔
VPN کے ذریعے منظم ڈیٹا بیس تک پہنچنا عام طور پر ایسی وجہ سے ناکام ہوتا ہے جو کسی نے رن بک میں نہیں لکھی: ٹنل آپ کے نیٹ ورک کے کنارے پر ختم ہوتا ہے، جبکہ سروس کبھی اس کے آپ کے رخ پر نہیں تھی۔ راستوں کا جدول درست دکھائی دیتا ہے، ٹنل فعال ہونے کی اطلاع دیتا ہے، اور کنکشن پھر بھی وقت ختم کر دیتا ہے۔ نیچے دیے گئے چار جائزوں کو ترتیب سے کریں اور پہلے ایسے جائزے پر رکیں جس کی کامیابی کی شرط پوری نہ ہو، کیونکہ اس کے بعد کا ہر جائزہ یہ مانتا ہے کہ پچھلے پورے ہو چکے ہیں۔
جائزہ ایک: آخری نقطہ دراصل کہاں رہتا ہے؟
VPN گیٹ وے ان دو نیٹ ورکس کو جوڑتا ہے جن کی پتوں کا کنٹرول آپ کے پاس ہے۔ منظم سروس فراہم کنندہ کے اپنے سامنے والے دروازے کے پیچھے چلائی جاتی ہے، اور وہ دروازہ مصنوعات کے مطابق تین شکلوں میں سے ایک اختیار کرتا ہے۔ اگر آپ نہیں جانتے کہ کس شکل سے واسطہ ہے، تو کوئی راستہ کام مدد نہیں کرے گا، کیونکہ خرابی راستے کی خرابی ہی نہ ہو۔
| Shape | What it means | Pass condition |
|---|---|---|
| Software on your VM | Ordinary subnet addressing | Route and security group permit the client |
| Attached to your VPC | Private, but only inside that VPC | Endpoint associated, source allowed, route present |
| Provider-hosted, public endpoint | Optional private link, not private by default | A private endpoint exists and DNS points at it |
ضائع ہونے والی زیادہ تر دوپہریں اس درجہ بندی کو چھوڑ کر سیدھا راستوں کے جدول پر جانے سے بنتی ہیں۔ فراہم کنندہ کے ہاں میزبانی شدہ سروس جس کا آخری نقطہ عوامی ہے، نقشہ جو بھی کہے آپ کے ٹنل کے پیچھے نہیں ہے، اور VPC سے منسلک سروس کبھی کسی عوامی DNS جواب میں ظاہر نہیں ہوگی۔
جائزہ دو: VPC سے منسلک سروس جیسے ElastiCache
اس قسم کے کیش اپنے ہی VPC کے اندر پتے حاصل کرتے ہیں اور ان کا انٹرنیٹ کی طرف کوئی سامع نہیں ہوتا۔ اسی VPC میں ختم ہونے والا کلائنٹ VPN ان تک پہنچ سکتا ہے، لیکن صرف اس وقت جب تین شرطیں ایک ساتھ پوری ہوں۔ کیش کا آخری نقطہ ایسے سب نیٹ سے منسلک ہونا چاہیے جنہیں آپ کا ٹنل دیکھ سکے، اس کا سیکیورٹی گروپ اس پتے کی اجازت دے جہاں سے آپ کے کلائنٹ آتے ہیں، اور کلائنٹ کی طرف کیش سب نیٹ کو ڈھانپنے والا راستہ درکار ہے۔
عام غلطی یہ سمجھنا ہے کہ قریب کہیں کا کنکشن بھی شمار ہوتا ہے۔ VPN کو کسی دوسرے VPC سے جوڑنا، یا صرف peering پر انحصار کرنا، کیش کے سیکیورٹی گروپ یا اس کے سب نیٹ کے راستوں کے جدول کو آپ کے کلائنٹ تک نہیں بڑھاتا۔ جب موجودہ ٹنل کہیں اور ختم ہوتا ہے، تو اس VPC کے اندر رکھا جمپ ہوسٹ یا VPN سرور عام متبادل ہوتا ہے۔ وہ متبادل ڈیزائن نہیں بلکہ ایک گھیر ہے، اور رن بک میں اسے اسی طرح نشان زد کرنا چاہیے۔
جائزہ تین: عوامی نام والا PaaS آخری نقطہ
Azure Database for PostgreSQL ایک عوامی سرور نام پیش کرتا ہے۔ یہ آپ کو ایسا نجی پتہ نہیں دیتا جسے آپ hosts فائل میں پن کر کے گیٹ وے سے گزر سکیں۔ ورچوئل نیٹ ورک سروس آخری نقطے یہ محدود کرتے ہیں کہ کون سے سب نیٹ کسی وسیلے تک پہنچ سکتے ہیں؛ وہ VPN سے آنے والے مقامی کلائنٹ کو اجازت نہیں دیتے۔
نجی رسائی حاصل کرنے کا مطلب ہے نجی آخری نقطہ یا نجی لنک ڈیزائن متعارف کرانا، پھر نجی DNS زون شامل کرنا تاکہ عوامی نام انٹرنیٹ کے بجائے اسی آخری نقطے سے جواب دے۔ سروس آخری نقطے کے قاعدے کے ساتھ ملایا گیا VPN ایک اور معماری ہے جو صرف نقشے میں یکساں دکھتی ہے۔ App Service وہی منطق مخالف سمت سے اپناتا ہے: VNet انضمام ایپ کو VNet میں باہر جانے والی کالیں کرنے دیتا ہے، اور یہ آپ کے ٹنل سے اندر آنے والا نجی راستہ نہیں بناتا۔ اس لیے اندر آنے والی نجی رسائی کے لیے نجی آخری نقطہ، App Service ماحول یا ایپ کے آگے رکھا گیٹ وے درکار ہے، اور ان میں سے کیا استعمال کر سکتے ہیں یہ منصوبے پر منحصر ہے۔
جائزہ چار: اپنا سامنے کا دروازہ رکھنے والی مصنوعات
Firebase Hosting کو Cloud VPN سے منسلک نہیں کیا جا سکتا، کیونکہ میزبانی کی تہہ ایک عالمی سامنے کا حصہ ہے، کسی منصوبے کے VPC کے اندر کی چیز نہیں۔ دستاویزی متبادل یہ ہے کہ کنٹرول شدہ داخلہ نقطہ آپ خود بنائیں، کسی پراکسی مثال یا بالٹی پر قائم لوڈ بیلنسر کے ساتھ۔ کسی بھی طرح سائٹ خالص میزبانی مصنوعات رہنا چھوڑ دیتی ہے اور ایسی بنیادی ڈھانچہ بن جاتی ہے جو اب آپ چلاتے ہیں۔ اس تبادلے کو نام دینا مناسب ہے اس سے پہلے کہ کوئی وعدہ کرے کہ ٹنل اسے ڈھانپ لے گا۔
Private API Gateway VPC سروس کی طرف زیادہ قریب ہے: interface قسم کا VPC آخری نقطہ ایسا ہوسٹ نام شائع کرتا ہے جس کے جواب نجی پتے ہوتے ہیں، اور آپ کے احاطے سے ٹریفک ٹنل یا مخصوص انٹرکنیکٹ سے آتا ہے۔ آخری نقطہ API سے منسلک ہونا چاہیے، اور سرٹیفکیٹ نیز ہوسٹ نام کو کال کرنے والوں کے استعمال کردہ حسب ضرورت ڈومین سے میل کھانا چاہیے۔
Google Cloud VPN ٹنل ناموں سے نہیں بلکہ ہم منصب IP پتوں سے بندھے ہوتے ہیں۔ DNS فارورڈنگ الگ ترتیب دی جاتی ہے، اسی لیے ٹنل مکمل طور پر صحت مند ہو سکتا ہے جبکہ دور دراز نجی زون میں تلاشیں اب بھی ناکام ہوتی ہیں۔
پھر حد کا تعین کریں
وہی کنکشن VPC کے اندر موجود VM سے چلائیں۔ جب وہاں کامیاب ہو اور VPN کلائنٹ سے ناکام ہو، تو خلا کلائنٹ کے راستے اور سروس کے آخری نقطے کے درمیان ہے: کوئی راستہ، سیکیورٹی گروپ، آخری نقطے کی پالیسی یا نام۔ جب دونوں کوششیں ناکام ہوں، تو اس نیٹ ورک میں کچھ بھی سروس تک نہیں پہنچ سکتا، اور VPN کبھی رکاوٹ نہیں تھا۔
getent hosts db.internal.example
nc -vz db.internal.example 5432نام کی تلاش اور پورٹ جائزہ الگ الگ کریں، کیونکہ وہ مختلف وجوہات سے ناکام ہوتے ہیں اور یہ جوڑا بتاتا ہے کہ راستے کا کون سا آدھا حصہ ٹوٹا ہے۔ عوامی پتے میں حل ہونے والا نام آپ کو بتاتا ہے کہ نجی DNS زون کام نہیں کر رہا۔