FreeBind ընդդեմ After=՝ systemd-ի socket-ը VPN հասցեին կապելը

Բեռնման ժամանակ ֆիքսված VPN հասցե կապող socket-միավորը կարող է ձախողվել նախքան թունելը կհատկացնի այն, և դրա հետևում գտնվող ծառայությունը երբեք չի մեկնարկի։ Երկու անջատիչ նման են լուծման և լուծում են այդ խնդրի տարբեր կեսերը։ FreeBind-ը թույլ է տալիս systemd-ին ստեղծել լսողը, քանի դեռ հասցեն բացակայում է։ After= միայն կարգավորում է աշխատանքները, ուստի փոխում է, թե երբ են սկսվում բաները, բայց հասցեն ավելի շուտ չի բերում։

Երկու տարբեր խնդիր, երկու տարբեր անջատիչ

Առաջին խնդիրը կապման ձախողումն է․ միջուկը մերժում է լսել այն հասցեում, որը հոսթը չի տիրապետում, ուստի socket-միավորը անմիջապես ձախողվում է, և ծառայությունը երբեք չի ակտիվանում։ Երկրորդ խնդիրը պատրաստականության ձախողումն է․ հասցեն ի վերջո գոյություն ունի, բայց ինչ-որ բան փորձում է օգտագործել այն նախքան թունելը երթևեկություն կտեղափոխի։ FreeBind-ը լուծում է առաջինը և ոչինչ չի անում երկրորդի համար։ Հերթականության հրահանգները ուղղակիորեն չեն լուծում ոչ մեկը, որովհետև դրանք միայն որոշում են, թե ինչ ինչ հերթականությամբ է սկսվում։ Ձեր իրական ձախողումը անվանելը հենց ամբողջ որոշումն է։

Հաստատեք, թե որն ունեք, օրագրից, այլ ոչ ծառայության նկարագրությունից։ Կապման ձախողումը նշում է հասցե և հաղորդում, որ այն հնարավոր չէ հատկացնել։ Պատրաստականության ձախողումը սովորաբար ի հայտ է գալիս ավելի ուշ՝ որպես ժամկետի լրանալ կամ մյուս կողմից տեսած մերժված կապակցում, մինչդեռ մատյաններում լրիվ առողջ socket-միավոր է։

FreeBind՝ լսողը գոյություն ունի հասցեից առաջ

FreeBind-ը միջուկին ասում է թույլատրել կապը ոչ տեղական հասցեին, որպեսզի systemd-ը կարողանա լսող socket-ը ստեղծել բեռնման ժամանակ և հանձնել այն հավելվածին, երբ հավելվածը մեկնարկի։ Սա socket-ակտիվացման իմաստն է և պատճառը, թե ինչու socket-ը կարող է ապրել իր հետևի ծառայությունից ավելի երկար։

[Socket]
ListenStream=
ListenStream=10.8.0.1:8443
FreeBind=yes

Դատարկ վերագրումը մաքրում է մատակարարի միավորից ժառանգված լսման գրառումները նախքան նորի ավելացումը, ինչը խանգարում է մնացորդային wildcard-լսողին պատասխանել բոլոր ինտերֆեյսներում։ Փոխարինեք հասցեն և պորտը ձերով և ստուգեք արդյունավետ միավորը, ոչ միայն drop-in ֆայլը։ Փաթեթի ֆայլը տեղում խմբագրելու փոխարեն օգտագործեք drop-in միավորի անվան տակ, որովհետև հաջորդ փաթեթի թարմացումը կվերագրի խմբագրումը և ոչ մի հետք չի թողնի մտադրությունից։ Ապա կիրառեք այն վերաբեռնման և վերագործարկման ընթացակարգով, որը socket-միավորը սպասում է։

systemd socket-ի տեղեկատուն փաստաթղթավորում է այս ընտրանքի հետևի IPv4 և IPv6 վարքը, և կարևոր մանրամասն այն է, որ այն վերաբերում է կապմանը, ոչ երթուղմանը։ Դրանում ոչինչ հասցե չի հատկացնում և VPN չի մեկնարկում։ FreeBind-ը լսողին տրված թույլտվություն է, ոչ ինտերֆեյսի փոխարինում։

After= և Wants=՝ հերթականությունը պատրաստականություն չէ

Հերթականությունը և պահանջը առանձին առանցքներ են, և դրանց շփոթումը ստեղծում է միավորներ, որոնք սկսվում են ճիշտ հերթականությամբ և այնուամենայնիվ ձախողվում։ After=vpn-client.service նշանակում է միայն, որ եթե երկու աշխատանքներն էլ սկսվեն, այս մեկը սպասում է մյուսի մեկնարկին։ Այն չի քաշում VPN-ը և չի սպասում, որ VPN-ը ավարտի միացումը։

Պահանջի հրահանգները, ինչպիսիք են Wants= և Requires=, զբաղվում են ակտիվացմամբ և տարբերվում են նրանով, թե ինչ է լինում կախվածության ձախողման դեպքում՝ մեկը շարունակում է, մյուսը կանգ է առնում։ Նրանցից ոչ մեկը չգիտի, թե ինչ է նշանակում միացված թունել։ VPN գործընթացը կարող է ակտիվ լինել առանց հատկացված հասցեի, կամ հատկացված հասցեով և առանց դեպի զուգընկերը երթուղու, և երկու վիճակներն էլ բավարարում են կախվածությանը։ Եթե հավելվածին անհրաժեշտ է, որ հասցեն գոյություն ունենա, մոդելավորեք այդ պայմանը բացահայտորեն՝ գործընթացի մեկնարկը պատրաստականության ապացույց համարելու փոխարեն։

Ստուգեք, թե միավորն ինչ է իրականում հայտարարում systemctl cat և systemctl show -p After -p Wants -p Requires-ի միջոցով։ Երեք տարբեր պանակներից drop-in-ները կարող են ավելացնել հրահանգներ, որոնք դուք երբեք չեք գրել, և systemd-ը կարդում է միայն արդյունավետ միավորը։

Ինչ չի անում network-online.target-ը

network-online.target-ից հետո դասավորված միավորը սպասում է, որ ցանցի կառավարիչը ցանցը հայտարարի օգտագործելի, ինչը բեռնման համաժամեցման կետ է, ոչ շարունակական պայման։ Այն ոչինչ չի ասում, թե արդյոք կոնկրետ թունելը վերևում է, և այլևս չի գործարկվի, երբ VPN-ը կեսօրից հետո նորից միանա։ Այն որպես վերամիացման մոնիտոր դիտարկելը այդ նպատակի ամենատարածված սխալ ընթերցումն է։

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

Փորձարկեք այն կենսացիկլը, որն իրականում ընտրել եք

Փորձարկեք մաքուր բեռնում, հարցում հասցեի հայտնվելուց հետո, և վարքը այն բանից հետո, երբ VPN-ը ընկնում և վերադառնում է։ Այս երեք դեպքերը տարբերում են աշխատող լսողին աշխատող ծառայությունից։

systemd-analyze verify myapp.socket
systemctl cat myapp.socket
ss -ltn "sport = :8443"

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

Ընտրեք կենսացիկլը գիտակցաբար՝ կա՛մ ազատ կապված լսող, որը սպասում է կայուն հասցեի վերադարձին, կա՛մ ծառայություն, որը կանգ է առնում թունելի հետ և նորից սկսվում վերականգնման պահին։ Սրանք տարբեր նախագծեր են և տարբեր կերպ են ձախողվում։ Ապա մուտքի քաղաքականությունը կապված պահեք ձեր նախատեսած աղբյուրներին և ուղիներին, որովհետև նպատակակետ հասցե կապելը չի պահանջում, որ ընդունված փաթեթները եկած լինեն վստահելի ինտերֆեյսով։