Մեկ OpenVPN հանգույց, երեք LAN՝ հասցեների պլան և iroute ֆայլեր
Չորս առանձին նախածանց, մեկ միջուկային երթուղի յուրաքանչյուր ճյուղի համար, մեկ iroute յուրաքանչյուր սեփականատիրոջ համար։ Աշխատանքային կարգ երեք տեղամասով հանգույցի համար, որը լուռ խափանվում է, երբ անունը սխալ է։
Երեք մասնավոր LAN կարող են հանդիպել մեկ հանգույցում առանց որևէ տեղամասի իմանալու մյուսների ներքինը, և ամբողջ ձևավորումը հենվում է չորս կարճ կարգավորման որոշումների վրա։ Այն աշխատեցնում է ոչ թե ինչ-որ էկզոտիկ արձանագրային հատկություն, այլ հասցեների պլան, որը ոչ ոք պետք չէ գուշակել, գումարած յուրաքանչյուր հաճախորդի համար երթուղիներ, որոնք հանգույցին ասում են, թե որ ճյուղն ունի որ նախածանցը։ Սխալվեք դրանցից որևէ մեկում, և թունելը միևնույն է բարձրանում է, և հենց դա է խափանումը շփոթեցնող դարձնում։
Անցեք քայլերը հերթականությամբ։ Յուրաքանչյուրը կախված է նախորդ քայլի պլանից, և ոչ մեկը նոր վկայագրային մարմին չի պահանջում։
Սկսեք պլանից, որը ոչ ոք պետք չէ գուշակել
Գրեք չորս չհատվող նախածանցեր նախքան կարգավորման ֆայլին դիպչելը՝ հանգույցի սեփական LAN-ը, յուրաքանչյուր ճյուղի LAN-ը և թափառող հաճախորդներին տրվող լողավազանը։ Չհատվելն է, որ մնացած ամեն ինչ պարզ է պահում, որովհետև համընկնող տիրույթները երթուղավորումը դարձնում են ամենաերկար համապատասխանության հանելուկ, որը ոչ մի հաճախորդային կարգավորում չի ուղղում։ Այնուհետև հաստատեք, թե որ մեքենան է յուրաքանչյուր LAN-ի լռելյայն դարպասը, որովհետև ճյուղի երթուղիչը, որը իր LAN-ի դարպասը չէ, հեռավոր երթուղիները պետք է տեղադրի բոլորովին այլ տեղ։ Վերջապես, ամրագրեք նույնականացված անունները, որոնք նույնականացնում են յուրաքանչյուր ճյուղը, որովհետև հենց այդ անուններով են փնտրվում հաճախորդային ֆայլերը։
Օրինակելի պլանը լողավազանը հեռու է պահում երեք LAN-ից։ Ձերը կտարբերվի, և միակ խիստ կանոնն այն է, որ երկու տիրույթ չհատվեն։
Hub LAN 172.20.0.0/24
Branch A LAN 172.21.0.0/24
Branch B LAN 172.22.0.0/24
VPN pool 10.77.0.0/24
identity branch-a owns 172.21.0.0/24
identity branch-b owns 172.22.0.0/24Ասացեք հանգույցի միջուկին, թե որտեղ են ճյուղերը
Հանգույցին յուրաքանչյուր ճյուղի համար երկու տեղեկություն է պետք՝ միջուկային երթուղի, որը նախածանցն ուղարկում է թունելային սարք, և iroute գրառում, որը OpenVPN գործընթացին ասում է, թե որ հաճախորդն է այն տիրում։ Միայն միջուկային երթուղին փաթեթները հասցնում է թունել և այնտեղ կանգ է առնում, որովհետև դեմոնը դեռ պետք է որոշի, թե որ գործընկերը պետք է ստանա դրանք։ Միայն iroute գրառումը թողնում է այդ փաթեթները միջուկում առանց հետևելու երթուղու։ Երկու տողերն էլ պատկանում են այն կարգավորմանը, որը դեմոնն իրականում բեռնում է, և արժե ստուգել այն նախքան որևէ այլ բան վրիպազերծելը։
dev tun
topology subnet
server 10.77.0.0 255.255.255.0
disable-dco
route 172.21.0.0 255.255.255.0
push "route 172.20.0.0 255.255.255.0"
client-config-dir /etc/openvpn/ccd
route 172.22.0.0 255.255.255.0Անջատեք հաճախորդ-հաճախորդը, երբ միջուկը պետք է լինի կիրարկման կետը։ Այդ ընտրանքը գործընկերների միջև երթևեկությունը փոխանցում է դեմոնի ներսում, ինչը հարմար է և նաև նշանակում է, որ ձեր փոխանցման կանոնները երբեք չեն տեսնում հոսքը։ Ստորև ամեն ինչ ենթադրում է, որ միջուկը տեսնում է յուրաքանչյուր փաթեթ ճյուղերի միջև։
Տվեք յուրաքանչյուր ճյուղին անհրաժեշտ երթուղիները
Յուրաքանչյուր ճյուղի պետք են երթուղիներ դեպի մյուս ճյուղերը և հանգույցի LAN-ը, և նրան պետք չէ երթուղի դեպի իր իսկ միացված LAN-ը։ Հեռավոր նախածանցները հանգույցից հրեք՝ դրանք ամեն երթուղիչի մեջ փակցնելու փոխարեն, որպեսզի չորրորդ տեղամասը հետագայում չորս խմբագրության փոխարեն մեկ նոր հաճախորդային ֆայլ նշանակի։ Հաճախորդային ֆայլը կրում է նաև iroute տողը, որը սեփականությունը և հայտարարությունը պահում է նույն տեղում։ Դարձրեք պանակը և նրա ֆայլերը ընթեռնելի ըստ սերվերի արտոնությունների մոդելի, հակառակ դեպքում որոնումը ձախողվում է առանց հաղորդագրության։
# /etc/openvpn/ccd/branch-a
iroute 172.21.0.0 255.255.255.0
push "route 172.22.0.0 255.255.255.0"Չորրորդ տեղամասը հետևում է նույն օրինաչափությանը՝ առանձին նույնականացված անուն, սեփականացված նախածանց, միջուկային երթուղի հանգույցում, iroute գրառում, և հայտարարություններ միայն այն տեղամասերին, որոնց թույլատրված է հասնել դրան։
Փորձարկեք երկու ուղղությամբ էլ նախքան այն ավարտված համարելը
Միացրեք IPv4 փոխանցումը բոլոր երեք երթուղիչներում, ապա հաստատեք, որ հրապատը թույլատրում է նախատեսված հոսքերը երկու ուղղությամբ էլ, որովհետև միակողմանի փորձարկումը կոտրված վերադարձի ուղով հաջողվում է ավելի հաճախ, քան ոչ ոք է սպասում։ Տեղամասերի միջև աղբյուրի թարգմանություն պետք չէ, և հենց սկզբնական աղբյուրի պահպանումն է թույլ տալիս յուրաքանչյուր ճյուղին կիրառել իր սեփական քաղաքականությունը հարցման վրա։
Փորձարկեք մեկ ճյուղի LAN-ի հոսթից մյուսի ծառայությանը, ապա շրջեք ուղղությունը, ապա փորձարկեք ճյուղից դեպի հանգույցի LAN-ը։ Այդ երեք արդյունքները տարբեր ապացույցներ են, և ոչ մեկը չի ենթադրում մյուսներին։ Եթե ճյուղի երթուղիչը իր LAN-ի լռելյայն դարպասը չէ, տեղադրեք հեռավոր նախածանցերը իրական դարպասի վրա և ներառեք նաև լողավազանը, երբ թունելի հաճախորդները պետք է միացումներ սկսեն այդ LAN-ի մեջ։
Գրանցեք պլանը, հաճախորդային ֆայլերը և հրապատի կանոնները որպես մեկ փաստաթուղթ, որովհետև հաջորդ տեղամասի ավելացումը գնահատվելու է դրանցով։
Ձևավորումը համախմբված է մնում, որովհետև յուրաքանչյուր շերտ ունի մեկ գործողություն՝ պլանը նախածանցերը պահում է եզակի, միջուկային երթուղին տեղափոխում է փաթեթները, iroute անվանում է սեփականատիրոջը, իսկ հրապատը որոշում է, թե ինչ է թույլատրված։ Երբ ինչ-որ բան կոտրվում է, այդ ցանկը նաև դրա ստուգման կարգն է։