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 सत्र, अर्थपूर्ण हुन पर्याप्त लामो एउटा स्थानान्तरण, र निष्क्रिय तहमा फर्कने डिस्क्रिप्टर गणना।