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

Զրոյով դուրս եկող սկրիպտը ձեզ ոչինչ չի ասել այն մասին, թե արդյոք թունելը վերադարձել է։

Կեռիկը գործարկվում է, իսկ հետո՞

#!/bin/sh
case "$1" in
  pre)
    vpn-client disconnect
    ;;
  post)
    vpn-client connect
    ;;
esac

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

Փուլի արգումենտը դիտարկեք որպես ձևավորման մաս։ pre փուլում վերակապակցման փորձը տեղի է ունենում, երբ մեքենան պատրաստվում է կորցնել ամեն ինչ, և այն չի կարող հաջողվել։

Root, նվազագույն միջավայր, սխալ օգտվող

Եթե հաճախորդը մուտքի նշանը պահում է յուրաքանչյուր օգտվողի համար, ապա կեռիկը root-ով գործարկելը նրան թողնում է առանց ներկայացնելու ոչինչ։ Ստուգեք վիճակը այն ինքնության ներքո, որն իրականում օգտագործում է կեռիկը, ոչ այն, որը փորձարկել եք աշխատասեղանի տերմինալից։ Որոշ կառուցվածքներ անջատումից հետո թողնում են նաև դեյմոն, որը պահում է միջերեսը, ուստի վերակապակցումը ընկնում է հնացած վիճակի մեջ, և գործընթացը նախ մաքրելը վերականգնում է այն ոչ մաքուր անջատման գնով։ Երկու վարքագծերից ոչ մեկը չի երևում, եթե փորձարկում եք միայն երջանիկ ուղին։

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

Ավտոմատ միացումը VPN-ի ուղին չէ

NetworkManager-ը առաջարկում է ակտիվացման երկու մեխանիզմ՝ ավտոմատ միացման դրոշ պրոֆիլի վրա, և երկրորդական միացումներ, որոնք սկսվում են, երբ ակտիվանում է հիմնական պրոֆիլը։ Սեփական սարքի տեսակները իրականացնում են առաջինը, VPN-ի հավելումները պատմականորեն իրականացրել են միայն երկրորդը, ուստի OpenVPN պրոֆիլի վրա ավտոմատ միացումը նշելը կարող է ընդհանրապես ազդեցություն չունենալ։ Ստուգեք երկու հատկությունները, ապա VPN-ը կցեք Wi-Fi կամ Ethernet պրոֆիլի երկրորդականի տեսքով։

[Unit]
PartOf=NetworkManager.service
Requires=NetworkManager-wait-online.service
After=NetworkManager-wait-online.service

systemd միավորով կառավարվող WireGuard միջերեսին անհրաժեշտ է այդ լրացուցիչ ֆայլը՝ կեռիկի փոխարեն, դասավորված այն բանից հետո, երբ ցանցը միացված է։

Սպասեք ցանցին, սահմանաչափով

timer=1
while ! ping -c1 -n -w1 203.0.113.1 >/dev/null; do
  sleep 1; timer=$((timer+1))
  [ $timer -ge 300 ] && exit 0
done
nmcli connection up "work-vpn"

Վերսկսելիս թունելը կարող են պահանջել, երբ Wi-Fi-ը դեռ նորից միանում է, ինչը ցանկացած ֆիքսված քուն դարձնում է գուշակություն։ Սպասեք հասանելի հասցեի, ապա բարձրացրեք պրոֆիլը, և սահմանափակեք սպասումը, որպեսզի կեռիկը չկարողանա վերսկսման ուղին անվերջ բաց պահել։ Նախընտրեք պրոֆիլի անունը թվային ինդեքսից, և եթե ճիշտ պրոֆիլը տարբերվում է ըստ ցանցի, թող առողջ թունելը նախապես գրի իր ընտրությունը ֆայլում։

Պաշտպանվեք նաև վերագործարկման փոթորիկներից՝ հաշվելով փորձերը և կանգ առնելով։ Յուրաքանչյուր ձախողված ստուգման արձագանքող հսկիչը մեկ խափանումը դարձնում է հանգույց։

Մեկ անգամ դադարեցրեք համակարգը, ապա կարդացեք մատյանում կեռիկի սեփական ելքը։ Դա միակ փորձն է, որն ապացուցում է հերթականությունը։

Առնչվող հոդվածներ