Ձեր VPN-ն աշխատում է միայն մուտքից հետո՝ բանալիների շղթայի պատճառով

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

Ինչու է մուտքը ստիպում աշխատել

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

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

Որոշեք, թե որ սեփականատերն է սկսում թունելը

Գոյություն ունեն երկու աջակցվող օրինաչափություն, և դրանք խառնելը այս ձախողման մյուս ճանապարհն է։ NetworkManager-ը կարող է ակտիվացնել համակարգային մակարդակի կապ, ինչը տեղին է, երբ մեքենան արդեն այնտեղ կենտրոնացրել է իր ցանցը։ Որպես այլընտրանք, առանձին systemd միավորը գործարկում է VPN-ն ուղղակիորեն և ինքն է տիրում ինտերֆեյսին։

systemctl list-unit-files 'openvpn*'
systemctl list-unit-files 'wg-quick*'
nmcli connection show --active
systemctl enable --now wg-quick@wg0

Մի գործարկեք երկու սեփականատերերին մեկ կազմաձևի դեմ։ Եթե NetworkManager-ը կառավարում է ինտերֆեյսը, և միավորը նույնպես բարձրացնում է այն, նրանք կվիճեն երթուղիների և DNS-ի համար, և ստացված վիճակը կախված է նրանից, թե ով վերջացրեց վերջինը։

Դրեք գաղտնիքը այնտեղ, որտեղ ծառայությունը կարող է կարդալ

Ֆոնային ծառայությունը չի կարող պատասխանել հարցմանը։ Վկայագրի գաղտնաբառերը, հաշվի գաղտնաբառերը և հղված նույնականացման ֆայլերը բոլորն էլ պահանջում են այնպիսի պահպանման կարգավորում, որին միավորը կարող է հասնել առանց մարդու, որը պատկանում է ծառայությունը գործարկող հաշվին և անընթեռնելի է մնացած բոլորի համար։

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

Փորձարկեք իրադարձությունը, որն իրականում տեղի է ունենում

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

systemctl is-enabled wg-quick@wg0
journalctl -u wg-quick@wg0 -b --no-pager
systemctl status systemd-networkd-wait-online --no-pager

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

Ստուգեք երթուղիներն ու DNS-ը, ոչ միայն ինտերֆեյսը

Գոյություն ունեցող ինտերֆեյսը աշխատող թունել չէ։ Չհսկվող գործարկումից հետո ստուգեք երթուղիները, լուծիչի վիճակը և մեկ նպատակակետ հասցեով՝ նախքան անունը ստուգելը։ Այնուհետև ստուգեք այն հավելվածը, որի համար գոյություն ունի թունելը։

ip -4 route show
resolvectl status
ping -c 3 10.61.0.1
curl -sS --max-time 5 https://internal.example/ -o /dev/null -w '%{http_code}\n'

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