بڑے ڈاؤن لوڈز اور VPN: راستہ درخواست پر ہی چنیں

’’بڑے ڈاؤن لوڈز VPN کے گرد بھیجیں اور چھوٹے جوابات اسی پر رکھیں‘‘ روٹنگ پالیسی جیسا لگتا ہے، مگر ہے نہیں۔ راؤٹر اسی لمحے دستیاب معلومات سے فیصلہ کرتا ہے: پتے، پورٹس، پروٹوکول، firewall کے نشانات، شناخت شدہ بہاؤ۔ جواب کا حتمی حجم اس مجموعے میں نہیں، کیونکہ وہ ابھی آیا نہیں، اور جب راؤٹر بائٹس ناپ سکے گا تب وہ انہیں پہلے ہی منتقل کر رہا ہوگا۔ اگر آپ کام کے مطابق رہنمائی چاہتے ہیں تو فیصلہ ایسے نقطے پر جانا چاہیے جو کام کو جانتا ہو، اور نیچے دی گئی چیک لسٹ بتاتی ہے کہ آپ کے ڈیزائن میں ایسا نقطہ ہے یا نہیں۔

راؤٹر جواب کیوں نہیں ناپ سکتا

جس لمحے کسی پیکٹ کو راستہ درکار ہوتا ہے، راؤٹر نے بہاؤ کے زیادہ سے زیادہ پہلے چند پیکٹ دیکھے ہوتے ہیں۔ وہ بتا سکتا ہے کہ کون کس سے بات کر رہا ہے، کس پروٹوکول پر، کس نشان کے ساتھ، اور اب تک کتنے بائٹس گزرے ہیں۔ اب تک کے بائٹس ماضی بیان کرتے ہیں۔ جواب کا حجم ایسے جواب کی خصوصیت ہے جو ابھی پیدا نہیں ہوا، اور ٹکڑوں میں یا اسٹریمنگ جوابات میں وہ شاید کبھی پیشگی معلوم نہ ہو۔

خود پروٹوکول کا میٹاڈیٹا بھی دکھنے سے کمزور ہے۔ HTTP ایسے جوابات کی اجازت دیتا ہے جن کی لمبائی جسم سے پہلے اعلان نہیں ہوتی، اور ایک صارف عمل کئی درخواستیں پیدا کر سکتا ہے جن کی مجموعی لاگت کسی ایک ہیڈر مالیت جیسی نہیں ہوتی۔ ہیڈر کو کام کا حجم سمجھنا روٹنگ غلطی سے پہلے ماڈلنگ غلطی ہے۔

جانچ 1: کیا ایسا فیصلہ نقطہ ہے جو راستہ چن سکے؟

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

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

جانچ 2: میٹاڈیٹا واقعی آپ کو کیا بتاتا ہے؟

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

ایپلیکیشن میٹاڈیٹا جس کی تائید کر سکتا ہے وہ کسی کام کے بارے میں فیصلہ ہے: یہ ورک فلو بلک سنک ہے، یہ انٹرایکٹو ہے، یہ معلوم ماخذ سے سافٹ ویئر اپ ڈیٹ ہے۔ یہ نیت کی زبان میں لکھی پالیسی ہے، اور جانچنے کے لیے کافی مستحکم ہے۔ ’’یہ جواب چالیس میگا بائٹ سے بڑا ہوگا‘‘ ایسی پالیسی نہیں۔

جانچ 3: کیا بہاؤ پہلے سے موجود ہے؟

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

conntrack -L -p tcp --dport 443 | head -5
ip route get 203.0.113.10
ss -tn state established dst 203.0.113.10

اس لیے عملی قاعدہ یہ ہے کہ رابطے کے بیچ میں ایک اخراج سے دوسرے پر منتقل ہونا نیا رشتہ ہے، ہجرت نہیں۔ اگر ڈیزائن کا تقاضا ہے کہ وہی رابطہ جاری رہے تو فیصلہ پہلے SYN سے پہلے لینا پڑتا، اور بعد میں شامل کوئی پیکٹ قاعدہ اسے صاف طور پر دوبارہ نہیں بنا سکتا۔

جانچ 4: کیا اصل ضرورت تاخیر ہے، اخراج نہیں؟

’’بلک ٹریفک کہیں اور بھیجو‘‘ والی بہت سی درخواستیں دراصل شکایات ہیں کہ بڑی منتقلی انٹرایکٹو کام کو سست محسوس کراتی ہے۔ یہ شیڈولنگ کا مسئلہ ہے، اور اس کا شیڈولنگ جواب ہے: موجودہ راستے پر منصفانہ قطار یا معاون بینڈوتھ پالیسی بلک بہاؤ کو چیٹ پیغام کو بھوکا رکھنے سے روکتی ہے، دونوں میں سے کسی کو ہلائے بغیر۔

tc qdisc replace dev eth0 root cake bandwidth 100mbit

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

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

تبدیلی کے ریکارڈ میں چیک لسٹ رکھیں: فیصلے کا نقطہ، اسے چلانے والا خانہ یا کام، بہاؤ پہلے سے ہے یا نہیں، اور ناپی گئی علامت تاخیر تھی یا اخراج۔ چار سوال، اور چاروں کا جواب دینے والی پالیسی وہ ہے جسے آپ چلا سکتے ہیں، صرف بچا نہیں سکتے۔