Երկու OpenVPN հաճախորդ մեկ Linux դարպասում՝ բաժանեք քաղաքականությունը

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

Միջուկն է որոշում, ոչ դեմոնը

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

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

Տվեք յուրաքանչյուր օրինակի իր ռեսուրսների հավաքածուն

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

dev tun-office
route-nopull
pull-filter ignore "redirect-gateway"

dev tun-lab
route-nopull

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

Գրեք մատրիցան՝ աղբյուր, աղյուսակ, սարք

Յուրաքանչյուր հաճախորդի խմբի համար ավելացրեք կանոն, որը աղբյուրի հասցեով աղյուսակ է ընտրում, ապա նախատեսված ուղին դրեք այդ աղյուսակում՝

ip rule add from 10.8.1.0/24 lookup 100 priority 1000
ip rule add from 10.9.1.0/24 lookup 200 priority 1000
ip route add default dev tun-office table 100
ip route add default dev tun-lab table 200

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

Թունելի սեփական փոխադրումը հաճախորդի խմբում չէ

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

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

Ուղու ընտրությունը այն չի թույլատրում

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

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

Ինչ է պատահում, երբ մեկ թունելն ընկնում է

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

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