Адзін хаб 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

Адключыце сувязь кліент-з-кліентам, калі ядро павінна быць пунктам прымянення правілаў. Гэтая опцыя перасылае трафік паміж партнёрамі ўнутры дэмана, што зручна і азначае, што вашыя правілы перасылкі ніколі не бачаць гэты паток. Усё ніжэй мяркуе, што ядро бачыць кожны пакет паміж філіяламі.

Дайце кожнаму філіялу патрэбныя маршруты

Кожнаму філіялу патрэбны маршруты да іншых філіялаў і да 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 называе ўладальніка, а міжсеткавы экран вырашае, што дазволена. Калі нешта ламаецца, гэты спіс — таксама парадак яго праверкі.