Динамическая маршрутизация между туннелями openvpn
Я думаю об использовании динамической маршрутизации [ OSPF или RIP ] через туннели OpenVPN. сейчас у меня есть несколько офисов, связанных в полную сетку, но это не масштабируемое решение, так как мы добавляем больше мест. Я хотел бы избежать ситуации, когда большое количество внутреннего трафика будет затронуто, если одна из двух точек завершения VPN, которые я планирую использовать, не работает.
у вас есть аналогичные конфигурации, работающие в производстве? если да - какой демон маршрутизации вы использовали - quagga? что-то другое? у вас возникли проблемы?
Спасибо!
2 ответа
Я реализовал что-то подобное ранее, но мои настройки были довольно сложными, возможно, слишком сложными. В настоящее время я изучаю реализацию более простого решения в соответствии с тем, что описано в следующем URL-адресе, под влиянием / под влиянием этого, но я опишу то, что я построил за это время. URL-адрес http://www.linuxjournal.com/article/9915
Одна из опций, которая в прошлом работала достаточно хорошо для меня, - это создание моих туннелей OpenVPN с использованием отводных устройств вместо Tun-устройств. Это инкапсулирует Ethernet по туннелю вместо уровня 3 и позволяет обойти внутренние ограничения OpenVPN, поддерживающего его собственную таблицу маршрутизации отдельно от ядра. Недостатком является то, что при туннелировании вы получаете много накладных расходов... представьте, что TCP через Ethernet через SSL зашифрован по протоколу TCP... вы поняли идею. Сверх того, он работал и масштабировался по горизонтали довольно хорошо.
Предполагая, что ваши VPN-серверы и клиенты являются конечными точками Linux (я тестировал только на Linux), вы можете создать новый интерфейс виртуального моста и назначить интерфейс отвода мосту, чтобы получить ваш уровень 3. В своей топологии я дал каждому VPN-серверу свой собственная подсеть 10.x.0.0 / 16, а также развернутый локальный DHCP-сервер для назначения адресов подключающимся клиентам. Сервер DHCP должен быть там, потому что OpenVPN больше не знает IP-адреса; это туннель Ethernet. Клиенты запускают dhclient для получения IP через интерфейс VPN после подключения, и все это управляется сценариями подключения, привязанными к конфигурации OpenVPN.
Если у вас есть IP-адреса с обеих сторон через DHCP, вы можете использовать протокол динамической маршрутизации для объявления маршрутов между подключенными клиентами. Я использовал Quagga в прошлом, и он работает довольно надежно.
Пример конфигурации сервера с использованием крана:
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.