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 સત્ર, પૂરતું લાંબું એક ટ્રાન્સફર, અને નિષ્ક્રિય સ્તરે પાછી આવતી ડિસ્ક્રિપ્ટર ગણતરી.