TCP ری سیٹ یہ ثابت نہیں کرتا کہ آپ کا VPN بلاک ہو رہا ہے

کلائنٹ لاگ میں «کنکشن ری سیٹ، دوبارہ شروع ہو رہا ہے» نظر آتا ہے، اور نتیجہ ثبوت سے پہلے آ جاتا ہے۔ کوئی فیصلہ کر لیتا ہے کہ نیٹ ورک VPN بلاک کر رہا ہے، یا سرٹیفکیٹ غلط ہے، یا کوئی مخصوص ملک مداخلت کر رہا ہے۔ ری سیٹ ایک TCP پیکٹ ہے جو کنکشن ختم کرتا ہے، اور لاگ لائن ریکارڈ کرتی ہے کہ آپ کے کلائنٹ کو ایک ملا۔ یہ بھیجنے والے آلے یا وجہ کا نام نہیں لیتا۔

ری سیٹ ایک پیکٹ ہے، فیصلہ نہیں

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

کلائنٹ کو بس اتنا ہی معلوم ہے۔ RST سرور، پراکسی، فائر وال یا حالت کھو دینے والے لوڈ بیلنسر سے آ سکتا ہے۔

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

تصدیق کریں کہ کون سا کنکشن ری سیٹ ہوا

پہلے دیکھیں کہ فعال پروفائل واقعی TCP استعمال کرتا ہے یا نہیں۔ UDP ٹنل پر ری سیٹ بے معنی ہے، اور HTTP پراکسی کا لاگ VPN سے مختلف TCP حصے سے متعلق ہو سکتا ہے۔

منزل، پورٹ، کوشش کا وقت اور وہ مرحلہ ریکارڈ کریں جہاں تک کلائنٹ پہنچا تھا۔

مرحلہ سب سے مفید فیلڈ ہے۔ TLS ہینڈ شیک کے دوران ری سیٹ ایک گروہ مشتبہ افراد کی طرف اشارہ کرتا ہے؛ تصدیق کے بعد ری سیٹ دوسرے کی طرف۔ مرحلے کے بغیر ہر نظریہ فٹ بیٹھتا ہے۔

راستے کے دونوں سرے موازنہ کریں

اگر آپ سرور کا انتظام کرتے ہیں تو اسی کوشش کے لیے اس کے واقعات موازنہ کریں۔ کیا اس نے کنکشن قبول کیا؟ کیا اس نے جان بوجھ کر بند کیا؟ کیا کوئی جواب ایک حد چھوڑ کر اگلی تک کبھی نہیں پہنچا؟

اگر ممکن ہو تو کلائنٹ اور سرور دونوں پر کیپچر کریں۔ جو ری سیٹ کلائنٹ پر نظر آتا ہے مگر سرور پر نہیں، وہ سرور پر پیدا نہیں ہوا۔

دونوں سمتوں میں RST حصوں پر دھیان دیں:

sudo tcpdump -ni any 'tcp[tcpflags] & tcp-rst != 0' -c 20
ss -tnp | grep 198.51.100.20

کنٹرول شدہ موازنے سے محدود کریں

دوسرا منظور شدہ نیٹ ورک بتا سکتا ہے کہ ناکامی کلائنٹ کا پیچھا کرتی ہے یا راستے کا۔ اگر وہی پروفائل کہیں اور کام کرتا ہے تو کلائنٹ کنفیگریشن غالباً ٹھیک ہے اور متغیر راستہ ہے۔

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

«یہ راستہ ناکام ہوتا ہے» اور «اس نامزد فریق نے یہ کیا» کے درمیان فرق برقرار رکھیں۔ پہلا قابلِ آزمائش ہے؛ دوسرا عام طور پر ایک کلائنٹ سے نہیں۔

اعتماد کی ترتیبات بدلے بغیر اصلاح کی جانچ کریں

TLS تصدیق بند نہ کریں، اسناد دوبارہ نہ بنائیں اور ایک ری سیٹ لائن کی بنیاد پر بلاکنگ پالیسی کا اعلان نہ کریں۔ ان میں سے ہر تبدیلی زیرِ آزمائش نظام کو بدلتی ہے اور اگلا موازنہ بے معنی کر دیتی ہے۔

شناخت شدہ جزو کو اس کے مالک کے ذریعے ٹھیک کریں، پھر وہی پروفائل اور وہی مشاہدہ دہرائیں:

openvpn --config client.ovpn --verb 4
sudo tcpdump -ni any 'host 198.51.100.20 and tcp' -c 40

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