دو اوپر والے روابط مگر ایک سرنگ: سوئچنگ، توازن یا بندھن
ناکامی پر سوئچنگ، فی بہاؤ توازن اور ایک ہی بہاؤ کو یکجا کرنا تین مختلف وعدے ہیں۔ دو ڈیفالٹ راستے آپ کو پہلا دیتے ہیں، باقی دو نہیں۔
دو انٹرنیٹ لکیریں VPN کو زیادہ دستیاب بنا سکتی ہیں، اور کچھ کام کے بوجھ کے لیے تیز تر بھی، مگر ان دو میں سے کیا ہوگا یہ میکانزم طے کرتا ہے۔ دو ڈیفالٹ راستوں والا راؤٹر بندھا ہوا نہیں ہے، اور ہزاروں اندرونی کنکشن اٹھانے والی سرنگ بھی اب بھی ایک بیرونی بہاؤ ہے۔ وعدے کا نام پہلے رکھنا ہی ایک ڈیزائن اور ایک مہنگی مایوسی کے درمیان فرق ہے۔ نیچے دی گئی جدول اختیارات کو اس بنیاد پر الگ کرتی ہے کہ ہر ایک کو دور سرے پر کیا چاہیے اور رابطے کے ضیاع کا کسی منتقلی پر کیا اثر ہوتا ہے۔
تین وعدے، اور صرف ایک کو ساتھی چاہیے
ناکامی پر سوئچنگ ترجیحی رابطہ غائب ہونے پر بھی راستہ دستیاب رکھتی ہے۔ بہاؤ ہیش توازن آزاد بہاؤ کو دونوں اوپر والے رابطوں پر پھیلاتا ہے۔ ایک بہاؤ کو یکجا کرنا ایک منتقلی کو ایک ہی وقت میں دونوں رابطے استعمال کرنے دیتا ہے۔ یہ مختلف ضرورتوں والی مختلف مصنوعات ہیں، اور صرف آخری کو آپ کے راؤٹر سے باہر کسی چیز کے تعاون کی ضرورت ہے۔
| Mechanism | Far-end requirement | Effect on one transfer | What breaks under a link loss |
|---|---|---|---|
| Packet-spraying overlay | A cooperating endpoint that reassembles the stream | Packets can spread across both links | Reordering and buffering on the surviving path; its own recovery logic decides what continues |
| MPTCP subflows | A peer or proxy that accepts subflows | Subflows can share one connection | Surviving subflows continue if the peer keeps them alive |
| Flow-hash balancing | Nothing new; the existing tunnel endpoint is enough | One outer flow still follows one link | Flows hashed onto the dead link move; established sessions break |
| Link failover | Nothing new | One path at a time; the second link sits idle | The session stalls or restarts on the other link |
اس جدول میں کچھ بھی دوسری لکیر خریدنے کی وجہ نہیں ہے۔ یہ جو کرتی ہے وہ یہ ہے کہ سوئچنگ کے ڈیزائن کو بندھن سمجھ کر جانچنے سے روکتی ہے۔
راؤٹر کو سرنگ ایک ہی بہاؤ کیوں لگتی ہے
بوجھ متوازن کرنے والا راؤٹر ماخذ اور منزل کے پتوں کو پورٹس کے ساتھ ہیش کرتا ہے اور پھر پورا بہاؤ وہاں بھیجتا ہے جہاں ہیش اشارہ کرتا ہے۔ راؤٹر کی نظر میں VPN سرنگ ایسا ہی ایک بہاؤ ہے، اندر کچھ بھی چل رہا ہو۔ اندرونی کنکشن کبھی ہیش کے فیصلے تک نہیں پہنچتے، کیونکہ بیرونی ہیڈر راستہ پہلے ہی طے کر چکا ہوتا ہے۔ اسی لیے دوسرا اوپر والا رابطہ بہت سے صارفین کے لیے کل گنجائش دوگنی کر سکتا ہے اور ایک صارف کی بڑی منتقلی میں کچھ نہیں بدلتا۔
دو الگ سرنگیں آپ کو دو امیدوار دے سکتی ہیں، مگر انہیں اب بھی ایک سوچی سمجھی پالیسی چاہیے جو ٹریفک تقسیم کرے اور جوابات اسی راستے پر رکھے جس نے درخواست اٹھائی تھی۔ اس قدم کو چھوڑنے کا عام نتیجہ غیر متناسب راؤٹنگ ہے۔ کم از کم ایسی پالیسی چاہیے جو بہاؤ، ترجیحی رابطہ اور بیک اپ رابطہ نام لے۔
ایتھرنیٹ بندھن غیر متعلقہ فراہم کنندگان کے پار نہیں جاتا، کیونکہ دور سرے کو یکجا کرنے کے پروٹوکول میں شریک ہونا پڑتا ہے۔ دو ISP کے درمیان بندھن ایک تحقیقی منصوبہ ہے جب تک کوئی تعاون کرنے والا آخری نقطہ موجود نہ ہو۔
کثیر راستہ TCP کو دونوں سروں پر کیا چاہیے
Linux کی Multipath TCP دستاویز ایک کنکشن سے تعلق رکھنے والے کئی ذیلی بہاؤ بیان کرتی ہے۔ ایک سرے پر کرنل کی حمایت بذات خود کچھ نہیں بدلتی، کیونکہ ساتھی کو بھی وہ ذیلی بہاؤ قبول کرنے پڑتے ہیں۔ دور کی طرف پراکسی دوسرا عام انتظام ہے، اور یہ اپنی گنجائش اور دستیابی والا جزو بن جاتا ہے جس کی منصوبہ بندی کرنی پڑتی ہے۔ وہی منطق WireGuard کے لیے آسان جواب کو مسترد کرتی ہے، جس کی ترسیل UDP ہے: MPTCP TCP ذیلی بہاؤ بڑھاتا ہے اور ڈیزائن میں کچھ اور کے بغیر اس سرنگ کو یکجا نہیں کر سکتا۔
کرنل کی خصوصیت فعال ہے یا نہیں یہ اس کے گرد ڈیزائن کرنے سے پہلے جانچیں، کیونکہ بہت سی تقسیمیں اسے بند حالت میں دیتی ہیں۔ یہ تین کمانڈیں ایک منٹ میں جواب دیتی ہیں۔
sysctl net.mptcp.enabled
ss -M | head
ip mptcp limits showبروشر نہیں، کام کے بوجھ سے چنیں
اگر کام کا بوجھ بہت سے آزاد سیشن ہیں، تو بہاؤ ہیش توازن دور سرے کے تعاون کے بغیر گنجائش بڑھا سکتا ہے۔ اگر ایک بڑی منتقلی ہے، تو صرف یکجا کرنے کا ڈیزائن مدد دے گا، اور اس ڈیزائن کو تعاون کرنے والا ساتھی چاہیے۔ اگر ضرورت یہ ہے کہ رابطہ مرنے پر بھی کام جاری رہے، تو جواب سوئچنگ ہے اور ایک منتقلی کی تھروپٹ غیر متعلق ہے۔
ضرورت کو ایک جملے میں لکھیں جس میں فعل ہو: ایک بیک اپ دوگنا تیز مکمل ہوتا ہے، یا گرا ہوا رابطہ سیشن ختم نہیں کرتا۔ دھندلے اہداف ایسے ڈیزائن پیدا کرتے ہیں جنہیں کوئی قبول بھی نہیں کر سکتا اور نہ رد۔ پھر طے کریں کہ دور سرا کیا ہو سکتا ہے، کیونکہ سب سے سستا اختیار اکثر وہی ہوتا ہے جو وہاں کچھ نیا نہیں مانگتا۔ یہ پابندی پہلی ملاقات سے پہلے ہی بروشر کے بیشتر دعوے ہٹا دیتی ہے۔
ضرورت کی دستاویز میں تینوں وعدے الگ رکھیں۔ تینوں کا دعویٰ کرنے والا ڈیزائن عام طور پر ایک دیتا ہے اور باقی خاموشی سے فرض کر لیتا ہے۔ اگلا حصہ جانچتا ہے کہ حقیقت میں کون سا دیا جاتا ہے۔
ایک منتقلی اور بہت سی جانچیں، پھر ایک رابطہ کھینچیں
ایک مسلسل منتقلی کا موازنہ اسی منزل کی طرف کئی متوازی منتقلیوں سے کریں، اور ہر ایک کے لیے ضیاع، تاخیر اور فی رابطہ استعمال درج کریں۔ اگر صرف متوازی سیشنوں میں فائدہ ہو تو یہ بہاؤ کی تقسیم کی طرف اشارہ کرتا ہے، ایک بہاؤ کے یکجا کرنے کی طرف نہیں۔ ایک اوپر والے رابطے کے ضیاع کو الگ جانچیں، کیونکہ دونوں رابطے چلنے کے دوران گنجائش قائم شدہ سیشن کے لیے سوئچنگ کے بارے میں کچھ نہیں کہتی۔ ہر جانچ سے پہلے اور بعد میں راستہ، ساکٹ اور دوبارہ بھیجنے کے شمار کنندگان درج کریں۔
ip route show default
ip route get 10.80.0.5
mtr -n -c 20 -r 10.80.0.5جب ایک ہی منتقلی اب بھی ایک اوپر والا رابطہ استعمال کرتی ہے، تو ڈیزائن وہی کر رہا ہے جو بہاؤ ہیش کا مطلب ہے۔ جب متوازی منتقلیاں دونوں پر پھیل جاتی ہیں، تو توازن کام کرتا ہے اور یکجا کرنا نہیں۔ درج کریں کہ ڈیزائن تین وعدوں میں سے کون سا واقعی نبھاتا ہے، اور اگلی گنجائش کی گفتگو بیچنے والے کے دعوے سے نہیں، ثبوت سے شروع ہوگی۔