Kill switch فعال ہوتا ہے: کھلے TCP سیشنز کا کیا ہوتا ہے؟

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

خارج کرنا، مسترد کرنا اور ری سیٹ کرنا مختلف ہیں

ٹریفک خارج کرنے والا فائروال اصول پیکٹ کو پھینک دیتا ہے اور کچھ واپس نہیں بھیجتا، اس لیے بھیجنے والا اپنے ٹائمر کے مطابق دوبارہ بھیجتا رہتا ہے۔ TCP reset کے ساتھ مسترد کرنے والا اصول کنکشن کو فوراً بند کر دیتا ہے اور ایپلیکیشن کو خرابی نظر آتی ہے۔ زیادہ تر kill switch خارج کرتے ہیں، کیونکہ مسترد کرنا پالیسی کو ظاہر کر دیتا اور خارج کرنا مردہ نیٹ ورک کے رویے جیسا لگتا ہے۔

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

وقفہ رہنے کے دوران ایپلیکیشن کیا کرتی ہے

TCP بڑھتی تاخیر کے ساتھ دوبارہ بھیجتا ہے، اور Linux کا طے شدہ دوبارہ کوشش بجٹ سیکنڈوں میں نہیں، بلکہ تقریباً پندرہ منٹ میں ختم ہوتا ہے۔ تب تک ساکٹ نہ مفید طور پر کھلا ہے نہ بند۔ اپنے keepalive یا درخواست کی مقررہ مدت رکھنے والی ایپلیکیشنز اکثر پہلے ہار مان جاتی ہیں، اسی لیے ایک ہی مشین کے دو پروگرام ایک ہی خلل کے دوران مختلف رویہ رکھتے ہیں۔

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

فیصلہ کریں کہ بحالی ضروری ہے یا نہیں

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

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

بلاک اور بحالی کو الگ الگ جانچیں

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

ss -tnp state established '( dport = :443 )'
sudo conntrack -L -p tcp --dport 443
sudo tcpdump -ni any 'tcp port 443 and tcp[tcpflags] & tcp-syn != 0'

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

متوقع رویہ نفاذ کے اصول کے ساتھ لکھیں اور تاریخ ڈالیں۔ وہ اصول بدلنے والا اگلا شخص جاننا چاہیے کہ تعیناتی نے دو معاہدوں میں سے کس کا وعدہ کیا تھا۔