VPN রিলে SSH নেওয়া বন্ধ করে: ফাইল ডেসক্রিপ্টর সীমা

WireGuard হ্যান্ডশেক এখনও সম্পন্ন হয়, পিয়ার এখনও সাম্প্রতিক এন্ডপয়েন্ট দেখায়, তবুও তার পেছনের রিলে দিয়ে নতুন SSH সেশন কোনো ব্যানার ছাড়াই আটকে থাকে। এই সমন্বয় টানেল থেকে দূরে সকেট গ্রহণকারী প্রসেসের দিকে ইঙ্গিত করে। socat-এর মতো রিলে নিজের ডেসক্রিপ্টর বাজেট, নিজের চাইল্ড এবং নিজের উত্তরাধিকৃত সীমা নিয়ে অ্যাপ্লিকেশন পথে বসে থাকে। নিচের হাঁটা ক্লায়েন্ট থেকে শুরু হয়ে প্রথম উপাদানে থামে যা আরেকটি সকেট খুলতে পারে না।

সংখ্যা বদলানোর আগে পথটি অনুসরণ করুন

পুরো টানেল নিয়ে ভাবনার বদলে একটি ব্যর্থ অনুরোধ অনুসরণ করুন। ক্লায়েন্ট টানেলে লেখে, VPN ডেমন ডিক্রিপ্ট ও রাউট করে, আর রিলে অপর প্রান্তে গ্রহণ করে। প্রতিটি ধাপ ডেসক্রিপ্টর খরচ করে, আর যে ধাপটি সাধারণত ফুরায় সেটি শেষেরটি।

এমন একটি অনুরোধ দিয়ে শুরু করুন যা আপনি পুনরুৎপাদন করতে পারেন এবং তার সময় মাপুন। TCP হ্যান্ডশেক সম্পন্ন হয় কিন্তু অ্যাপ্লিকেশন ব্যানার না এলে, রিলে সকেটটি নিয়েছে এবং তারপর চাইল্ডে বা তার আপস্ট্রিম লেগে আটকে গেছে। হ্যান্ডশেক নিজেই যদি কখনও সম্পন্ন না হয়, কারণ রাউটিং, ফায়ারওয়াল বা লিসেনার অবস্থা, ডেসক্রিপ্টর সিলিং নয়। দুটি আকারের মধ্যে কোনটি দেখেছেন তা লিখে রাখুন, কারণ তারা ভিন্ন প্রসেসের দিকে ইঙ্গিত করে।

কাজের নকল করা হপগুলোও গণনা করুন। ফর্কিং লিসেনার প্রতিটি গৃহীত সকেট এমন চাইল্ডকে দেয় যা নিজের কপি রাখে, তাই প্রকৃত মোট পুরো গাছের বৈশিষ্ট্য, কেবল প্যারেন্টের নয়।

রিলে যে সীমা উত্তরাধিকারে পেয়েছে তা পড়ুন

একমাত্র সীমা যা গুরুত্বপূর্ণ তা চলমান প্রসেসের, এবং তা ঠিক করেছে যে জিনিসটি সেই প্রসেস চালু করেছে। শেলে ulimit -n টাইপ করলে শেলের কথা বোঝায়। সার্ভিস ম্যানেজারকে জিজ্ঞাসা করুন সে কী প্রয়োগ করেছে, তারপর PID-এ নিশ্চিত করুন।

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

limits ফাইলটি প্রসেস যেভাবে দেখে সেই নরম ও কঠিন সিলিং ছাপে। উদার কঠিন মানের নিচে কম নরম মান মানে ডেমন নিজের সিলিং বাড়াতে পারে, এবং কিছু কিছু স্টার্টআপে তা করে; সমান কম মান মানে ইউনিট ফাইলই উৎস।

Drop-in গুলো অভিধানক্রমে লোড হয় এবং পরের ফাইল জেতে, তাই systemctl cat vpn-relay.service কী প্রযোজ্য তার প্রামাণিক দৃশ্য। ম্যানেজার যে ফাইল কখনও পড়ে না তা সম্পাদনা করাই বাড়ানো সংখ্যার কোনো প্রভাব না থাকার সবচেয়ে সাধারণ কারণ।

স্থির সমবর্তিতা ধরে রাখা অবস্থা থেকে আলাদা করুন

দুটি প্রসেস অসংশ্লিষ্ট কারণে একই সিলিংয়ে পৌঁছাতে পারে, আর প্রতিকারগুলো আলাদা। উপযোগী সমবর্তী সেশন অনুসরণকারী চাহিদা সক্ষমতার প্রশ্ন। কাজ শেষের পরেও যে বৃদ্ধি চলতে থাকে তা লিক বা কেউ না-বন্ধ-করা সেশনের সমষ্টি।

নিষ্ক্রিয় অবস্থায়, স্বাভাবিক শিখরে এবং লোড থামার কয়েক মিনিট পর আবার মাপুন। ls /proc/PID/fd | wc -l দিয়ে খোলা এন্ট্রি নরম সীমার বিপরীতে গণনা করলে ব্যবধান বোঝা যায়, আর সিলিংয়ের এক-দুই নিচে থাকা গণনা ধীর পথ নয়, কঠিন থামা।

গণনা কমতে অস্বীকার করলে মোট নয়, সকেট অবস্থার দিকে তাকান। CLOSE_WAIT-এ বসে থাকা ডেসক্রিপ্টর মানে পিয়ার বন্ধ করেছে আর আপনার দিক কখনও করেনি, যা অ্যাপ্লিকেশন জীবনচক্রের ত্রুটি এবং বড় সীমা কেবল পিছিয়ে দেয়। চাইল্ড মডেলও সীমাবদ্ধ করুন: সমবর্তী চাইল্ডে কোনো ক্যাপ ছাড়া ফর্কিং রিলে ডেসক্রিপ্টর, প্রসেস স্লট ও মেমরি একসঙ্গে ফুরিয়ে দেয়।

লাইভ প্রসেসে নতুন মান যাচাই করুন

ইউনিট সম্পাদনার পর ম্যানেজার রিলোড করুন এবং সার্ভিস রিস্টার্ট করুন, কারণ কেবল রিলোড চলমান প্রসেসের ইতিমধ্যে উত্তরাধিকৃত সীমা কখনও বদলায় না। যে প্রসেস সত্যিই ট্রাফিক সার্ভ করছে তার উপর যাচাই করুন।

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 ডাউন হওয়ার আলাদা ঘটনা। পরিবর্তনটি এমনভাবে সাজান যাতে রিলে চক্রাকারে চলার সময় টানেল চালু থাকে, এবং যার দীর্ঘস্থায়ী সেশন এটি অতিক্রম করে তাকে সতর্ক করুন।

রোলব্যাক হলো আগের ইউনিট ফাইল আরেকটি রিস্টার্টসহ, এবং নতুন মান একটি কর্মদিবস টিকে থাকার আগে সেই ফাইল জায়গায় থাকে। তারপর মূলত ব্যর্থ অনুরোধ দিয়ে চক্রটি বন্ধ করুন: রিলে দিয়ে একটি নতুন SSH সেশন, যথেষ্ট দীর্ঘ একটি ট্রান্সফার, এবং নিষ্ক্রিয় স্তরে ফেরা ডেসক্রিপ্টর গণনা।