TL; DR Поможет ли маршрутизация на основе политик OpenBSD в ситуации с многосетевым сервером / шлюзом? Если да, то как мне его настроить?
Длинная форма
Я управляю OpenBSD с двумя связями ISP и туннелями VPN к удаленным узлам маршрутизации.
Первоначально мы использовали несколько маршрутов по умолчанию с различными показателями - предпочтительный маршрут через статический IP-адрес маршрутизатора NAT, который, в свою очередь, имеет динамически назначаемые адреса (в основном это кабельный модем).
На практике это было не идеально, но работает достаточно хорошо. Новые соединения, установленные от шлюза (далее называемые просто «gw»), выберут маршрут с более высокой скоростью и меньшей задержкой, если он установлен; и выйти через кабельный модем, если связь не работает. Входящее соединение могло проходить только по лучшему маршруту, поскольку другие IP-адреса находились за NAT (не маршрутизируемыми извне.
Теперь нам нужно направить трафик через дополнительные узлы прокси / VPN-маршрутизатора «в облаке», чтобы снизить риски DDoS на наших статических IP-адресах.
Они подключаются к шлюзу через туннели.
первый. Затем мы обнаружили, что у нас периодически пропадал доступ администратора.
Чтобы еще больше усложнить ситуацию, этот шлюз имеет дополнительные активные интерфейсы для определенных VLAN. Они не имеют отношения к этой проблеме, но их нельзя беспокоить.
Возможное решение
У меня сложилось впечатление, что мы должны использовать маршрутизацию на основе политик, rdomains. Думаю, это означает, что я создаю таблицы маршрутизации для каждого из трех задействованных интерфейсов и любого соединения на любом из них (включая tun0 туннельный интерфейс) должен маршрутизироваться через таблицу для этого домена (и, таким образом, каждый может иметь свой собственный маршрут по умолчанию).
Я на правильном пути?
Вот диаграмма и очищенный список настроек интерфейса:
________
| tunnel | _______
~~~+~~~~ | GW |======++
| ~+~+~+~ ||
| _________ | | | ||
+-----| prefISP |-------------+ | | __||____ .........
~~~~~~~w~ | +-----| Switch |-----( Cluster )
| ~~~~~~~~ ^^^^^^^^^
_________ .....|...... ||
| fallISP |---------( LAN / WiFi )===++
~~~~~~~~~ ^^^^^^^^^^^^
Diagram: I want to avoid asymmetric routing when accessing GW through the tunnel, through the preferred ISP, and when accessing GW or the cluster (through the GW or from the LAN).
Sanitized interface info:
em3: inet 123.45.67.118 netmask 0xfffffff8 broadcast 123.45.67.119 description: prefISP
em0: inet 10.1.1.100 netmask 0xffffff00 broadcast 10.1.1.255 description: fallISP
tun0: inet 192.168.2.2 --> 192.168.2.1 netmask 0xffffff00 description: tunnel
em1: VLAN_TRUNK
vlan1000: inet 172.29.1.1 netmask 0xffffff00 broadcast
Как указано: em3 наша ссылка на предпочтительного (более быстрого) провайдера; tun0 проходит через это; em0 находится в том же сегменте, что и офисная LAN / Wi-Fi, и служит нашим резервным интернет-провайдером; а GW имеет дополнительные ссылки на кластер и коммутатор.
Добро пожаловать в мечту о балансировке нагрузки.
Это возможно, но ваш лучший маршрут и безболезненный режим - использовать протокол маршрутизации BGP и управлять нисходящим и восходящим трафиком с помощью политик.
Чтобы это удалось, вам необходимо договориться с обоими интернет-провайдерами, чтобы они включили вас в качестве внутреннего узла iBGP, чтобы вы могли протолкнуть свои маршруты маршрутов в Интернет.
Правильный способ - запросить собственный номер автономной системы. и управляйте всеми своими IP-адресами. это немного сложно выполнить из-за требований.
http://teamarin.net/2014/01/31/how-to-request-an-asn-from-arin/
Если вы соответствуете требованиям многосетевой политики, вам необходимо будет предоставить протокол внешнего шлюза, который будет использоваться, IP-адреса, которые в настоящее время используются в вашей сети, номер AS и имя каждого из ваших вышестоящих поставщиков и / или партнеров, а также договорную проверку обслуживания как минимум с двумя из них.
Если вы подходите под уникальную политику маршрутизации, вы должны продемонстрировать, что политика маршрутизации AS будет отличаться от политик маршрутизации ее пограничных узлов.
Независимо от того, под какую политику вы подпадаете, если вы не впервые запрашиваете ASN, вам также необходимо будет показать нам, как сеть, для которой вы запрашиваете ASN, также автономна от всех существующих AS в вашей сети.
Вот хорошая статья о множественной адресации с использованием BGP: http://aspath.net/BGP-MHing-HOWTO-whitepaper.pdf
Если вы не желаете или не можете создавать сеансы BGP с вашими поставщиками услуг Интернета, то другим решением является покупка аппаратного балансировщика нагрузки. (технически говоря, на большинстве аппаратных средств используются некоторые модифицированные BSD для реализации функций продукта. Так что, если у вас есть знания, вы можете настроить его на сервере, на котором работает BSD. но вы никогда не получите доступ к аппаратному устройству с выделенным оборудованием для сетевой обработки , но если у вас небольшая нагрузка (я бы сказал, более 50 Мбит / с), вы можете это сделать)