SaaS ٹریفک کو درست گاہک VPN تک کیسے بھیجا جائے
ایک دوسرے پر چڑھنے والے گاہک سب نیٹ مشترکہ روٹنگ کو توڑ دیتے ہیں۔ ایک علیحدگی ماڈل منتخب کریں، ہر کام کو تصدیق شدہ کرایہ دار سے باندھیں، اور آغاز سے پہلے کرایہ داروں کے درمیان راستوں کی جانچ کریں۔
ایک SaaS پلیٹ فارم درجن بھر گاہک نیٹ ورکس سے جڑتا ہے، اور ان گاہکوں میں سے دو اپنے بنیادی ڈیٹا بیس کے لیے 10.20.0.10 استعمال کرتے ہیں۔ کسی کام میں وہ پتہ پانے والے ورکر کو یہ جاننے کا کوئی طریقہ نہیں کہ کام کس ڈیٹا بیس کا مطلب ہے، اور مشترکہ روٹنگ جدول اسے خوشی سے اس سرنگ کی طرف بھیج دے گا جس کی طرف سابقہ اشارہ کرتا ہے۔ حل مزید سرنگیں نہیں ہیں؛ حل یہ فیصلہ کرنا ہے کہ کرایہ دار کی شناخت راستے میں کہاں داخل ہوتی ہے اور پتہ منصوبے کو کون سا علیحدگی ماڈل درکار ہے۔ تین شرطیں یہ انتخاب طے کرتی ہیں: کیا گاہک سابقے ایک دوسرے پر چڑھتے ہیں، غلطی کتنی دور تک پھیل سکتی ہے، اور کنیکٹر کون چلاتا ہے۔
دو گاہک ڈیٹا بیس، ایک منزل پتہ
IP پتہ ایک مقام ہے، شناخت نہیں۔ درخواست کو ایسا کرایہ دار لے جانا چاہیے جس کی تصدیق سرور نے کی ہو، اور منزل حل ہونے سے پہلے اس کرایہ دار کو نیٹ ورک سیاق منتخب کرنا چاہیے۔
جب ایسا نہیں ہوتا، ناکامی خاموش ہوتی ہے۔ کنکشن کامیاب ہوتا ہے، استفسار چلتا ہے، اور جواب غلط گاہک کے ڈیٹا بیس سے آتا ہے کیونکہ روٹنگ جدول میں 10.20.0.10 کے لیے ایک ہی اندراج تھا۔ DNS اسے مزید خراب کرتا ہے: کرایہ دار A کے سیاق میں حل شدہ کیش شدہ نام کرایہ دار B کے لیے چلنے والے کام کے ذریعے دوبارہ استعمال ہو سکتا ہے۔ پیکٹ میں کچھ بھی دونوں میں فرق نہیں کرتا، اس لیے کوئی دوبارہ کوشش منطق اسے درست نہیں کرتی۔
پہلے علیحدگی ماڈل طے کریں
مصنوعات کا موازنہ کرنے سے پہلے تینوں شرطیں لکھیں۔ چڑھاؤ فیصلہ کرتا ہے کہ ایک پتہ جگہ بالکل مشترک ہو سکتی ہے یا نہیں؛ اثر کا دائرہ فیصلہ کرتا ہے کہ روٹنگ غلطی سپورٹ ٹکٹ ہے یا خلاف ورزی؛ آپریشنل ملکیت فیصلہ کرتی ہے کہ آپ ہر کرایہ دار کے لیے کنیکٹر بیڑا چلا سکتے ہیں یا نہیں۔
| Condition | Hub with per-tenant route tables | Per-tenant connector context |
|---|---|---|
| Customer CIDRs overlap | No, unless you add 1:1 NAT | Yes, each context keeps its own view |
| A mistake must stay inside one VPC | Weak, routing is shared infrastructure | Strong, each connector has its own egress |
| You can run one fleet per tenant | Not required | Required |
اگر سابقے مختلف ہیں اور پالیسی کنٹرول شدہ مرکز کی اجازت دیتی ہے، تو ہر کرایہ دار کے لیے روٹنگ جدولوں والا ایک Transit Gateway قابل عمل ہے۔ اٹیچمنٹ انجمن اس روٹنگ جدول کا انتخاب کرتی ہے جو اس اٹیچمنٹ سے آنے والی ٹریفک کے لیے استعمال ہوتی ہے، اور پھیلاؤ فیصلہ کرتا ہے کہ جدول میں کون سے راستے نظر آتے ہیں۔ صرف اپنے جدول سے جڑا اور صرف اپنے سابقوں کا پھیلاؤ کرنے والا کرایہ دار اٹیچمنٹ مرکز تک پہنچتا ہے اور کہیں اور نہیں۔ یہ روٹنگ فیصلہ ہے، اور یہ تب تک درست رہتا ہے جب تک کوئی مشترکہ جدول میں طے شدہ راستہ نہ ڈالے۔
اگر سابقے ایک دوسرے پر چڑھتے ہیں، تو صرف روٹنگ انہیں الگ نہیں کر سکتی۔ آپ کو ہر کرایہ دار کے لیے الگ نیٹ ورک سیاق یا ایسا ترجمہ منصوبہ چاہیے جو ہر گاہک کی جگہ کو واضح معنی دے۔
Transit Gateway علیحدگی کا اصل مطلب کیا ہے
انجمن اور پھیلاؤ دو اہم کنٹرول ہیں، اور انہیں خلط ملط کرنا آسان ہے۔ انجمن بتاتی ہے کہ اس اٹیچمنٹ کا پیکٹ کس جدول میں تلاش کیا جاتا ہے؛ پھیلاؤ بتاتا ہے کہ کون سے جدول اس اٹیچمنٹ کے راستے سیکھتے ہیں۔ علیحدگی دونوں کو کرایہ دار کے لیے مخصوص بنانے سے آتی ہے، زیادہ اٹیچمنٹ بنانے سے نہیں۔
طے شدہ سب-کے-سب ترتیب آسان ہے اور علیحدگی نہیں۔ الگ روٹنگ جدولیں رابطہ محدود کرتی ہیں، لیکن ایک ہی روٹنگ سیاق میں ایک غیر تبدیل شدہ منزل پتے کو دو معنی نہیں دیتیں۔ اگر ایپلیکیشن کرایہ دار جاننے سے پہلے 10.20.0.10 حل کرے، تو روٹنگ تہہ ضروری معلومات پہلے ہی کھو چکی ہے۔
AWS نے 23 اکتوبر 2026 کو Transit Gateway اور Cloud WAN کے لیے اٹیچمنٹ سطح کا 1:1 NAT شامل کیا، جو معاون اٹیچمنٹ کے لیے چڑھاؤ کا جواب بدل دیتا ہے۔ Transit Gateway NAT دستاویز میزبان بٹس محفوظ رکھتے ہوئے مستقل، بے حالت اور برابر سابقہ IPv4 نقشوں کی وضاحت کرتی ہے۔ اس کے گرد ڈیزائن کرنے سے پہلے معاون اٹیچمنٹ اقسام اور علاقائی پابندیاں جانچیں۔
کام کو تصدیق شدہ کرایہ دار سے باندھیں
ہر کام کو سرور سے تصدیق شدہ کرایہ دار شناخت لے کر چلنا چاہیے، اور اس شناخت کو منتظم کی ملکیت والا کنکشن ریکارڈ منتخب کرنا چاہیے۔ ریکارڈ منظور شدہ نیٹ ورک سیاق، سروس پتہ، اسناد کا حوالہ اور وہاں اجازت شدہ کارروائیوں کے نام بتاتا ہے۔ غیر قابل اعتماد درخواست کو کبھی اپنا VPN شناخت کنندہ، گیٹ وے یا نجی ہدف فراہم نہیں کرنا چاہیے، کیونکہ درست لاگ ان ہر منسلک گاہک کی پتہ جگہ جانچنے کی اجازت نہیں ہے۔
الگ کنیکٹر ڈیزائن میں، کرایہ دار A کا کام A کے لیے مخصوص کنیکٹر کی طرف جاتا ہے جو A کے VPC میں چلتا ہے اور صرف A کے منظور شدہ وسائل تک پہنچ سکتا ہے۔ ایک ہی میزبان پر الگ کنٹینر وہ علیحدگی خود پیدا نہیں کرتے؛ نیٹ ورک نام فضا، راستے اور اخراج پالیسی کو اسے نافذ کرنا ہوگا۔ کنیکٹر کو کرایہ دار کی حد تک اسناد اور قطاریں بھی درکار ہیں، کیونکہ نجی راستہ مشترکہ راز یا مشترکہ کام کی شے کو محدود نہیں کرتا۔ مشترکہ ایپلیکیشن ورکر ٹھیک ہیں بشرطیکہ نیٹ ورک سیاق اور اسناد ہر کرایہ دار کے لیے منتخب ہوں، ہر میزبان کے لیے نہیں۔
صحت کی جانچیں کرایہ دار اور مرحلے کا نام لیں: سرنگ قائم، راستہ موجود اور حقیقی سروس درخواست کامیاب تین مختلف اشارے ہیں۔ چلتی سرنگوں کی مجموعی گنتی اس واحد گاہک کو چھپا دے گی جس کا کنیکٹر خراب ہے۔
ان راستوں کی جانچ کریں جنہیں ناکام ہونا چاہیے
آغاز سے پہلے تین ٹیسٹ چلائیں۔ اجازت شدہ A کارروائی کامیاب ہونی چاہیے، اجازت شدہ B کارروائی کامیاب ہونی چاہیے، اور جان بوجھ کر B کے کنیکٹر یا اس کے ترجمہ شدہ عرف کی طرف بھیجا گیا A کام بند انداز میں ناکام ہونا چاہیے۔ پھر ایک سرنگ توڑیں اور تصدیق کریں کہ کام صرف اسی کرایہ دار کے لیے ناکام ہوتا ہے، کسی دوسرے گاہک کے اسی نمبر والے سب نیٹ پر گرے بغیر۔ بحالی کی بھی جانچ ہونی چاہیے، کیونکہ پرانا راستہ یا کیش شدہ اسناد رکاوٹ سے زیادہ زندہ رہ سکتے ہیں۔
فن تعمیر الگ کنیکٹروں والے مشترکہ ورکر یا مکمل طور پر الگ کرایہ دار وسائل ہو سکتی ہے۔ ناقابل تبدیل بات ایک ہی ہے: تصدیق شدہ کرایہ دار سیاق راستہ اور اسناد منتخب کرتا ہے، اور کوئی راستہ تبدیلی کبھی کرایہ داروں کے درمیان ایپلیکیشن اجازت نہیں دیتی۔