VPN ռելեը դադարում է ընդունել SSH։ ֆայլերի դեսկրիպտորների սահմանաչափեր

WireGuard ձեռքսեղմումը դեռ ավարտվում է, peer-ը դեռ ցույց է տալիս վերջերս եղած endpoint, և այնուամենայնիվ դրա հետևի ռելեով նոր SSH սեսիան կախվում է առանց banner-ի։ Այդ համակցությունը ցույց է տալիս թունելից հեռու՝ դեպի այն պրոցեսը, որը ընդունում է socket-ը։ socat-ի նման ռելեն նստում է հավելվածի ուղու վրա՝ իր դեսկրիպտորների բյուջեով, իր զավակներով և իր ժառանգված սահմաններով։ Ներքևի քայլքը սկսվում է հաճախորդից և կանգ է առնում առաջին բաղադրիչի մոտ, որը չի կարող բացել ևս մեկ socket։

Հետևեք ուղուն նախքան թիվը փոխելը

Հետևեք մեկ ձախողված հարցման՝ ամբողջ թունելի մասին դատելու փոխարեն։ Հաճախորդը գրում է թունելի մեջ, VPN-դեմոնը վերծանում և երթևեկում է, իսկ ռելեն ընդունում է մյուս կողմում։ Յուրաքանչյուր քայլ սպառում է դեսկրիպտորներ, և այն, որ սովորաբար սպառվում է, վերջինն է։

Սկսեք հարցումից, որը կարող եք վերարտադրել, և չափեք դրա ժամանակը։ Եթե TCP ձեռքսեղմումը ավարտվում է, բայց հավելվածի banner չի գալիս, ռելեն վերցրել է socket-ը և հետո կախվել է զավակի մեջ կամ իր վերին ոտքի վրա։ Եթե ձեռքսեղմումն ինքը երբեք չի ավարտվում, պատճառը երթուղումն է, firewall-ը կամ լսողի վիճակը, ոչ թե դեսկրիպտորների առաստաղը։ Գրանցեք, թե երկու ձևերից որն եք տեսել, որովհետև դրանք ցույց են տալիս տարբեր պրոցեսների։

Հաշվեք նաև աշխատանքը կրկնապատկող թռիչքները։ Ճյուղավորվող լսողը յուրաքանչյուր ընդունված socket հանձնում է զավակի, որը պահում է իր պատճենը, ուստի իրական գումարը ամբողջ ծառի հատկությունն է, ոչ միայն ծնողինը։

Կարդացեք այն սահմանը, որը ռելեն ժառանգել է

Միակ սահմանը, որ կարևոր է, պատկանում է աշխատող պրոցեսին, և այն սահմանել է այն, ինչը մեկնարկել է այդ պրոցեսը։ Shell-ում ulimit -n մուտքագրելը նկարագրում է shell-ը։ Հարցրեք ծառայությունների կառավարչին, թե ինչ է կիրառել, ապա հաստատեք PID-ի վրա։

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

limits ֆայլը տպում է փափուկ և կոշտ առաստաղները այնպես, ինչպես պրոցեսը տեսնում է դրանք։ Ցածր փափուկ արժեքը առատաձեռն կոշտ արժեքի տակ նշանակում է, որ դեմոնին թույլատրվում է բարձրացնել իր առաստաղը, և ոմանք դա անում են մեկնարկին; հավասար ցածր արժեքները նշանակում են, որ unit ֆայլն է աղբյուրը։

Drop-in-ները բեռնվում են բառարանային կարգով և ավելի ուշ ֆայլերը հաղթում են, ուստի systemctl cat vpn-relay.service-ը հեղինակավոր տեսքն է այն բանի, ինչ գործում է։ Այն ֆայլը խմբագրելը, որը կառավարիչը երբեք չի կարդում, ամենատարածված պատճառն է, թե ինչու բարձրացված թիվը ազդեցություն չի ունենում։

Առանձնացրեք կայուն զուգահեռականությունը պահպանված վիճակից

Երկու պրոցես կարող են հասնել նույն առաստաղին անկապ պատճառներով, և միջոցները տարբերվում են։ Օգտակար զուգահեռ սեսիաներին հետևող պահանջարկը հզորության հարց է։ Աշխատանքի ավարտից հետո շարունակվող աճը արտահոսք է կամ սեսիաների հավաքածու, որը ոչ ոք չի փակել։

Չափեք հանգիստ վիճակում, ձեր սովորական գագաթնակետին և կրկին ծանրաբեռնվածության դադարից մի քանի րոպե անց։ Բաց գրառումները ls /proc/PID/fd | wc -l-ով փափուկ սահմանի դեմ հաշվելը ձեզ ասում է բացվածքը, և առաստաղից մեկ-երկու ցածր թիվը կոշտ կանգ է, ոչ թե դանդաղ ուղի։

Երբ թիվը հրաժարվում է իջնել, նայեք socket-ների վիճակներին, ոչ թե ընդհանուր գումարներին։ CLOSE_WAIT-ում նստած դեսկրիպտորները նշանակում են, որ peer-ը փակել է, իսկ ձեր կողմը երբեք չի փակել, ինչը հավելվածի կյանքի ցիկլի թերություն է, որը ավելի մեծ սահմանը միայն հետաձգում է։ Սահմանափակեք նաև զավակների մոդելը՝ ճյուղավորվող ռելեն առանց զուգահեռ զավակների վերին սահմանի սպառում է դեսկրիպտորները, պրոցեսների տեղերը և հիշողությունը միասին։

Ստուգեք նոր արժեքը կենդանի պրոցեսի վրա

Unit-ը խմբագրելուց հետո վերաբեռնեք կառավարիչը և վերագործարկեք ծառայությունը, քանի որ միայն վերաբեռնումը երբեք չի փոխարինում արդեն աշխատող պրոցեսի ժառանգած սահմանները։ Ստուգեք այն պրոցեսի վրա, որն իրականում սպասարկում է երթևեկությունը։

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-ի անկումից։ Դասավորեք փոփոխությունն այնպես, որ թունելը մնա վերևում, մինչ ռելեն ցիկլ է անում, և զգուշացրեք բոլորին, ում երկարատև սեսիան հատում է այն։

Հետ գլորումը նախորդ unit ֆայլն է գումարած ևս մեկ վերագործարկում, և այդ ֆայլը մնում է տեղում, մինչև նոր արժեքը գոյատևի աշխատանքային օր։ Այնուհետև փակեք օղակը սկզբում ձախողված հարցումով՝ մեկ նոր SSH սեսիա ռելեով, մեկ փոխանցում, որը բավական երկար է, որ նշանակություն ունենա, և դեսկրիպտորների թիվ, որը վերադառնում է իր հանգիստ մակարդակին։