Многосетальная система OpenBSD: на основе политик маршрутизация против маршрутов по умолчанию mpath
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 / Wifi, и служит нашим резервным провайдером; а GW имеет дополнительные ссылки на кластер и коммутатор.
Добро пожаловать в мечту о балансировке нагрузки.
Это допустимо, но ваш лучший маршрут и безболезненный режим - это использование протокола BGP-маршрутизации и управление Downstream и Upstream трафиком с помощью политик.
Для этого вы должны договориться с обоими провайдерами, чтобы они включили вас в качестве внутреннего iBGP узла, чтобы вы могли прокладывать свои маршруты в интернет.
Правильным способом будет запрос вашего собственного автономного системного номера. и управление всеми вашими IP-адресами, которые у вас есть. Это немного сложно выполнить из-за требований.
http://teamarin.net/2014/01/31/how-to-request-an-asn-from-arin/
Если вы квалифицируетесь в соответствии с политикой многоадресной доставки, вам нужно будет предоставить внешний протокол шлюза, который будет использоваться, IP-адреса. используемый в настоящее время в вашей сети, AS номер и имя каждого из ваши поставщики услуг по разведке и добыче и/или коллеги, а также договорные проверка сервиса как минимум двумя из них.
Если вы квалифицируетесь в соответствии с уникальной политикой маршрутизации, вы должны продемонстрировать, что политика маршрутизации AS будет отличаться от политики маршрутизации. политики своих коллег на границе.
Независимо от того, под какой политикой вы подпадаете, если это не первая ваша политика. время запроса ASN, вам также нужно будет показать нам, как сеть вы запрашиваете ASN для автономной от всех существующих ASN в Также и в вашей сети.
Вот хорошая статья о Multihoming с использованием BGP: http://aspath.net/BGP-MHing-HOWTO-whitepaper.pdf
если вы не хотите, не можете создавать BGP-сессии с вашими провайдерами, то другим решением будет использование аппаратного компенсатора нагрузки. (Технически говоря, большинство аппаратных средств запускают некоторые модифицированные BSD для достижения возможностей продуктов. так что, если у Вас есть знания, Вы можете настроить его на сервере под управлением BSD. но Вы никогда не получите trhoguput аппаратного устройства с выделенным аппаратным обеспечением для сетевой обработки, но если Ваша нагрузка невелика (более 50 Мбит/с я бы сказал), Вы можете это сделать)
.