VPN ریلے نے SSH قبول کرنا بند کر دیا: فائل ڈسکرپٹر کی حدیں

WireGuard ہینڈ شیک اب بھی مکمل ہوتا ہے، peer اب بھی حالیہ endpoint دکھاتا ہے، اور پھر بھی اس کے پیچھے والے ریلے سے گزرنے والا نیا SSH سیشن بغیر کسی بینر کے لٹکتا ہے۔ یہ امتزاج ٹنل سے دور، socket قبول کرنے والے عمل کی طرف اشارہ کرتا ہے۔ socat جیسا ریلے اپنے ڈسکرپٹر بجٹ، اپنے بچوں اور اپنی وراثتی حدوں کے ساتھ ایپلیکیشن کے راستے میں بیٹھتا ہے۔ نیچے کا سفر کلائنٹ سے شروع ہوتا ہے اور پہلے ایسے جزو پر رکتا ہے جو ایک اور socket نہیں کھول سکتا۔

نمبر بدلنے سے پہلے راستہ تلاش کریں

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

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

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

وہ حد پڑھیں جو ریلے نے وراثت میں لی

صرف ایک اہم حد چل رہے عمل کی ہے، اور اسے اسی چیز نے مقرر کیا جس نے وہ عمل شروع کیا۔ شیل میں ulimit -n لکھنا شیل کی وضاحت کرتا ہے۔ سروس مینیجر سے پوچھیں کہ اس نے کیا لاگو کیا، پھر PID پر تصدیق کریں۔

systemctl show -p MainPID -p LimitNOFILE vpn-relay.service
cat /proc/$(systemctl show -p MainPID --value vpn-relay.service)/limits

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

Drop-in لغوی ترتیب میں لوڈ ہوتے ہیں اور بعد کی فائلیں جیتتی ہیں، اس لیے systemctl cat vpn-relay.service اس بات کا مستند منظر ہے کہ کیا لاگو ہے۔ ایسی فائل میں ترمیم کرنا جو مینیجر کبھی نہیں پڑھتا، بڑھائے گئے نمبر کے بے اثر ہونے کی سب سے عام وجہ ہے۔

مستقل ہم وقتی کو محفوظ حالت سے الگ کریں

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

خاموش حالت میں، اپنی معمول کی چوٹی پر اور بوجھ رکنے کے چند منٹ بعد دوبارہ ناپیں۔ ls /proc/PID/fd | wc -l سے کھلی اندراجات کو نرم حد کے مقابل گننا فرق بتاتا ہے، اور چھت سے ایک یا دو کم گنتی سست راستہ نہیں بلکہ سخت رکاوٹ ہے۔

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

زندہ عمل پر نئی قدر جانچیں

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

systemctl daemon-reload
systemctl restart vpn-relay.service
awk '/Max open files/ {print}' /proc/$(systemctl show -p MainPID --value vpn-relay.service)/limits
ss -tnp state established '( sport = :2222 )' | wc -l

awk سطر نئی جوڑی واپس کرتی ہے؛ اگر وہ اب بھی پرانی دکھائے، تو آپ کی ترمیم کردہ drop-in وہ نہیں جو لوڈ ہو رہی ہے۔ ss گنتی آپ کا ورک لوڈ چیک ہے، اس لیے متوقع سیشن تعداد کھولیں اور اسے بڑھتے دیکھیں۔ ان سیشنوں کے بند ہونے کے بعد بھی بڑھتی گنتی کا مطلب ہے کہ حد کبھی پورا مسئلہ نہیں تھی۔

ہر بڑے اضافے کے ساتھ ایک انتباہ آتا ہے۔ select() سے پول کرنے والی ایپلیکیشنز FD_SETSIZE سے اوپر ڈسکرپٹر نہیں دیکھ سکتیں، جو عام بلڈز میں 1024 ہے، اس لیے اس سے اوپر اٹھائی گئی چھت غیر متعلق نظر آنے والی ناکامیاں پیدا کر سکتی ہے۔ systemd ایگزیکیوشن حوالہ بھی ان سروسز کے لیے وہی انتباہ رکھتا ہے جنہیں وہ شروع کرتا ہے۔

دوبارہ آغاز کو ٹنل کی دستیابی سے دور رکھیں

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

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