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

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

بیکاری کے رکنے کی صورت کیسی ہوتی ہے

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

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

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

بھولنے والا ڈیوائس تلاش کریں

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

یہ مت سمجھیں کہ دستاویزی ڈیفالٹ ہی آپ کے راستے کی وقت کی حد ہے۔ یہ ایک ڈیوائس کا ڈیفالٹ ہے۔

  • گھریلو راؤٹر: اکثر منٹ، کبھی کبھی اس سے بہت کم۔
  • کلاؤڈ NAT یا لوڈ بیلنسر: خاص طور پر UDP کے لیے دستاویزی بیکاری کی وقت کی حد دیکھیں۔
  • ہوسٹ فائر وال: netfilter ٹریکنگ ٹائمر ہر فلو پر لاگو ہوتے ہیں۔

اصل راستے پر ٹائمر جانچیں

Linux پر netfilter ٹریکنگ ٹائمر نظر آتے ہیں اور بدلے جا سکتے ہیں: sysctl net.netfilter.nf_conntrack_udp_timeout اور net.netfilter.nf_conntrack_udp_timeout_stream۔ دوسرا تب لاگو ہوتا ہے جب ٹریفک دونوں سمتوں میں دیکھا جا چکا ہو، اسی لیے قائم شدہ ٹنل سادہ جانچ سے زیادہ عرصہ زندہ رہ سکتا ہے۔

RFC 4787 UDP NAT کا رویہ اور تجویز کردہ کم سے کم حد بیان کرتا ہے۔ یہی وہ حوالہ ہے جس کا ذکر کریں جب کسی وینڈر کا ڈیفالٹ غیر معمولی طور پر کم لگے۔

Keepalive اور دوبارہ جڑنا مختلف اوزار ہیں

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

بہت زیادہ بار بار کیے گئے ٹیسٹ کام بڑھاتے ہیں مگر غلط حد درست نہیں کرتے۔

صفحہ ری لوڈ سے نہیں، نئی درخواست سے تصدیق کریں

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

اگر رکنا جاری رہے تو ایک ہاپ باہر جائیں اور اس ڈیوائس کا اسٹیٹ ٹیبل جانچیں۔

متعلقہ مضامین