Ինչու է OpenVPN-ը մահանում նոթբուքի արթնանալուց հետո։

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

ip -br address show tun0
ip route get 10.20.0.10
journalctl -u openvpn-client@office -b --no-pager | tail -30

Վերարտադրեք արթնացումը՝ նախքան այն ավտոմատացնելը

Քունն ավելի հաճախ է ավարտում գաղտնագրված սեանսը, քան հեռացնում է սարքը։ UDP հոսքը, որը կենդանի էր պահում թունելը, կանգ է առնում, սերվերը կարող է գցել զույգին, և հաճախորդը կա՛մ նկատում է դա ու նորից միանում, կա՛մ պահում է ինտերֆեյս, որի հետևում ոչինչ չկա։ Միայն ինտերֆեյսի ստուգումը քիչ բան է ապացուցում, որովհետև հին սարքը ճիշտ նույն տեսքն ունի, ինչ աշխատողը մինչև փաթեթները ստիպված չլինեն անցնել դրա միջով։ Գործարկեք երթուղու որոնումը և մեկ իրական հարցում թունելով, ապա կարդացեք մատյանը արթնացման պահի շուրջ։

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

Որտեղ է իրականում ապրում systemd-ի քնի կեռը

Շատ հին ուղեցույցներ մատնանշում են /etc/pm/sleep.d-ը՝ գրացուցակ, որը պատկանում է pm-utils-ին և որին systemd-ի վրա հիմնված քունը երբեք չի դիմում։ systemd-ը կեռերը կարդում է /usr/lib/systemd/system-sleep/-ից և /etc/systemd/system-sleep/-ից՝ նախ փոխանցելով փուլը, ապա գործողությունը, ուստի pre-ը և post-ը միակ արժեքներն են, որոնց վրա կեռը ճյուղավորվում է։ Պահեք տեղական պատճենը /etc-ի տակ՝ փաթեթավորված ֆայլը խմբագրելու փոխարեն, և հիշեք, որ սկրիպտը աշխատում է որպես root անցման մեջտեղում, ուստի այն պետք է արագ վերադառնա։

#!/bin/sh
case "$1" in
  post)
    systemctl --no-block try-restart [email protected]
    ;;
esac
exit 0

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

Վերականգնեք ծառայությունը, թողեք tun0-ը հանգիստ

tun0-ը ձեռքով իջեցնելը դեմոնին թողնում է հսկելու ինտերֆեյս, որը նա այլևս չի տիրապետում, և հաջորդ վիճակի փոփոխությունը շփոթեցնող սխալներ է առաջացնում։ Թիրախավորեք ծառայությունը կամ նրա կապի պրոֆիլը, ոչ թե ինտերֆեյսը՝ նախ ստուգեք միավորի ճշգրիտ անունը, որովհետև տարածումների փաթեթները, OpenVPN 3-ը և NetworkManager-ը բոլորն ընտրում են տարբեր։ NetworkManager-ի պրոֆիլը վերադառնում է, երբ այդ կապը վերաշրջանառվում է, ուստի systemd-ի միավորն այնտեղ թիրախ չէ։ Ինչ մեխանիզմ էլ լինի, դա պետք է լինի այն նույն գործողությունը, որը դուք ձեռքով ստուգել եք։

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

Զբաղվեք այն ժամանակացույցով, որը չեք կարող կառավարել

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

Անունների լուծումն առանձին մրցավազք է, որովհետև աշխատասեղանի ցանցային կույտը կարող է վերականգնել DNS-ը այն բանից հետո, երբ թունելն արդեն վեր է։ Փնտրումները ստուգեք առանձին՝ resolvectl query internal.example-ով, փոխարենը եզրակացնելով դրանք աշխատող երթուղուց։ Այն թունելը, որը ճիշտ երթուղավորում է և ոչինչ չի լուծում, DNS խնդիր է, ոչ թե կեռի խնդիր։

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