Ինչու է ձեր OpenVPN հաճախորդը մնում անջատված մեկ ժամանակային սահմանից հետո

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

Սկսեք նրանից, թե միավորը իրականում ինչ է արել, ոչ թե նրանից, ինչ պնդում է մոնիտորինգը։ systemctl status openvpn-client@office և journalctl -u openvpn-client@office -n 50 ցույց են տալիս դուրս գալու պատճառը և վերջին տողը, որը հաճախորդը գրել է մեկնելուց առաջ։

Պրոցեսը դուրս եկավ նախքան ինչ-որ մեկը նկատեց

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

Երկու ping հրահանգները չեն կարող միասին լինել մեկ պրոֆիլում, այնպես որ ընտրեք մեկը և գրանցեք ընտրությունը։ Նայեք նաև սերվերին, քանի որ նրա սեփական ping-exit փակում է սեսիան անկախ հաճախորդի պահանջից, և միայն սերվերի մատյանն է գրանցում, թե ով է կայացրել այդ որոշումը։

Ընտրություն ping-exit-ի և ping-restart-ի միջև

Ընտրեք ping-restart նոութբուքի կամ հեռավոր վայրի համար, որը պետք է ինքնաբուժվի, և պահեք ping-exit այն դեպքերի համար, երբ մեռած թունելը պետք է կանգնեցնի պրոցեսը, որպեսզի ուրիշ բան կարողանա արձագանքել դրան։ Թվերը պակաս կարևոր են, քան հարաբերությունը՝ ping 10-ը ping-restart 60-ի հետ նշանակում է տաս վայրկյան լռություն ստուգումից առաջ և վաթսուն՝ վերսկսումից առաջ, ինչը ագրեսիվ է կորուստներով բջջային կապի համար և ողջամիտ՝ լարայինի։ Գրեք պատճառը տողի կողքին, հակառակ դեպքում հաջորդ ընթերցողը կենթադրի, որ լռելյայն արժեքները դիտավորյալ են եղել։

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

Հսկողություն, որն իսկապես վերսկսում է միավորը

systemd հոսթի վրա ամենափոքր կայուն փոփոխությունը մեկ drop-in ֆայլն է՝ Restart=on-failure և RestartSec=10՝ /etc/systemd/system/[email protected]/restart.conf-ում։ drop-in-ը կարդացվում է միայն այն ժամանակ, երբ systemd-ն վերաբեռնում է իր սեփական սահմանումները, այնպես որ դրանից հետո գործարկեք systemctl daemon-reload։ Ստուգեք systemctl show -p Restart -p ExecMainStatus openvpn-client@office-ով՝ արժեքի հասնելը ենթադրելու փոխարեն։ Ֆայլի անվան մեջ եղած օրինակը պետք է լինի այն պրոֆիլը, որը միավորը իրականում բեռնում է, ուստի office-ի համար գրված ֆայլը ոչինչ չի անում openvpn-client@home-ի համար։

on-failure-ը անտեսում է մեկ դեպք՝ զրո կարգավիճակով մաքուր դուրս գալը։ Որոշ ապամոնտաժման ուղիներ այդպես են ավարտվում, ուստի կարդացեք գրանցված կարգավիճակը՝ ձեռնարկի էջի ձևակերպմանը վստահելու փոխարեն։ Եթե ձեր հաճախորդը զրոյով հանձնվում է, ձեզ անհրաժեշտ է Restart=always, և գինը այն է, որ իսկապես կոտրված պրոֆիլը նորից ու նորից վերադառնում է, մինչև մեկնարկի արագության սահմանը գործի և մատյանը լցվի։

Restart=always-ը գործում է նաև դիտավորյալ կանգնեցնելուց հետո։ Սպասարկման համար օգտագործեք systemctl stop-ը, և քողարկեք միավորը, եթե այն պետք է մնա անջատված, մինչ դուք աշխատում եք։

Բռնեք արտահոսքը, մինչ թունելն անջատված է

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

Երբ հոսթին ընդհանրապես չի թույլատրվում արտանետել չպաշտպանված փաթեթներ, դա կարող է երաշխավորել միայն firewall-ը։ Ելքային կանոնը, որը թույլ է տալիս թունելի ինտերֆեյսը և VPN սերվերի հասցեն՝ դեն նետելով մնացած ամեն ինչ, գործում է նաև հաճախորդի մահից հետո, և հաճախորդի սեփական կոնֆիգուրացիայում ոչինչ չի կարող զտել այն երթևեկությունը, որը հաճախորդը չի տեղափոխում։

Փորձարկեք այն՝ դիտավորյալ կանգնեցնելով հաճախորդին։ Գործարկեք systemctl stop openvpn-client@office-ը, ապա curl -m 5 https://example.com-ը, որը պետք է ձախողվի, այլ ոչ թե հաջողվի ֆիզիկական կապով։ Հաջողությունը նշանակում է, որ firewall-ի կանոնը բացակայում է կամ չափազանց թույլատրող է։

Նորից միացեք, հաստատեք, որ թունելը կրկին երթևեկություն է տեղափոխում, և միայն դրանից հետո ավելացրեք ստուգումը մոնիտորինգին։ ip addr-ի հարցումը cron-ից tun սարքի համար ամենահաճախ ձախողվող հսկողությունն է, քանի որ persist-tun-ի դեպքում սարքը գոյատևում է սեսիայից ավելի, և ստուգիչը առողջություն է հաղորդում, մինչ ոչինչ չի տեղափոխվում։