بڑی اپ لوڈز کے دوران VPN کٹ جاتا ہے: پہلے قطار پڑھیں

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

ہر رن میں ایک متغیر بدلیں اور اینڈ پوائنٹ کو مستحکم رکھیں۔

دہرانے کے قابل بوجھ موازنہ بنائیں

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

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

آؤٹ پٹ وقت کے نشانات کے ساتھ محفوظ کریں تاکہ بوجھ والے اور بیکار رن کی لائن بہ لائن موازنہ ہو سکے۔

رفتار نہیں، قطار پڑھیں

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

ping -c 20 -i 0.2 203.0.113.10
mtr -rwc 20 203.0.113.10
tc -s qdisc show dev eth0
ss -ti dst 203.0.113.10
nstat -az | grep -E 'Retrans|Timeout'

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

ڈیوائس اور کنٹرول راستہ جانچیں

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

uptime
mpstat -P ALL 1 3
dmesg | grep -i -E 'thermal|throttl'
journalctl -u openvpn-server@server --since '10 min ago' | tail -20

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

ایک چیز بدلیں اور دہرائیں

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

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

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