Հաճախորդի կեռ թե՞ սերվերի կեռ. որտեղ է աշխատում OpenVPN-ի սկրիպտը

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

Երկու մեքենա, երկու հարց, որոնց պետք է նախ պատասխանել

Հարցրեք, որտեղ պետք է տեղի ունենա վիճակի փոփոխությունը, ապա հարցրեք, թե որ իրադարձությունն է համապատասխանում դրան։ Եթե փոփոխությունը մեկ օգտագործողի լիազորում է կամ մեկ հաճախորդի կոնֆիգուրացիայի որոշում, այն պատկանում է այնտեղ, որտեղ հայտնի է օգտագործողների գրացուցակը՝ սերվերին։ Եթե փոփոխությունը երթուղի է, resolver-ի կարգավորում կամ վերջնակետի տեղական օգնական, այն պատկանում է վերջնակետին, և միայն վերջնակետը կարող է դա անել։

Այս երկու հարցերին հակառակ հերթականությամբ պատասխանելն է այն ճանապարհը, որով մարդիկ հասնում են Windows-ով նոյթբուքին batch ֆայլ pushելու փորձին։ Սերվերը գիտի, թե ով է միացել․ նոյթբուքը գիտի, թե ինչ տեսք ունի իր սեփական ցանցային կույտը։ Ոչ մեկը չունի մյուսի տեղեկությունը, և փորձը սովորաբար ձախողվում է լուռ, այլ ոչ թե հստակ սխալով։

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

Սերվերի կողմի տարբերակը՝ իրադարձություն յուրաքանչյուր միացման համար

client-connect սկրիպտը գործարկվում է սերվերի պրոցեսի համատեքստում, երբ նույնականացված հաճախորդը միանում է, և ստանում է փաստաթղթավորված միացման մանրամասներ, ինչպիսիք են common name-ը և հատկացված հասցեն։ Դա ճիշտ տեղն է յուրաքանչյուր հաճախորդի կոնֆիգուրացիայի հատված գրելու, քաղաքականության որոշում կիրառելու կամ սերվերին պատկանող վիճակ գրանցելու համար։

Մարդկանց բաց թողած տարբերությունը այդ կեռի և սերվերի up կեռի միջև եղած տարբերությունն է։ up կեռը գործարկվում է, երբ սերվերը բացում է իր թունելային սարքը, ինչը բազմահաճախորդ սերվերի վրա մեկ անգամ տեղի է ունենում դեմոնի մեկնարկին։ Դա յուրաքանչյուր մուտքի իրադարձություն չէ, և այնտեղ տեղադրված կոդը գործարկվում է ծառայության մեկնարկին, ոչ թե այն ժամանակ, երբ օգտագործողները միանում են։

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

Հաճախորդի կողմի տարբերակը՝ աշխատանք, որը պետք է տեղում կատարվի

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

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

Անվանակարգը նույնպես կարևոր է։ up կեռը համապատասխանում է սարքի ստեղծմանը, իսկ route-up-ը՝ երթուղիների տեղադրմանը, բայց մասնավոր ցանցի հասանելիություն պահանջող առաջադրանքը պետք է ստուգի հասանելիությունը, այլ ոչ թե ենթադրի, որ սարքի ստեղծումը նշանակում է, որ ամեն երթուղի, resolver գրառում և հավելված պատրաստ է։

Ինչու գործարկվող կոդ pushելը ցանկում չէ

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

Սկրիպտների գործարկումը տեղում միացնելը դա չի փոխում։ Ձեր script-security կարգավորումը թույլատրում է ձեր ընտրած տեղական սկրիպտները․ այն սերվերին իրավունք չի տալիս նորեր մատակարարել։

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

Ինչ ստուգել նախքան երկու կեռերից որևէ մեկին վստահելը

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

Փորձարկեք այն հաշվի ներքո, որն իսկապես կգործարկի այն, և այն պահին, երբ իսկապես կգործարկվի։ openvpn(8) ձեռնարկը փաստաթղթավորում է կեռերի երկու ընտանիքները և push-ի սահմանափակումները․ հարթակը, որի վրա տեղակայում եք, փաստաթղթավորում է, թե արդյոք այն ընդհանրապես դրանք տրամադրում է։ Սկրիպտը, որը հաջողվում է ինտերակտիվ ադմինիստրատորի տերմինալում, վարկած է, ոչ թե ստուգում։