Бір OpenVPN хабы, үш LAN: мекенжай жоспары және 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

Ядро ережелерді орындау нүктесі болуы керек кезде client-to-client өшірулі қалсын. Бұл опция теңдестер арасындағы трафикті демонның ішінде жеткізеді, бұл ыңғайлы әрі сіздің бағыттау ережелеріңіз ағынды ешқашан көрмейтінін білдіреді. Төмендегілердің бәрі ядро әр филиаларалық пакетті көреді деп есептейді.

Әр филиалға қажет маршруттарын беріңіз

Әр филиалға басқа филиалдарға және хаб 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 иесін атайды, ал файрвол неге рұқсат екенін шешеді. Бірдеңе бұзылса, сол тізім тексеру тәртібі де болады.