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 सत्र, महत्वपूर्ण होने के लिए काफी लंबा एक स्थानांतरण, और निष्क्रिय स्तर पर लौटती डिस्क्रिप्टर गिनती।