صرف خفیہ کاری پھر سے بھیجے گئے پیکٹ کو کیوں نہیں روکتی

محفوظ پیکٹ خفیہ کاری کے لحاظ سے ختم نہیں ہوتے، اس لیے پانچ منٹ پہلے درست رہنے والا پیکٹ اب بھی درست ہے، کیونکہ خفیہ کاری اور سالمیت کا تحفظ اس بارے میں کچھ نہیں کہتے کہ بائٹس کب بنائے گئے۔ جو حملہ آور ٹریفک پکڑ کر دوبارہ بھیج سکتا ہے اسے خفیہ تحریر توڑنے کی ضرورت نہیں۔ اسی لیے ہر سنجیدہ ٹنل پروٹوکول اپنی چابیوں کے ساتھ ترتیب کی حالت رکھتا ہے۔

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

درست خفیہ تحریر تازہ خفیہ تحریر نہیں ہے

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

وہ اصول لاگو کرنا سستا ہے اور کہنا بھی سستا ہے: دیے گئے محفوظ پیکٹ کو دی گئی چابی کے تحت ایک بار قبول کریں۔ اس میدان میں باقی سب کچھ اس پر منحصر ہے کہ عمل درآمد اس ایک بار کو کیسے ٹریک کرتا ہے۔

دوبارہ بھیجے جانے کے رد کو ڈکرپشن کی ناکامی کے طور پر پڑھنا آپ کو بالکل غلط ذیلی نظام کی طرف بھیجتا ہے۔

ترتیب کا نمبر اور ایک ونڈو

IPsec ESP ترتیب کا نمبر رکھتا ہے اور وصول کنندہ حال ہی میں قبول شدہ قدروں کی سرکتی ونڈو رکھتا ہے، جبکہ ESP تفصیل طے شدہ ونڈو سائز اور اسے بڑھانے کے اختیار کی وضاحت کرتی ہے۔ WireGuard مختلف راستہ اختیار کرتا ہے: ہر چابی کے لیے کاؤنٹر اور اس کے خلاف واضح جانچ۔ کوئی ڈیزائن یہ نہیں مانتا کہ پیکٹ ترتیب سے آتے ہیں، کیونکہ حقیقی نیٹ ورک انہیں دوبارہ ترتیب دیتے ہیں۔ دونوں دوبارہ ترتیب برداشت کرتے ہیں، اور کوئی بھی تکرار برداشت نہیں کرتا۔

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

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

nstat -az | grep -i XfrmIn
ip -s xfrm state | head -n 30
wg show wg0 transfer

حالت چابی کی ہے، میزبان کی نہیں

کاؤنٹر کی حالت کسی حفاظتی انجمن یا چابی کے دور سے بندھی ہوتی ہے، اس لیے چابی بدلنے سے نیا سیاق و سباق اور اپنا ترتیب کا میدان بنتا ہے۔ چابی بدلے بغیر کاؤنٹر صاف کرنا، یا دستی ری سیٹ کے بعد انجمن دوبارہ استعمال کرنا، اس مفروضے کو توڑتا ہے جس پر وصول کنندہ کی ونڈو کھڑی ہے۔ اسی لیے پروٹوکول کے زیر انتظام چابی کی تبدیلی موجود ہے، نہ کہ آپریٹر کو نظر آنے والا ری سیٹ بٹن۔

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

کچھ بند کرنے سے پہلے وجہ کی تشخیص کریں

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

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

جانچ کیا وعدہ نہیں کرتی

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

معاون ترتیبات کے ساتھ برقرار رکھا گیا سافٹ ویئر ہی صارف کے پاس دستیاب عملی کنٹرول ہے۔ پیکٹ پروٹوکول سنبھالتا ہے؛ باقی سب آپریشنل فیصلہ رہتا ہے۔