Ո՞վ պետք է տիրապետի երթուղիներին և DNS-ին, երբ openfortivpn-ը միանում է։

Աշխատող openfortivpn նստաշրջանում չորս փուլեր շերտավորվում են միմյանց վրա։ Հաճախորդը նույնականացվում է դարպասում և սկսում TLS կապ, ապա գործարկում PPP այդ կապի ներսում, ապա ստանում հասցե և DNS տեղեկություն, և վերջում կիրառում հոսթի երթուղիներն ու resolver-ի կարգավորումները։ Յուրաքանչյուր փուլ կարող է կենդանի լինել, մինչ հաջորդը՝ ոչ, և դրա համար է «միացված» բառն այդքան սայթաքուն աջակցության թեմաներում։

Ամենաշատ շփոթությունը վերացնող որոշումն այն է, թե ով է տիրապետում վերջին փուլին։ Կա՛մ VPN հաճախորդն ինքն է կիրառում հոսթի փոփոխությունները, կա՛մ դա անում է մեկ այլ բաղադրիչ, և երկուսը կիսատ խառնելն է այն պատճառը, որ երթուղիներն ու resolver ֆայլերը վերջում տարբեր նստաշրջաններ են նկարագրում։

Չորս փուլեր, որոնք նման են մեկ կապի

Առաջին փուլը ընդունումն է։ անվանված նույնականացման տիրույթ կամ մեկանգամյա կոդ, և ստանում է շարունակելու համար անհրաժեշտ պարամետրերը։ Երբ հաճախորդը տպում է, որ միացած է դարպասին, դա նշանակում է, որ TLS տրանսպորտը աշխատում է։ Դա չի նշանակում, որ PPP-ն բանակցել է, և, իհարկե, չի նշանակում, որ ներքին հավելվածը հասանելի է։

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

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

Ով է խմբագրում երթուղային աղյուսակը

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

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

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

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

Ով է տիրապետում DNS-ին և resolver ֆայլին

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

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

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

Արտոնություն, պատրաստակամություն և հանձնում

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

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

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