я думаю об использовании динамической маршрутизации [OSPF или RIP] через OpenVPN туннели. прямо сейчас у меня несколько офисов, соединенных в полную сеть, но это не масштабируемое решение, так как мы добавляем больше местоположений. Я бы хотел избежать ситуации, когда большое количество внутреннего трафика будет нарушено, если одна из двух точек завершения VPN, которые я планирую использовать, не работает.
у вас есть аналогичная конфигурация, работающая в производстве? если да, то какой демон маршрутизации вы использовали - квагга? что-то другое? у вас возникли проблемы?
Спасибо!
Я реализовал что-то подобное раньше, но моя установка была довольно сложной, возможно, слишком сложной. В настоящее время я изучаю возможность реализации более простого решения в духе / под влиянием того, что описано по следующему URL-адресу, но я опишу то, что я создал за это время. URL-адрес http://www.linuxjournal.com/article/9915
Один из вариантов, который в прошлом мне очень хорошо помогал, - это создание туннелей OpenVPN с использованием устройств Tap вместо устройств tun. Это инкапсулирует Ethernet через туннель вместо уровня 3 и позволяет вам обойти внутренние ограничения OpenVPN, сохраняя свою собственную таблицу маршрутизации отдельно от ядра. Обратной стороной является то, что вы несете большие накладные расходы из-за туннелирования таким образом ... представьте себе TCP через Ethernet через TCP, зашифрованный SSL ... вы поняли. Плюс в том, что он работал и достаточно хорошо масштабировался по горизонтали.
Предполагая, что ваши VPN-серверы и клиенты являются конечными точками Linux (я тестировал только на Linux), вы можете создать новый интерфейс виртуального моста и назначить интерфейс перехода для моста, чтобы получить свой уровень 3. В моей топологии я дал каждому VPN-серверу свой собственная подсеть 10.x.0.0 / 16, а также развернут локальный DHCP-сервер для назначения адресов подключающимся клиентам. Сервер DHCP должен быть там, потому что OpenVPN больше не знает IP-адреса; это туннелирование Ethernet. Клиенты запускают dhclient для получения IP-адреса через интерфейс VPN после подключения, и все это управляется скриптами подключения, привязанными к конфигурации OpenVPN.
Если у вас есть IP-адреса с обеих сторон через DHCP, вы можете использовать протокол динамической маршрутизации для объявления маршрутов между подключенными клиентами. Раньше я использовал Quagga, и он работает довольно надежно.
Пример конфигурации сервера с использованием tap:
mode server
proto tcp-server
port 1194
dev tap0
Примеры команд для добавления интерфейса крана в новый мост:
sudo brctl addbr vpnbr0 # create new bridge called vpnbr0
sudo brctl setfd vpnbr0 0 # set forwarding delay to 0 secs
sudo brctl addif vpnbr0 tap0 # add openvpn tap interface to vpnbr0
Пример команд демонтажа:
sudo brctl delif vpnbr0 tap0
sudo brctl delbr vpnbr0
Если у вас есть интерфейс моста vpnbr0, вы можете запустить на нем DHCP-сервер или назначить IP-адреса вручную. Затем вы можете рассматривать его как любой другой интерфейс Ethernet. Возможно, вы захотите внести дополнительные изменения, чтобы настроить размер MTU, и вы можете попробовать различные протоколы и параметры шифрования, пока не найдете правильный баланс между эффективностью и безопасностью. У меня больше нет хороших спецификаций по общей пропускной способности, и здесь много движущихся частей.
Если бы мне пришлось сделать это снова, я бы придерживался устройств tun в OpenVPN, и я бы следовал инструкциям в статье, которую я связал в первом абзаце, чтобы обновлять таблицу маршрутизации ядра Linux в любое время при обновлении внутренней таблицы адресов OpenVPN. Это исключит DHCP из стека, уменьшит накладные расходы на туннелирование и позволит моим клиентам подключаться и работать без участия в динамической маршрутизации.
В настоящее время у нас есть несколько экземпляров OpenVPN AS, работающих со статическими маршрутами, указывающими на каждый из них. Мы назначили подсеть / 24 каждому серверу OpenVPN. В настоящее время у нас есть пользователи, указывающие вручную на каждый сервер, но вы можете использовать различные технологии, чтобы указать пользователям правильный сервер.
Единственная проблема здесь заключается в том, что в случае отказа OpenVPN-сервера пользователям потребуется подключиться к другому серверу для получения трафика. Это связано с тем, что мы перераспределяем статический маршрут на сервер OpenVPN, поскольку OpenVPN AS не поддерживает OSPF.
Существуют маршрутизаторы с открытым исходным кодом, поддерживающие OpenVPN, такие как Vyatta, но мы предпочитаем веб-интерфейс OpenVPN AS.