ہب اینڈ اسپوک بمقابلہ فل میش: آپ کی سائٹس کے لیے کون سی VPN ٹوپولوجی موزوں ہے
دو کام کرنے والی سرنگیں کوئی ٹوپولوجی نہیں ہیں۔ ہب، میش یا چند براہ راست لنکس والا ہب چننے سے پہلے گزرگاہ، ناکامی کا رویہ اور تبدیلی کی لاگت کا موازنہ کریں۔
دو برانچ دفتر سارا دن ایک دوسرے سے بات کرتے ہیں، اور ان کے درمیان سرنگ کسی دوسرے علاقے کے ڈیٹا سینٹر سے گزر کر گھومتی ہے۔ ہر درخواست اس چکر کی قیمت دو بار ادا کرتی ہے، اور کسی کو تب تک خبر نہیں ہوتی جب تک فائل سنک غلط محسوس ہونے نہ لگے۔ ٹوپولوجی کا سوال دراصل یہیں سے شروع ہوتا ہے: اس بات سے نہیں کہ کون سا خاکہ زیادہ مضبوط لگتا ہے، بلکہ اس بات سے کہ آپ کس ٹریفک پیٹرن کی قیمت ادا کر رہے ہیں۔ دونوں ڈیزائن کام کرتے ہیں، اور مختلف طریقوں سے، مختلف لاگتوں پر ناکام ہوتے ہیں۔
باقی ہر چیز سے پہلے ہم منصب تعلقات گن لیں
اگر N سائٹس ہیں تو فل میش کو N ضرب N منفی ایک، تقسیم دو کے برابر سرنگیں چاہیے؛ ہب کو N کافی ہیں۔ پانچ سائٹس پر یہ دس بمقابلہ پانچ ہے، جو اب بھی سنبھلنے والا لگتا ہے۔ پندرہ پر یہ 105 بمقابلہ پندرہ ہے، اور فرق اب حساب کا نہیں، عملے کا ہے۔
ان تعلقات میں سے ہر ایک ایسی حالت اٹھائے ہوتا ہے جس کی ملکیت آپ کو سنبھالنی ہوتی ہے۔ IPsec میں اس کا مطلب ایک سیکیورٹی ایسوسی ایشن، ایک شناخت، ایک کلید یا سرٹیفکیٹ، مُرد ہم منصب کی نشاندہی، اور ہر دور دراز پریفکس کے لیے کم از کم ایک روٹ ہے۔ WireGuard میں اس کا مطلب ایک عوامی کلید اور ہر ہم منصب کے لیے ایک AllowedIPs بلاک ہے، جو فی ہم منصب سستا ہے مگر ساتھ میں کوئی دریافت بالکل نہیں: نئی سائٹ بہرحال ہر موجود سائٹ پر کنفیگریشن کی تبدیلی ہی ہے۔
فیصلہ خاکہ نہیں، ٹریفک کا امتزاج کرے
اگر برانچ ٹریفک زیادہ تر کسی مرکزی ERP یا فائل کلسٹر کی درخواستیں ہیں تو ہب کوئی سمجھوتہ نہیں، وہی درست شکل ہے: ٹریفک ویسے بھی وہیں جانا چاہتا تھا، اور ایک پالیسی نقطہ کا آڈٹ جوڑی وار اصولوں کے میش سے آسان ہے۔ میش اپنی پیچیدگی کا حق تب کماتا ہے جب برانچیں آپس میں ڈیٹا کا تبادلہ کریں: دو دفتروں کے درمیان نقل، سائٹس کے درمیان آواز، ایسی CAD شیئرنگ جسے درجن بھر انجینئر سارا دن کھولتے ہیں۔
مشکل صورتیں ان کے درمیان ہوتی ہیں، اور وہی اکثریت ہیں۔ تنظیمی چارٹ سے اندازہ لگانے کے بجائے بحث سے پہلے پیمائش کریں۔
| Signal | Points to a hub | Points to a mesh |
|---|---|---|
| Branch-to-branch traffic | Occasional, small | Dominant, all day |
| Site count | Growing, past ten | Small and stable |
| Change rate | Frequent adds and moves | Rare |
| Failure tolerance | A second hub is affordable | Every site must survive alone |
جدول کو اصول نہیں، برابری توڑنے والا سمجھ کر پڑھیں۔ چار میں سے تین قطاریں ایک طرف اشارہ کریں تو عام طور پر ڈیزائن وہیں طے ہو جاتا ہے؛ تقسیم کا مطلب ہائبرڈ ہے، اور پختہ نیٹ ورک زیادہ تر آخر کار وہی چلاتے ہیں۔
ہب کو فارورڈ کرنے کا حکم دینا پڑتا ہے
کام کرنے والی دو اسپوک تا ہب سرنگیں اسپوک تا اسپوک رسائی پیدا نہیں کرتیں۔ ہب میں IP فارورڈنگ فعال ہونی چاہیے، ہر اسپوک نیٹ ورک تک ایک روٹ، ایسا فائر وال اصول جو اس گزر کو اجازت دے، اور واپسی کا راستہ طے شدہ ہونا چاہیے؛ ہر اسپوک کو دوسری سائٹ کے پریفکس کے لیے ایک روٹ چاہیے۔ لینکس ہب پر یہ net.ipv4.ip_forward=1 کے ساتھ ایسی FORWARD زنجیر ہے جو اس جوڑے کو خاموشی سے گرا نہ دے، اور پالیسی پر مبنی IPsec میں یہ وہ ٹریفک سلیکٹر ہیں جو دونوں سروں پر دور دراز اسپوک سب نیٹ درج کریں۔ strongSwan کے فارورڈنگ نوٹس کرنل اور فائر وال کا پہلو ڈھانپتے ہیں جب کمی اسی پرت میں ہو۔ ایک سستا امتحان یہ ہے کہ ایک اسپوک سے دوسرے کی سروس کی طرف ٹریفک بھیجیں اور ہب کے کاؤنٹر دیکھیں؛ ایسا اصول جو کبھی نہ بڑھے اس کا مطلب ہے ترتیب غلط ہے، روٹ نہیں۔
مرکزی پالیسی بھی کارآمد حصہ ہے۔ برانچوں کو مشترکہ سروسز تک رسائی دی جا سکتی ہے بغیر ایک دوسرے تک پہنچنے کی اجازت کے، اور اس رسائی میٹرکس کو صریحاً لکھ لینا قابلِ قدر ہے۔ غائب روٹس کسی پڑھنے کے قابل اصول کا برا نعم البدل ہیں۔
آدھے ادھورے ورژن سے بچیں: اسپوک A ہب کے ذریعے اسپوک B تک روٹ کرتا ہے، ہب دونوں طرف روٹ کرتا ہے، مگر ہب کا فائر وال A سے نئی کنکشنز کی اجازت دیتا ہے، B سے نہیں۔ پہلی سمت ٹیسٹ میں ٹھیک رہتی ہے اور دوسری لٹک جاتی ہے، جو روٹنگ کی خرابی لگتی ہے مگر ہے نہیں۔
پہلے ناکامی کا ڈیزائن بنائیں، پھر عام راستے کا
ایک ہب مشترکہ انحصار اور گزرگاہ کی رکاوٹ ہے، اور فالتو پن وہیں ہے جہاں ہب کے ڈیزائن عام طور پر غلط ہوتے ہیں۔ دو ہب کا مطلب ہے ہر اسپوک دو سرنگیں رکھے، اور واپسی کے راستے کو باہر جانے والے سے متفق ہونا چاہیے؛ جب ایسا نہ ہو تو حالت رکھنے والا فائر وال جوابات گرا دیتا ہے اور علامت ایسی کنکشن ہوتی ہے جو کھل کر مر جاتی ہے۔ بڑی تعیناتیاں اسے مستقل پریفکس کے بجائے سرنگوں پر چلنے والے روٹنگ پروٹوکول سے حل کرتی ہیں، جو زیادہ مشینری ہے مگر اندازے کو ختم کر دیتا ہے۔ آپ جو بھی چنیں، واپسی کا راستہ باہر جانے والے کے ساتھ لکھیں، کیونکہ جس نصف کی کوئی جانچ نہیں کرتا وہی واپسی والا نصف ہے۔
میش اس خطرے کو پھیلا دیتا ہے: ایک سائٹ کا لنک گرنے سے باقی الگ تھلگ نہیں ہوتے۔ یہ ان جگہوں کو بھی بڑھا دیتا ہے جہاں راستے کا انتخاب آپ کو حیران کر سکتا ہے، اور ایپلیکیشن سیشنز پھر بھی مدد کے بغیر راستے کی تبدیلی سے نہیں بچتے۔
کوئی بھی ڈیزائن TCP سیشن کو فیل اوور کے پار خود بخود زندہ نہیں رکھتا۔ اگر ایپلیکیشن دوبارہ جڑ نہ سکے تو ٹوپولوجی آپ کا مسئلہ نہیں۔
تبدیلی کی لاگت سے چنیں، پھر راستوں کی تصدیق کریں
ہب سے شروع کریں، کیونکہ غلط ہونے پر اس کا نقصان سستا ہے، اور ان جوڑوں کے لیے براہ راست سرنگیں شامل کریں جن کا ٹریفک اسے جائز رکھتا ہے۔ وہ ہائبرڈ فیصلہ نہ کرنے کی ناکامی نہیں؛ وہی ڈیزائن ہے جس پر زیادہ تر تنظیمیں ایک سال کے اندر پہنچ جاتی ہیں۔ اہم بات یہ ہے کہ ہر براہ راست لنک کی ایک بیان کردہ وجہ اور ایک ذمہ دار ہو۔
پھر ایک نہیں، دونوں خاکوں کی تصدیق کریں۔ عام راستے کے لیے، ہر سائٹ سے ہر سروس پریفکس تک traceroute چلائیں اور دیکھیں کہ ہاپ خاکے سے میل کھاتے ہیں۔ ناکامی کے راستے کے لیے، ایک سرنگ بند کریں اور دہرائیں، کیونکہ ایسا راستہ جو صرف تب چلے جب سب کچھ اٹھا ہو، ڈیزائن نہیں ہوا، صرف کنفیگر ہوا ہے۔
دونوں خاکے رسائی میٹرکس کے ساتھ رکھیں، اور سائٹ شامل ہونے پر ان پر دوبارہ نظر ڈالیں؛ آپ جس لاگت کا انتظام کر رہے ہیں وہ اگلی تبدیلی کی لاگت ہے، موجودہ تصویر کی خوبصورتی نہیں۔