Один хаб OpenVPN, три сети LAN: план адресации и файлы iroute

Четыре непересекающихся префикса, один маршрут ядра на филиал, один iroute на владельца. Порядок работы для хаба на три площадки, который тихо отказывает при неверном имени.

Три частные сети 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 хаба, а маршрут к собственной подключённой сети ему не нужен. Проталкивайте удалённые префиксы с хаба, а не вклеивайте их в каждый маршрутизатор, чтобы четвёртая площадка позже означала один новый файл на клиента вместо четырёх правок. Файл на клиента содержит также строку 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 хаба. Эти три результата — разные доказательства, и ни один не подразумевает остальные. Если маршрутизатор филиала не является шлюзом по умолчанию своей сети, установите удалённые префиксы на настоящем шлюзе и включите также пул, когда туннельным клиентам нужно начинать соединения в эту сеть.

Запишите план, файлы на клиента и правила межсетевого экрана как один документ, поскольку следующее добавление площадки будет оцениваться по ним.

Проект держится вместе, потому что у каждого слоя одна задача: план сохраняет уникальность префиксов, маршрут ядра перемещает пакеты, iroute называет владельца, а межсетевой экран решает, что разрешено. Когда что-то ломается, этот список — ещё и порядок проверки.

Похожие статьи