Ці могуць кліенты на двух серверах OpenVPN дасягаць адзін аднаго?

Запуск другога OpenVPN сервера дае вам другое месца для падключэння кліентаў і больш нічога. Ён не змяшчае гэтых кліентаў у сетку першага сервера, а опцыя client-to-client змяняе толькі перасылку ўнутры аднаго працэсу сервера. Два пулы становяцца адной сеткай, калі вы мэтанакіравана маршрутызуеце паміж імі, з уладальнікам для кожнага кірунку. Усё ніжэй мяркуе рэжым TUN у прасторы карыстальніка з адключанай такой унутранай перасылкай, таму рашэнне прымае ядро.

Міф: адзін спіс уліковых запісаў, адна сетка

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

Такім чынам, другі сервер не дадае рэзервавання, выяўлення або агульнага шырокавяшчальнага дамена. Ён дадае маршрутызаваную сетку, якая патрабуе плана, і план пачынаецца з адрасацыі.

Дайце кожнаму шлюзу свой пул і адрас транзіту

Два дыяпазоны, якія не могуць перасякацца ні з чым іншым, плюс невялікая транзітная сувязь паміж хастамі — гэта ўвесь план адрасацыі. Трымайце транзіт на прыватным сегменце, які вы кантралюеце, і запішыце лічбы, перш чым любы сервер выдасць арэнду.

Супрацьстойце спакусе даць абодвум серверам адзін пул, каб профілі заставаліся аднолькавымі. Маршрут у ядры не можа сказаць, які з двух хастаў зараз валодае адвольным адрасам унутры агульнага дыяпазону, таму табліца маршрутызацыі паказвала б на адзін шлюз, а кліент мог быць падключаны да іншага. Імёны інтэрфейсаў — лакальныя ўмоўнасці, а не агульны стан. Абодва хасты тут называюць тунельны прылад tun0, а транзітную сувязь — transit0, што нармальна, бо ні адзін пакет не нясе гэтых імёнаў.

Усталюйце маршрут з абодвух бакоў

Кожнаму шлюзу патрэбны маршрут да пула іншага праз адрас транзіту, і перасылка павінна быць уключана, каб любы з іх мог быць прамежкавым вузлом. Спачатку пацвердзіце бягучую табліцу, затым дадайце запіс і захавайце яго праз сеткавы менеджар хаста, а не праз хук перападключэння.

sysctl net.ipv4.ip_forward
ip route add 10.64.20.0/24 via 172.28.44.2 dev transit0
ip route get 10.64.20.37

Паўтарыце гэта на іншым хасте, памяняўшы пулы. Паўторнае даданне таго ж маршруту з незвязанага скрыпта — гэта як хаст атрымлівае некалькі копій і загадкавае змяненне наступным разам, калі хтосьці чытае табліцу. Калі транзітная сувязь сама з'яўляецца тунелем, маршрут паказвае на тапалогію гэтага тунеля, і прамежкавы вузел павінен перажыць яго перападключэнне. Адрас транзіту, які знікае на трыццаць секунд, забірае з сабой шлях паміж пуламі, і гэта ўласцівасць дызайну, якую варта заявіць, а не выявіць.

Прасоўвайце маршрут кліента, не фальсіфікуючы ўладанне

Кліентам патрэбны маршрут да аддаленага пула, інакш іх уласная аперацыйная сістэма адпраўляе пакет на шлюз па змаўчанні, і тунель яго не бачыць. Канфігурацыя сервера — натуральнае месца, каб гэта даставіць.

push "route 10.64.20.0 255.255.255.0"

Змесціце люстраны радок у канфігурацыю іншага сервера, затым перападключыце тэставы кліент і прачытайце яго табліцу. Кліенту, які ігнаруе прасунутыя маршруты, патрэбна ўласная зацверджаная канфігурацыя, а маршрут, які ніколі не прыходзіць, не з'яўляецца кантролем доступу. Не давайце кліенту iroute для ўсяго пула іншага шлюза. Гэтая дырэктыва існуе для падсеткі за адным падключаным кліентам, і выкарыстанне яе, каб прыхаваць адсутны міжшлюзавы маршрут, стварае сервер, які лічыць, што валодае адрасамі, да якіх не можа дасягнуць.

Дакажыце адзін запыт і адхіліце іншы

Выберыце рэальную аперацыю, напрыклад HTTPS ад кліента на 10.64.10.21 да службы на 10.64.20.37, і дазвольце менавіта гэта на абодвух хастах. Кожны фільтр прымае запыт на сваім уваходным баку і адсочваемы адказ на баку вяртання; уласная палітыка службы прызначэння ўсё яшчэ павінна яго прыняць.

iptables -A FORWARD -i tun0 -o transit0 -s 10.64.10.21 -d 10.64.20.37 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i transit0 -o tun0 -d 10.64.10.21 -s 10.64.20.37 -p tcp --sport 443 -m conntrack --ctstate ESTABLISHED -j ACCEPT

Пры ўзаемных маршрутах трансляцыя адрасоў крыніцы не патрэбна і тут актыўна шкодная: трансляцыя крыніцы хавае, які кліент зрабіў запыт, і перамагае палітыку на аснове крыніцы на баку прызначэння. Праверце, што існуючае правіла маскараду для выхаду ў інтэрнэт не захоплівае і гэты шлях. Затым праверце адмову. Служба, якая павінна заставацца лакальнай для пула B, павінна заставацца недасяжнай з пула A, а пары кліентаў на адным шлюзе таксама трэба тэставаць, бо палітыка перасылкі, якую вы толькі што змянілі, датычыцца і іх.

Яшчэ адна папраўка да разумовай мадэлі: транзітная сувязь нясе расшыфраваныя ўнутраныя пакеты, таму гэта мяжа даверу, а не прыватная гарантыя. Калі яна перасякае сетку, якую вы не кантралюеце, абараніце гэты вузел зацверджаным шыфраваным тунелем і маршрутызуйце праз яго рэальную тапалогію. Наскразное TLS усё яшчэ аўтэнтыфікуе прыкладанне само, таму ўнутраная служба павінна працягваць яго выкарыстоўваць.