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 സെഷൻ, അർത്ഥവത്താകാൻ മതിയായ നീളമുള്ള ഒരു കൈമാറ്റം, നിഷ്ക്രിയ നിലയിലേക്ക് മടങ്ങുന്ന ഡിസ്ക്രിപ്റ്റർ എണ്ണം.