OpenVPN շարժիչ, թե Tunnelblick. ով է տնօրինում Mac-ի VPN նստաշրջանը

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

Անցեք ստորև նշված հինգ ստուգումները հերթականությամբ։ Առաջինը, որն ունի երկու սեփականատեր, այն է, որ ստեղծում է տարօրինակ կիսամիացված վիճակները, որոնք մարդիկ վերագրում են հենց OpenVPN-ին։ Յուրաքանչյուր ստուգում անվանում է այն ապացույցը, որը լուծում է այն։

Առաջին ստուգում՝ որ OpenVPN երկուական ֆայլն է իրականում աշխատում

Միացված վիճակում գործարկեք pgrep -fl openvpn և կարդացեք ամբողջ հրամանի տողը։ Առաջին ուղին այն շարժիչն է, որն իրականում աշխատում է։ Apple Silicon-ում Homebrew-ի տեղադրումը սովորաբար գտնվում է /opt/homebrew-ի տակ, մինչդեռ Intel Mac-երը օգտագործում են /usr/local, և Tunnelblick-ը շարժիչ է գործարկում իր իսկ հավելվածի փաթեթի ներսից։

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

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

Երկրորդ ստուգում՝ ով է փոխում DNS-ը և ուղիները

Շարժիչը կարող է գործարկել OpenVPN-ի սեփական up և down հրահանգները, սակայն կառավարիչը կարող է տիրապետել նույն կյանքի ցիկլին։ Tunnelblick-ի անվանասպասարկման կարգավորումները կառավարում են նրա ստանդարտ միացման և անջատման սկրիպտները, և երբ այդ ինտեգրումը միացված է, պրոֆիլի մրցակից հրահանգները կարող են անտեսվել։

Դա կարևոր է, որովհետև DNS-ն այն տեղն է, որտեղ աշխատող թունելը ամենից հաճախ կոտրված է թվում։ Միացված վիճակում ստուգեք scutil --dns-ը, նկատեք, թե որ լուծիչն է առաջինը, և հաստատեք, որ անջատումից հետո այն վերադառնում է։ Եթե պրոֆիլը սպասում է ինքը սահմանել DNS-ը, մինչդեռ կառավարիչը նույնպես կառավարում է այն, երկուսից մեկը կպարտվի։

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

Երրորդ ստուգում՝ որտեղից են գալիս հավատարմագրերը

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

Թվարկեք պրոֆիլի հավատարմագրերի աղբյուրը: հաճախորդի վկայագիր և բանալի, օգտանվի և գաղտնաբառի հարցում, կամ արտաքին օգնականի տրամադրած նշան։ Ապա հաստատեք, որ ընտրված սեփականատերը կարող է հասնել այդ աղբյուրին առանց մարդու, եթե միացումը պետք է դիմանա վերագործարկմանը։

Չորրորդ ստուգում՝ ով է սկսում, հսկում և կանգնեցնում գործընթացը

Ինքնուրույն տեղակայմանը հսկիչ է պետք, եթե այն պետք է մնա աշխատող։ Launchd-ը կարող է շարժիչը գործարկել մուտքի պահին կամ պահանջով, վերագործարկել անկումից հետո և մաքուր կանգնեցնել, բայց ինչ-որ մեկը պետք է գրի այդ աշխատանքը և տիրապետի դրան։ Տերմինալում հրամանը գործարկելը աշխատում է փորձարկման համար, ոչ այն օգտվողի համար, որը փակում է պատուհանը։

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

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

Հինգերորդ ստուգում՝ ինչպես է ստուգվում հանձնումը

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

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

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

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