Բացակայող VPN երթուղի NetworkManager-ում՝ պրոֆիլի քաղաքականությո՞ւն, թե՞ սկրիպտ

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

Որոշեք, թե որ սեփականատերն է պատասխանատու, նախքան որևէ բան գրելը։

Երեք սեփականատեր, մեկ բացակայող նախածանց

Նախածանցը կարող է բացակայել, որովհետև ոչ ոք չի տրամադրել այն, որովհետև պրոֆիլը մերժել է այն, կամ որովհետև այն տեղադրվել է մի տեղ, որտեղ դուք չեք նայում։ Սրանք տարբեր խափանումներ են և ունեն տարբեր ուղղումներ։

Առաջինը ստուգելն ամենահեշտն է․ արդյո՞ք սերվերը կամ հավելվածը երբևէ առաջարկել են երթուղին։ Backend-ը, որը երբեք չի ստացել նախածանցը, չի կարող տեղադրել այն, և օժանդակ սկրիպտը չի կարող հորինել հասանելիություն, որը գործընկերը երբեք չի նկարագրել։ Երկրորդը պրոֆիլի քաղաքականությունն է, որը կարող է ճնշել երթուղիներ, որոնք միացումը հակառակ դեպքում կվերցներ։ Երրորդը աղյուսակ կամ կանոն է, որը կարող է երթուղին պահել մի տեղ, որտեղ լռելյայն որոնումը երբեք չի նայում։

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

Կարդացեք պրոֆիլը, նախքան որևէ բան ավելացնելը

Սկսեք պահված միացման սեփական հատկություններից։ Կարդացեք դրանք առանց գաղտնիքներ թափելու, և օգտագործեք UUID-ն, եթե պրոֆիլի անունը երկիմաստ է։

nmcli -f vpn.service-type,ipv4.never-default,ipv4.ignore-auto-routes,ipv4.route-table,ipv4.routes connection show office

vpn.service-type ձեզ ասում է, թե որ backend-ն է տիրապետում միացմանը, և դա կարևոր է, որովհետև հավելվածի տվյալները backend-ին բնորոշ են։ Մի հավելվածի ընդունած բանալին աջակցվող հրահանգ չէ մյուսի համար, ուստի մեկ այլ հաճախորդի փաստաթղթերից պատճենված հատվածը ոչնչի ապացույց չէ։

ipv4.ignore-auto-routes և ipv4.never-default պատասխանում են տարբեր հարցերի։ Առաջինը կարող է մերժել երթուղիներ, որոնք միացումը հակառակ դեպքում ինքնաշխատ կվերցներ, իսկ երկրորդը կառավարում է, թե արդյոք պրոֆիլը կարող է դառնալ լռելյայն երթուղի։ Պրոֆիլը, որը անտեսում է ինքնաշխատ երթուղիները և ոչ մի այլ բանի չի հենվում, մաքուր կմիանա և գրեթե ոչինչ չի տեղադրի։

ip -4 rule show
ip -4 route show table all

Այս երկու հրամանները լուծում են երրորդ հնարավորությունը։ Փնտրեք ձեր նախածանցը բոլոր աղյուսակներում, ոչ միայն main-ում, և ստուգեք՝ արդյոք քաղաքականության կանոնը համապատասխան որոնումն ուղարկում է այլ տեղ։ Եթե նախածանցը մեկ այլ աղյուսակում է, և ոչինչ չի դիմում դրան, դուք բացակայող երթուղի չունեք․ դուք ունեք որոնում, որը երբեք չի հասնում դրան։

Ինչ սկրիպտը չի կարող ուղղել

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

OpenVPN-ի script-security-ը մյուս կրկնվող շփոթությունն է։ Սա OpenVPN-ի կարգավորում է, որը սահմանում է, թե որ սկրիպտները կարող է կատարել հաճախորդը և ինչ կարող է դնել դրանց միջավայրում․ 3-րդ մակարդակը թույլ է տալիս հավատարմագրերը փոխանցել միջավայրի միջով, ինչը գաղտնիքների հետ վարվելու որոշում է, ոչ թե երթուղավորման ուղղում։ Այն պրոֆիլի մեջ կպցնելը, որի backend-ը OpenVPN չէ, կամ այն բարձրացնելը, երբ ոչ մի սկրիպտի դա պետք չէ, ավելացնում է ենթարկվածություն՝ առանց երթուղի ավելացնելու։

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

Որոշումը՝ հերթականությամբ

Տվեք երեք հարց հերթով։ Արդյո՞ք գործընկերը տրամադրել է նախածանցը, ինչը ցույց կտա backend-ի մատյանը կամ նրա սեփական կարգավիճակի արտածումը։ Եթե այո, արդյո՞ք պրոֆիլը կարգավորված է ընդունելու և տեղադրելու երթուղիներ, թե՞ ճնշում է դրանք։ Եթե երթուղին ինչ-որ տեղ գոյություն ունի, արդյո՞ք որոնման ուղին ճիշտ է ձեր փորձարկվող երթևեկության համար։

Միայն երբ առաջին պատասխանը այո է, երկրորդը՝ այո, և երրորդը ճիշտ է, լրացուցիչ սկրիպտը դառնում է արդարացված, և նույնիսկ այդ ժամանակ պետք է հարցնել՝ արդյոք backend-ը բնիկորեն աջակցում է երթուղին։ VPN կարգավորումների տեղեկատուն փաստագրում է service-type-ը և հավելվածին բնորոշ տվյալների բառարանը, և հենց այնտեղից պետք է սկսել, նախքան ենթադրելը, որ բանալին գոյություն ունի։

Հաստատված ուղղումից հետո նորից միացեք և փորձարկեք նպատակակետը ըստ հասցեի, ապա ըստ անվան, հետո անջատվեք և նորից միացեք՝ հաստատելու, որ վիճակը կրկնելի է։ Մեկ սեփականատեր, մեկ աղյուսակ և թունելի հետ անհետացող երթուղի․ սա է արդյունքը, որն արժե ունենալ։