динамическая маршрутизация между туннелями openvpn
Я реализовал нечто подобное раньше, но моя установка была довольно сложной, возможно, даже слишком. В настоящее время я изучаю возможность реализации более простого решения в духе / под влиянием того, что описано по следующему 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
Пример команд для добавления интерфейса Tap в новый мост:
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 ' s таблица маршрутизации в любое время обновляется внутренняя таблица адресов OpenVPN. Это исключит DHCP из стека, уменьшит накладные расходы на туннелирование и позволит моим клиентам подключаться и работать без участия в динамической маршрутизации.
У нас в настоящее время есть несколько экземпляров OpenVPN AS, работающего со статическими маршрутами, указывающими на каждого. Мы присвоили/24 подсеть каждому серверу OpenVPN. В настоящее время нам указывали на пользователей вручную каждый сервер, но Вы могли использовать множество технологий для указания на пользователей на корректного.
Единственная проблема здесь - то, что в конечном счете подача OpenVPN понижается, пользователи должны будут соединиться с другим сервером для получения трафика. Это - то, вследствие того, что мы перераспределяем статический маршрут к серверу OpenVPN, так как OpenVPN AS не поддерживает OSPF.
Существуют маршрутизаторы с открытым исходным кодом, которые поддерживают OpenVPN, такой как Vyatta, но мы предпочитаем веб-интерфейс OpenVPN AS.