Կարո՞ղ է OpenVPN-ի կեռիկի սկրիպտը օգտագործել հենց նոր կառուցված թունելը
OpenVPN-ը կեռիկները գործարկում է իր իսկ մեկնարկի ընթացքում, ուստի թունելի կարիք ունեցող սկրիպտը սպասում է մի թունելի, որը սպասում է իրեն։ Առանձնացրեք աշխատանքը և կեռիկն ընտրեք ըստ իրադարձության։
Կեռիկի սկրիպտը կհասնի՞ թունելի մյուս կողմը, կախված է երեք պայմանից՝ որ իրադարձությանն է կցված, արդյոք OpenVPN-ը դեռ իր մեկնարկային հաջորդականության մեջ է, երբ սկրիպտը գործում է, և արդյոք աշխատանքը անջատվել է այդ հաջորդականությունից։ Սկրիպտների մեծ մասը ձախողվում է երրորդի վրա։ Քնի ավելացումը կյանքի ցիկլի խնդիրը վերաբերվում է որպես ժամանակի խնդրի, և այն աշխատում է հենց այնքան հաճախ, որ մոլորեցնի։
Նախ որոշեք իրադարձությունը, ապա աշխատանքի հետաձգման մեխանիզմը, ապա այն տեղը, որտեղ գործում է հետաձգված աշխատանքը։ Այս երեք որոշումները անկախ են, և դրանք խառնելն այն է, ինչից երկու տողանոց կեռիկը դառնում է մի ամբողջ կեսօր։
Ինչու է կեռիկը սպասում թունելի, որը սպասում է իրեն
OpenVPN իր կեռիկները կանչում է համաժամանակյա, նույն պրոցեսի ներսում, որը տեղաշարժում է փաթեթները։ up գործարկվում է, երբ tun կամ tap սարքը գոյություն ունի, բայց մինչև որևէ երթուղու ավելացումը, իսկ route-up գործարկվում է երթուղիներից հետո; այդ պահերից ոչ մեկը չի խոստանում, որ մյուս կողմը կպատասխանի։ Քանի դեռ կեռիկներից որևէ մեկի սկրիպտը գործում է, դեմոնը չի փոխանցում, ուստի այն հրամանը, որը սպասում է, որ երթևեկությունը անցնի թունելով, սպասում է մի թունելի, որը սպասում է հրամանին։ Այս շրջանաձև սպասումն է պատճառը, որ ձեռքով գործարկումը հաջողվում է, իսկ կեռիկը ժամկետանց է դառնում։
Ակնհայտ կարկատանը՝ մի քանի վայրկյան քունը, երբեմն աշխատում է, որովհետև հեռավոր ծայրը ինքնուրույն բարձրացավ, ոչ թե որովհետև քունը ինչ-որ բան ուղղեց։ Պատրաստականությունը հարցնող օգնականը այլ պատասխան է: կեռիկը վերադառնում է, փոխանցումը սկսվում է, և օգնականը ստանում է անհրաժեշտը, երբ այն իսկապես կա։
Ընտրեք կեռիկը ըստ իրադարձության, ոչ ըստ հարմարության
Կցեք up-ը աշխատանքին, որին միայն սարքն է պետք, route-up-ը՝ աշխատանքին, որին երթուղիներ են պետք, և պահեք client-connect-ը և client-disconnect-ը սերվերի կողմում յուրաքանչյուր հաճախորդի առաջադրանքների համար։ Անջատման ժամանակ մաքրումը պետք է դիմանա երկու անգամ գործարկմանը, քանի որ մշտական ինտերֆեյսով վերամիացումները չեն հետևում ամբողջական վերագործարկման նույն հաջորդականությանը։ Սերվերի վրա client-connect-ը գործարկվում է, երբ հաճախորդը նույնականացվում է, ոչ թե երբ դեմոնն է մեկնարկում, ինչն արժե հաստատել նախքան տրամաբանությունն այնտեղ տեղափոխելը։ Եթե աշխատանքը պատկանում է ծառայության կյանքի ցիկլին, այլ ոչ մեկ կապին, ապա systemd միավորը ավելի լավ տուն է, քան ցանկացած կեռիկ։
Կեռիկի հրամանները դեմոնն ուղղակիորեն է կատարում, առանց միջանկյալ խեցու, ուստի up տողում ifconfig_remote-ը գալիս է որպես բառացի տեքստ։ Փաթաթեք հրամանը բացահայտ խեցու մեջ, կամ տրամաբանությունը պահեք միջավայրը կարդացող սկրիպտում։ ipchange-ը մեկ հրահանգ է, որն ավելացնում է իր սեփական արգումենտները: այն հրամանին է տալիս հասցեն և պորտը, ուստի ոչ մեկի համար գրված սկրիպտը տեսնում է երկու անսպասելի։
Աշխատանքը անջատելու երեք եղանակ
Առաջին տարբերակը օգնականին կեռիկի ներսից ֆոն ուղարկելն է: գործարկեք այն setsid-ով կամ systemd-run --scope-ով, փակեք ժառանգված նկարագրիչները և անմիջապես դուրս եկեք զրոյով։ Երկրորդը՝ կեռիկը գրի փոքր վիճակի ֆայլ, և systemd-ի ժամաչափը կամ ուղու միավորը գործի դրա հիման վրա, ինչը կեռիկը պահում է չնչին և կրկնափորձի քաղաքականությունը դնում այնտեղ, որտեղ մատյաններ կան։ Երրորդը՝ ամբողջությամբ հրաժարվել կեռիկից և աշխատանքը տեղափոխել VPN ծառայությունից հետո դասավորված միավոր, ինչը ճիշտ պատասխանն է, երբ աշխատանքն ընդհանրապես կապակցված չէ։ Երեքն էլ կիսում են մեկ կանոն՝ կեռիկը պետք է վերադառնա նախքան թունելի կարիքը։
Ինչ էլ ընտրեք, օգնականը դարձրեք իդեմպոտենտ և դիտելի։ Երկու համընկնող կանչեր չպետք է նույն անշրջելի գործողությունը երկու անգամ կատարեն, և ձախողվող օգնականը պետք է թողնի մի բան, որ մարդը կարողանա կարդալ։
Առանձնացրեք ավազարկղի ձախողումները կյանքի ցիկլի ձախողումներից
Երբ սկրիպտը գործում է root հուշումից և ձախողվում որպես ծառայություն, պատճառը սովորաբար ավազարկղն է, ոչ թե ցանցը։ Սահմանափակող ProtectHome-ը, միայն կարդալու ProtectSystem-ը կամ գոյություն չունեցող աշխատանքային պանակը կարող են սկրիպտը կամ նրա տվյալները հասանելիությունից զրկել, և SELinux հոսթում ֆայլին նաև պետք է համատեքստ, որը թույլ է տալիս կատարում։ Կարդացեք միավորը systemctl cat openvpn-server@server-ով և մատյանը journalctl -u openvpn-server@server -n 80-ով, ապա փնտրեք թույլտվության կամ համատեքստի սխալ, ոչ թե կապի ժամկետանցում։ Ավազարկղն անջատելը պետք է լինի վերջին քայլը, ոչ առաջինը։
Կյանքի ցիկլի ձախողումն այլ տեսք ունի: կեռիկը մեկնարկում է, օգնականը գործում է, և սոքեթը պարզապես դեռ այնտեղ չէ։ Գրեք ժամանակադրոշմով տող հենց կեռիկից, անջատվեք և նորից միացեք, և իրադարձությունները կարդացեք հերթականությամբ։ Երբ օգնականին իսկապես թունել է պետք, թող նա հարցնի պատրաստականության մասին՝ ֆիքսված ժամանակ քնելու փոխարեն։
Երեք դաշտ են հաջորդ զեկույցը դարձնում օգտակար՝ որ կեռիկն է գործել, որ հաշիվն է օգտագործել և որտեղ է կանգ առել։ Առանց դրանց յուրաքանչյուր հետագա հետաքննություն սկսվում է զրոյից։