کیا کم VPN تھروپٹ اینٹروپی کا مسئلہ ہے؟ عام طور پر نہیں

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

ایک جیسے نظر آنے والی دو علامات

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

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

systemd-analyze blame | head -10
journalctl -u [email protected] -o short-precise | head -40
cat /proc/sys/kernel/random/entropy_avail

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

بے ترتیب اعداد کا انتظار درحقیقت کیسا لگتا ہے

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

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

strace -f -e trace=getrandom -p $(pidof openvpn) 2>&1 | head -20
dmesg | grep -i 'random\|crng'

پہلا حکم دکھاتا ہے کہ آپ کے دیکھتے وقت عمل بے ترتیب عدد کی کال میں بیٹھا ہے یا نہیں۔ دوسرا خود کرنل کے ابتدائی پیغامات دکھاتا ہے، اور وہیں ابتدائی بوٹ کی رکاوٹ نظر آتی ہے۔

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

مسلسل سستی درحقیقت کیسی لگتی ہے

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

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

ss -tin dst 203.0.113.10
nstat -az | grep -i 'drop\|retrans'
ethtool -S eth0 | grep -i 'drop\|error'

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

آپ نے جو رکاوٹ ناپی اس کے لیے اصلاح منتخب کریں

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

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

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