Бир 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 ээсин атайт, ал эми файрвол эмнеге уруксат экенин чечет. Бир нерсе бузулганда, ошол тизме текшерүү тартиби да болуп калат.