Основная цель статьи – показать процесс установки и настройки виртуальных маршрутизаторов VyOS на кластере oVirt, для организации связи на уровне L3 между внутренними и внешними сетями.
Также в статье будут рассмотрены вопросы, связанные с особенностями настройки выхода в Интернет через двух провайдеров, и повышения отказоустойчивости межсетевой маршрутизации.
Вводная часть
Основываясь на двух предыдущих статьях:
- Создание отказоустойчивой ИТ инфраструктуры. Часть 1 — подготовка к развёртыванию кластера oVirt 4.3
- Создание отказоустойчивой ИТ инфраструктуры. Часть 2. Установка и настройка кластера oVirt 4.3
Мы к этому времени создали отказоустойчивый кластер oVirt, с подключенным к нему СХД для хранения виртуальных дисков ВМ. При этом все сетевые устройства и хосты коммутируются в стек из двух коммутаторов второго уровня Cisco C2960RX, на котором настроены соответствующие порты в транковом или статическом режимах, и к которым привязаны идентификаторы VLAN.
С формальной и практической точек зрения, у нас имеется полная связность на уровне L2 между устройствами и ВМ в пределах одного и тоже VLAN'а.
VLAN – это «виртуальная» локальная сеть, в которой все хосты взаимодействуют друг с другом в пределах одной широковещательной области (или сети). Обычно широковещательные области изолируются друг от друга с помощью VLAN, настраиваемых на портах коммутатора, хотя давным-давно сети разделяли физически, а не логически, подключая хосты из определённой группы доступа, к своим сетевым концентраторам, или хабам.
Для взаимодействия хостов из разных широковещательных областей (VLAN'ов) между собой, нам необходимо устройство, которое может соединить их на третьем уровне OSI, или по-простому – маршрутизатор. Это устройство, в свою очередь, также может использоваться для подключения к внешним сетям, обеспечивая выход из внутренних сетей в Интернет.
Основная наша задача – это создание отказоустойчивой ИТ инфраструктуры, в том числе и сетевой, поэтому нам потребуется связка из двух маршрутизаторов, где один маршрутизатор является ведущим, а второй ведомым. В случае выхода из строя ведущего маршрутизатора, в дело вступает ведомый, и весь трафик начинает идти через него.
Главное требование к такой схеме – она должна быть устойчивой и абсолютно прозрачной для всех сетевых потребителей, т.е. они не должны страдать от каких-либо потерь во время таких переключений, и тем более на них ничего не нужно дополнительно настраивать, кроме IP адреса, маски и шлюза по умолчанию.
В качестве маршрутизатора был выбран VyOS версии 1.2.2, по причине уже довольно длительной эксплуатации (в нашей организации), в ходе которой он показал себя только с положительной стороны, работая как на физических серверах, так и в виде виртуальных машин под управлением гипервизора KVM.
VyOS содержит в себе много полезного для сетевого администрирования функционала – работу с динамическими протоколами маршрутизации, VPN и IPSec туннелями, WAN load balancing, VRRP, QoS, и т.д.
В основе VyOS лежит ядро Debian, а CLI (командный интерфейс), очень напоминает таковой у Juniper, так что особой сложности у тех, кто с ним уже знаком, он не вызовет.
О наличии GUI (графической оболочки) для VyOS на сегодняшний момент ничего не известно, но работа в его консоли для любого Linux/Cisco/Juniper администратора, не должна вызывать затруднений, тем более что «под капотом» у него Debian, в котором можно при необходимости запускать знакомые системные утилиты, хотя конечно же необходимо использовать в первую очередь CLI самого VyOS.
Как всегда, перед началом работы с новым ПО, желательно ознакомиться с документаций на него – VyOS User Guide, чтобы дальнейшее чтение статьи прошло без сложностей. К тому же на Habr имеется свежая обзорная статья про VyOS, надеюсь что автор будет не против ссылки на неё :)
Дистрибутив VyOS доступен в следующих вариантах:
- по подписке – это стабильные LTS (long-term support) версии;
- в виде rolling releases, выпускающихся ежедневно (использовать в production можно, но только после тщательного и длительного тестирования и конечно на свой страх и риск);
- в виде самостоятельно собранного LTS образа VyOS из исходников.
Для ускорения процесса развёртывания маршрутизаторов, в статье будет использоваться свежий rolling release VyOS 1.2.2, как вариант можно использовать бесплатную предыдущую LTS версию VyOS 1.1.8.
Протоколы и технологии (применительно к VyOS), которые будут задействованы в статье:
Подключение датацентра к Интернет с помощью протокола BGP в этой статье не рассматривается, так как у большинства организаций обычно нет такой необходимости, но при наличии технических возможностей и поддержке со стороны провайдеров, его можно без проблем реализовать.
Итак, после небольшого вступления, перейдём к основной теме статьи. Чтобы было удобно ориентироваться, приведу основные главы статьи:
- Описание тестового стенда.
- Подготовительные работы.
- Начальная настройка маршрутизаторов VyOS.
- Настройка правил на файерволе.
- Настройка vrrp для отказоустойчивой маршрутизации.
- Настройка выхода в Интернет через двух провайдеров.
Описание тестового стенда
Для тестового стенда в качестве внешних IP адресов и сетей, везде указаны приватные IP адреса, что конечно же никак не меняет сути нашей задачи и правил, по которым работают протоколы маршрутизации и функционирует Интернет. Ничто не помешает затем вместо приватных адресов использовать публичные адреса, и подключить нашу инфраструктуру к сети Интернет.
Для реализации отказоустойчивого подключения к сети Интернет и внутренним сетям, будут использоваться:
- два виртуальных маршрутизатора – VyOS1 и VyOS2.
- три виртуальных маршрутизатора с ОС CentOS 7 и пакетом Quagga – Provider-1, Provider-2 и Provider-3, для эмуляции работы сети Интернет.
- несколько клиентских машин с ОС CentOS 7, для тестирования связности между внутренними и внешними сетями.
Все виртуальные маршрутизаторы и клиентские ВМ, будут работать на кластере oVirt. Это не значит, что весь тестовый стенд «заточен» именно под oVirt, его можно реализовать на чём угодно – на ВМ под управлением обычного KVM, VMware, Hyper-V, и даже на физических хостах.
Общая схема сети на уровне L3 для тестового стенда:
На этой схеме имеется несколько допущений:
- все «публичные» сети начинаются с 172.16.x.x, и являются по отношению к сетям в датацентре внешними, это необходимо для эмуляции работы внутренних сетей с хостами в Интернет
- все приватные сети в датацентре начинаются с 172.20.x.x
В составе тестового стенда будут использованы следующие сети, с соответствующими идентификаторами VLAN:
- VLAN17 – сеть 172.20.1.0/24, приватные адреса для хостов в датацентре (IPMI, management)
- VLAN30 – сеть 172.16.1.0/24, «публичная» сеть, связь между VyOS1, VyOS2 и Provider-1
- VLAN31 – сеть 172.16.2.0/24, «публичная» сеть, связь между VyOS1, VyOS2 и Provider-2
- VLAN32 – сеть 172.20.32.0/23, приватные адреса для хостов в датацентре – PROD
- VLAN36 – сеть 172.16.10.8/30, «публичная» P2P сеть, связь между роутерами Provider-1 и Provider-3
- VLAN37 – сеть 172.16.10.12/30, «публичная» P2P сеть, связь между роутерами Provider-2 и Provider-3
- VLAN38 – сеть 172.16.3.0/24, «публичная» сеть для внешних хостов, эмуляция Интернет
- VLAN40 – сеть 172.20.40.0/23, приватные адреса для хостов в датацентре – TEST
В процессе развёртывания тестового стенда, нам придётся настраивать протокол BGP на роутерах Provider-1, Provider-2 и Provider-3, чтобы обеспечить связность между «публичными» сетями 172.16.1.0/24, 172.16.2.0/24 и 172.16.3.0/24
Задачи, которые сетевому администратору предстоит реализовать:
- обеспечить отказоустойчивое подключение к двум независимым провайдерам, для выхода в Интернет из внутренних сетей датацентра;
- все хосты в датацентре с адресами из приватных сетей, должны выходить в Интернет через NAT;
- выход из строя одного из маршрутизаторов VyOS, никак не должен сказываться на доступности хостов между внутренними сетями, и на доступность выхода в Интернет.
Подготовительные работы.
Перед развёртыванием проекта, необходимо создать 9 виртуальных машин в oVirt:
- VyOS – 2 шт., ОС – последний rolling release
- маршрутизаторы с пакетом Quagga – 3 шт., ОС – CentOS 7 x86/64 1810 Minimal (можно более свежую)
- клиентские ВМ – 4 шт., ОС – CentOS 7 x86/64 1810 Minimal (можно более свежую)
- test-17 – 1 Gb RAM, 1 CPU, 10 Gb HDD
- VLAN17, IP – 172.20.1.239/24, Gateway – 172.20.1.1
- test-IM32 – 1 Gb RAM, 1 CPU, 10 Gb HDD
- VLAN32, IP – 172.20.32.239/23, Gateway – 172.20.32.1
- test-IM40 – 1 Gb RAM, 1 CPU, 10 Gb HDD
- VLAN40, IP – 172.20.40.239/23, Gateway – 172.20.40.1
- test-public – 1 Gb RAM, 1 CPU, 10 Gb HDD,
- VLAN38, IP – 172.16.3.2/24, Gateway – 172.16.3.1
- PROVIDER-1 – 1 Gb RAM, 1 CPU, 10 Gb HDD
- VLAN30, IP – 172.16.1.1/24
- VLAN36, IP – 172.16.10.9/30
- PROVIDER-2 – 1 Gb RAM, 1 CPU, 10 Gb HDD
- VLAN31, IP – 172.16.2.1/24
- VLAN37, IP – 172.16.10.13/30
- PROVIDER-3 – 1 Gb RAM, 1 CPU, 10 Gb HDD
- VLAN36, IP – 172.16.10.10/30
- VLAN37, IP – 172.16.10.14/30
- VLAN38, IP – 172.16.3.1/24
- VyOS1 – 1 Gb RAM, 1 CPU, 10 Gb HDD
- eth0: VLAN17, IP – 172.20.1.253/24
- eth1: VLAN30, IP – 172.16.1.2/24
- eth2: VLAN31, IP – 172.16.2.3/24
- eth3: VLAN32, IP – 172.20.33.253/23
- eth4: VLAN40, IP – 172.20.40.253/23
- VyOS2 – 1 Gb RAM, 1 CPU, 10 Gb HDD
- eth0: VLAN17, IP – 172.20.1.254/24
- eth1: VLAN30, IP – 172.16.1.3/24
- eth2: VLAN31, IP – 172.16.2.2/24
- eth3: VLAN32, IP – 172.20.33.254/23
- eth4: VLAN40, IP – 172.20.40.254/23
Все необходимые идентификаторы VLAN были созданы на коммутаторах и назначены на соответствующие сетевые порты ещё в самой первой статье из цикла.
Из подготовительных работ, нужно ещё сделать следующее:
1) Создать все используемые выше логические сети в административном портале oVirt, а затем назначить их на хосты кластера.
Делаем всё по инструкциям из предыдущей статьи, а также по официальной документации. Результат этой работы можно посмотреть на скриншотах, настройки сети у обоих хостов кластера должны быть идентичны:
2) Установить ОС на виртуальные маршрутизаторы с пакетом Quagga, а также ОС на клиентские ВМ.
После подключения ВМ к соответствующим логическим сетям, устанавливаем на них ОС, и настраиваем IP адреса и шлюзы в соответствии со списком ВМ и со схемой сети.
Добавлять установочные образы с ОС и создавать виртуальные машины мы научились в предыдущей статье, поэтому особых затруднений этот процесс не должен вызвать.
Дальнейшая настройка этих виртуальных машин будет выполнена далее, по ходу статьи.
Начальная настройка маршрутизаторов VyOS.
Официальная документация по установке VyOS, FAQ.
Для установки маршрутизатора VyOs в качестве виртуальной машины под управлением oVirt:
- скачиваем ISO с самым последним rolling release по ссылке
- добавляем этот образ в oVirt
- создаём виртуальную машину и назначаем для неё логические сети
- назначаем первым загрузочным устройством установочный ISO образ с VyOS
- включаем ВМ и приступаем к установке.
После включения ВМ и загрузки с ISO, заходим в консоль ВМ и вводим команду для начала установки ОС:
vyos@vyos:~$ install image После завершения установки ОС, отсоединяем CD от ВМ, и перезагружаем её:
vyos@vyos:~$ rebootЛогин и пароль по умолчанию для входа в виртуальный маршрутизатор VyOS: vyos / vyos
После перезагрузки виртуального маршрутизатора, заходим в консоль роутера (из административного портала oVirt), и проверяем образ, с которого он загрузился, и с которым мы теперь будем работать.
vyos@VyOS1:~$ sh system image
The system currently has the following image(s) installed:
1: 1.2-rolling-201909060337 (default boot) (running image)
vyos@VyOS1:~$ show version
Version: VyOS 1.2-rolling-201909060337
Built by: autobuild@vyos.net
Built on: Fri 06 Sep 2019 03:37 UTC
Build UUID: 8b5401ba-b2eb-45d9-b267-1e3c5cfba6d7
Build Commit ID: ad4c3805b7b9af
Architecture: x86_64
Boot via: installed image
System type: KVM guest
Hardware vendor: oVirt
Hardware model: oVirt Node
Hardware S/N: 4c4c4544-004a-5010-804e-cac04f4e5232
Hardware UUID: 0f6dcc5e-b60b-4a47-81cc-6885339aa695
Copyright: VyOS maintainers and contributorsДля входа в режим конфигурирования роутера (по аналогии с «configure terminal» для устройств Cisco), вводим команду:
vyos@VyOS1:~$ configure
[edit]
vyos@VyOS1#Настройка сетевых интерфейсов и других параметров маршрутизатора, может производиться только в режим конфигурирования.
Команды для просмотра сетевых интерфейсов и их настроек:
show interfaces ethernet
show interfaces ethernet detail
show interfaces ethernet eth0Настройка сетевого интерфейса VLAN17:
set interfaces ethernet eth0 address '172.20.1.253/24'
set interfaces ethernet eth0 description 'VLAN17'Чтобы удалить IP адрес с интерфейса:
set delete interfaces ethernet eth0 address 172.20.1.253/24Настройка сетевого интерфейса VLAN30:
set interfaces ethernet eth1 address '172.16.1.2/24'
set interfaces ethernet eth1 description 'VLAN30'Настройка сетевого интерфейса VLAN31:
set interfaces ethernet eth2 address '172.16.2.3/24'
set interfaces ethernet eth2 description 'VLAN31'Настройка сетевого интерфейса VLAN32:
set interfaces ethernet eth3 address '172.20.33.253/23'
set interfaces ethernet eth3 description 'VLAN32'Настройка сетевого интерфейса VLAN40:
set interfaces ethernet eth4 address '172.20.40.253/23'
set interfaces ethernet eth4 description 'VLAN40'Настройка сетевого интерфейса VLAN17:
set interfaces ethernet eth0 address '172.20.1.254/24'
set interfaces ethernet eth0 description 'VLAN17'Настройка сетевого интерфейса VLAN30:
set interfaces ethernet eth1 address '172.16.1.3/24'
set interfaces ethernet eth1 description 'VLAN30'Настройка сетевого интерфейса VLAN31:
set interfaces ethernet eth2 address '172.16.2.2/24'
set interfaces ethernet eth2 description 'VLAN31'Настройка сетевого интерфейса VLAN32:
set interfaces ethernet eth3 address '172.20.33.254/23'
set interfaces ethernet eth3 description 'VLAN32'Настройка сетевого интерфейса VLAN40:
set interfaces ethernet eth4 address '172.20.40.254/23'
set interfaces ethernet eth4 description 'VLAN40'Включение SSH для удалённого управления маршрутизатором
set service ssh port 22Настройка DNS forwarder для разрешения внешних имён с роутера
set system name-server 1.1.1.1
set system name-server 8.8.8.8Настройка имени роутера и уровня логирования
set system host-name VyOS1
set system syslog global facility all level 'notice'Добавление ключа SSH для аутентификации пользователя на роутере
set system login user vyos authentication public-keys 'vyos' key "very_very_very_long_key"
set system login user vyos authentication public-keys 'vyos' type ssh-rsaНастройка ntp сервера и временной зоны
set system ntp server 0.pool.ntp.org
set system ntp server 1.pool.ntp.org
set system ntp server 2.pool.ntp.org
set system time-zone Europe/Moscow
dateУскорение медленной работы по SSH (если нет доступа к DNS серверам)
edit service ssh disable-host-validationДля сохранения всех сделанных изменений, выполняем команды
commit
saveДля отказа от всех сделанных изменений, выполняем команду
discardПриведённые выше настройки, являются минимально достаточными для начала работы с VyOS через SSH, с аутентификацией по паролю или SSH ключу.
Помимо этих базовых настроек, существует ещё множество других, которые могут пригодиться при дальнейшей работе с VyOS, например, для:
- настройки SNMP для мониторинга параметров маршрутизатора, к примеру, в небезызвестном Zabbix;
- настройки роутера для автоматической выгрузки на tftp сервер всех изменений в конфигурации, после каждого commit'а и мониторинга факта таких изменений в Zabbix;
- настройки резервного копирования конфигурационного файла VyOS на tftp сервер по расписанию;
- и т.п.
Все дополнительные настройки в рамках этой статьи описать нереально, так как потребуется ещё добавлять информацию о шаблонах и параметрах системы мониторинга Zabbix, поэтому их внедрение и использование может быть темой одной из будущих статей.
Настройка правил на файерволе.
Ссылка на документацию – Firewall.
VyOS использует для фильтрации сетевых пакетов netfilter.
Политика для файервола в VyOS может применяться двумя способами:
- политика, применяемая к интерфейсу (Per-Interface)
- политика зоны (Zone Policy).
В статье будет использоваться политика, применяемая к интерфейсу.
Политика для файервола управляется через наборы правил – это раздельные группы правил, пронумерованные от 1 до 9999. Правила выполняются последовательно, в соответствии с номером правила. Если трафик соответствует правилу, действие правила выполняется; если нет, то система переходит к следующему правилу.
Правила выполняют следующие действия:
- Accept – означает, что трафик разрешается
- Drop – означает, что трафик молча отбрасывается
- Reject – означает, что трафик отбрасывается с сообщением «ICMP Port Unreachable».
Наборы правил обычно применяются к интерфейсу, или к нескольким интерфейсам, в следующих направлениях:
- входящий трафик (или in)
Соответствует входящему интерфейсу цепочки FORWARD (netfilter), файервол фильтрует пакеты, которые входят в интерфейс и проходят через VyOS. Можно применить только один входной фильтр пакетов на интерфейс. - исходящий трафик (или out)
Соответствует исходящему интерфейсу цепочки FORWARD (netfilter), файервол фильтрует пакеты, которые покидают интерфейс. Это могут быть как пакеты, проходящие через VyOS, так и созданные на нём самом. Можно применить только один выходной фильтр пакетов на интерфейс. - локальный трафик (или local)
Соответствует цепочке INPUT (netfilter), т.е. трафик, который направляется на сам маршрутизатор VyOS, например, на 22 порт слушающий на его внешнем или внутреннем интерфейсе.
Пример настроек правил:
set firewall name OUTSIDE-IN default-action 'drop'
set firewall name OUTSIDE-IN rule 10 action 'allow'
set firewall name OUTSIDE-IN rule 10 state established 'enable'
set firewall name OUTSIDE-IN rule 10 state related 'enable'Строка 1 – создает политику файервола с именем «OUTSIDE-IN» для блокировки трафика по умолчанию.
Строка 2 – создает правило файервола (#10), которое разрешает трафик, соответствующий правилу.
Строка 3 – указывает, что правило применимо, когда существует установленный сеанс для трафика.
Строка 4 – указывает, что правило применимо, когда трафик относится к этому соединению.
Пример настройки файервола для блокировки трафика, направленного на сам маршрутизатор:
set firewall name OUTSIDE-LOCAL default-action 'drop'В этом примере весь трафик отбрасывается по умолчанию.
Пример применения правил для файервола к интерфейсам, в нужных направлениях:
set interfaces ethernet eth0 firewall in name 'OUTSIDE-IN'
set interfaces ethernet eth1 firewall local name 'OUTSIDE-LOCAL'Строка 1 – привязка политики файервола «OUTSIDE-IN» к интерфейсу eth0, для входящего трафика с внутренних адресов.
Строка 2 – привязка политики файервола «OUTSIDE-LOCAL» к интерфейсу eth1, для трафика, направляемого на сам маршрутизатор.
Настройка локальных правил файервола
Переходим к настройке локальных правил файервола (для трафика, направляемого на сам маршрутизатор).
Основные правила, которые будут использоваться:
- принимаем трафик, относящийся к установленному соединению (established, related), отбрасываем неправильный трафик
- Принимаем ICMP echo-request (ping)
- Принимаем запросы DHCP
- Принимаем запросы DNS
- Ограничиваем соединения по SSH до 4 в минуту на IP адрес и принимаем их только из определённых внутренних сетей (management)
- Принимаем подключения SNMP только из определённых внутренних сетей (management)
- Создаём групповые объекты с внутренними сетями
set firewall group network-group NET-VLAN17 network '172.20.1.0/24' set firewall group network-group NET-VLAN30 network '172.16.1.0/24' set firewall group network-group NET-VLAN31 network '172.16.2.0/24' set firewall group network-group NET-VLAN32 network '172.20.32.0/23' set firewall group network-group NET-VLAN38 network '172.16.3.0/24' set firewall group network-group NET-VLAN40 network '172.20.40.0/23' set firewall group network-group NET-MANAGEMENT network '172.20.32.0/23' set firewall group network-group NET-MANAGEMENT network '172.20.1.0/24' - Создаём именную локальную политику для каждой сети, или интерфейса, подключенного к маршрутизатору.
set firewall name LOCAL-VLAN30 default-action 'drop' set firewall name LOCAL-VLAN30 rule 1010 action 'accept' set firewall name LOCAL-VLAN30 rule 1010 state established 'enable' set firewall name LOCAL-VLAN30 rule 1010 state related 'enable' set firewall name LOCAL-VLAN30 rule 1011 action 'drop' set firewall name LOCAL-VLAN30 rule 1011 state invalid 'enable' set firewall name LOCAL-VLAN30 rule 1020 action 'accept' set firewall name LOCAL-VLAN30 rule 1020 icmp type-name 'echo-request' set firewall name LOCAL-VLAN30 rule 1020 protocol 'icmp' set firewall name LOCAL-VLAN30 rule 1020 state new 'enable' set firewall name LOCAL-VLAN30 rule 1030 action 'drop' set firewall name LOCAL-VLAN30 rule 1030 destination port '22' set firewall name LOCAL-VLAN30 rule 1030 protocol 'tcp' set firewall name LOCAL-VLAN30 rule 1030 recent count '4' set firewall name LOCAL-VLAN30 rule 1030 recent time '60' set firewall name LOCAL-VLAN30 rule 1030 source group network-group 'NET-MANAGEMENT' set firewall name LOCAL-VLAN30 rule 1030 state new 'enable' set firewall name LOCAL-VLAN30 rule 1040 action 'accept' set firewall name LOCAL-VLAN30 rule 1040 destination port '22' set firewall name LOCAL-VLAN30 rule 1040 protocol 'tcp' set firewall name LOCAL-VLAN30 rule 1040 source group network-group 'NET-MANAGEMENT' set firewall name LOCAL-VLAN30 rule 1040 state new 'enable'
set firewall name LOCAL-VLAN31 default-action 'drop' set firewall name LOCAL-VLAN31 rule 1010 action 'accept' set firewall name LOCAL-VLAN31 rule 1010 state established 'enable' set firewall name LOCAL-VLAN31 rule 1010 state related 'enable' set firewall name LOCAL-VLAN31 rule 1011 action 'drop' set firewall name LOCAL-VLAN31 rule 1011 state invalid 'enable' set firewall name LOCAL-VLAN31 rule 1020 action 'accept' set firewall name LOCAL-VLAN31 rule 1020 icmp type-name 'echo-request' set firewall name LOCAL-VLAN31 rule 1020 protocol 'icmp' set firewall name LOCAL-VLAN31 rule 1020 state new 'enable' set firewall name LOCAL-VLAN31 rule 1030 action 'drop' set firewall name LOCAL-VLAN31 rule 1030 destination port '22' set firewall name LOCAL-VLAN31 rule 1030 protocol 'tcp' set firewall name LOCAL-VLAN31 rule 1030 recent count '4' set firewall name LOCAL-VLAN31 rule 1030 recent time '60' set firewall name LOCAL-VLAN31 rule 1030 source group network-group 'NET-MANAGEMENT' set firewall name LOCAL-VLAN31 rule 1030 state new 'enable' set firewall name LOCAL-VLAN31 rule 1040 action 'accept' set firewall name LOCAL-VLAN31 rule 1040 destination port '22' set firewall name LOCAL-VLAN31 rule 1040 protocol 'tcp' set firewall name LOCAL-VLAN31 rule 1040 source group network-group 'NET-MANAGEMENT' set firewall name LOCAL-VLAN31 rule 1040 state new 'enable'
set firewall name LOCAL-VLAN17 default-action 'drop' set firewall name LOCAL-VLAN17 rule 1001 action 'accept' set firewall name LOCAL-VLAN17 rule 1001 source group network-group 'NET-MANAGEMENT' set firewall name LOCAL-VLAN17 rule 1010 action 'accept' set firewall name LOCAL-VLAN17 rule 1010 state established 'enable' set firewall name LOCAL-VLAN17 rule 1010 state related 'enable' set firewall name LOCAL-VLAN17 rule 1011 action 'drop' set firewall name LOCAL-VLAN17 rule 1011 state invalid 'enable' set firewall name LOCAL-VLAN17 rule 1020 action 'accept' set firewall name LOCAL-VLAN17 rule 1020 icmp type-name 'echo-request' set firewall name LOCAL-VLAN17 rule 1020 protocol 'icmp' set firewall name LOCAL-VLAN17 rule 1020 state new 'enable' set firewall name LOCAL-VLAN17 rule 1040 action 'accept' set firewall name LOCAL-VLAN17 rule 1040 destination port '53' set firewall name LOCAL-VLAN17 rule 1040 protocol 'tcp_udp' set firewall name LOCAL-VLAN17 rule 1040 state new 'enable' set firewall name LOCAL-VLAN17 rule 1100 action 'drop' set firewall name LOCAL-VLAN17 rule 1100 destination port '22' set firewall name LOCAL-VLAN17 rule 1100 protocol 'tcp' set firewall name LOCAL-VLAN17 rule 1100 recent count '4' set firewall name LOCAL-VLAN17 rule 1100 recent time '60' set firewall name LOCAL-VLAN17 rule 1100 source group network-group 'NET-MANAGEMENT' set firewall name LOCAL-VLAN17 rule 1100 state new 'enable' set firewall name LOCAL-VLAN17 rule 1101 action 'accept' set firewall name LOCAL-VLAN17 rule 1101 destination port '22' set firewall name LOCAL-VLAN17 rule 1101 protocol 'tcp' set firewall name LOCAL-VLAN17 rule 1101 source group network-group 'NET-MANAGEMENT' set firewall name LOCAL-VLAN17 rule 1101 state new 'enable' set firewall name LOCAL-VLAN17 rule 1110 action 'accept' set firewall name LOCAL-VLAN17 rule 1110 destination port '161' set firewall name LOCAL-VLAN17 rule 1110 protocol 'udp' set firewall name LOCAL-VLAN17 rule 1110 source group network-group 'NET-MANAGEMENT' set firewall name LOCAL-VLAN17 rule 1110 state new 'enable'
set firewall name LOCAL-VLAN32 default-action 'drop' set firewall name LOCAL-VLAN32 rule 1010 action 'accept' set firewall name LOCAL-VLAN32 rule 1010 state established 'enable' set firewall name LOCAL-VLAN32 rule 1010 state related 'enable' set firewall name LOCAL-VLAN32 rule 1011 action 'drop' set firewall name LOCAL-VLAN32 rule 1011 state invalid 'enable' set firewall name LOCAL-VLAN32 rule 1020 action 'accept' set firewall name LOCAL-VLAN32 rule 1020 icmp type-name 'echo-request' set firewall name LOCAL-VLAN32 rule 1020 protocol 'icmp' set firewall name LOCAL-VLAN32 rule 1020 state new 'enable' set firewall name LOCAL-VLAN32 rule 1030 action 'accept' set firewall name LOCAL-VLAN32 rule 1030 destination port '67' set firewall name LOCAL-VLAN32 rule 1030 protocol 'udp' set firewall name LOCAL-VLAN32 rule 1030 state new 'enable' set firewall name LOCAL-VLAN32 rule 1040 action 'accept' set firewall name LOCAL-VLAN32 rule 1040 destination port '53' set firewall name LOCAL-VLAN32 rule 1040 protocol 'tcp_udp' set firewall name LOCAL-VLAN32 rule 1040 state new 'enable' set firewall name LOCAL-VLAN32 rule 1100 action 'drop' set firewall name LOCAL-VLAN32 rule 1100 destination port '22' set firewall name LOCAL-VLAN32 rule 1100 protocol 'tcp' set firewall name LOCAL-VLAN32 rule 1100 recent count '4' set firewall name LOCAL-VLAN32 rule 1100 recent time '60' set firewall name LOCAL-VLAN32 rule 1100 source group network-group 'NET-MANAGEMENT' set firewall name LOCAL-VLAN32 rule 1100 state new 'enable' set firewall name LOCAL-VLAN32 rule 1101 action 'accept' set firewall name LOCAL-VLAN32 rule 1101 destination port '22' set firewall name LOCAL-VLAN32 rule 1101 protocol 'tcp' set firewall name LOCAL-VLAN32 rule 1101 source group network-group 'NET-MANAGEMENT' set firewall name LOCAL-VLAN32 rule 1101 state new 'enable' set firewall name LOCAL-VLAN32 rule 1110 action 'accept' set firewall name LOCAL-VLAN32 rule 1110 destination port '161' set firewall name LOCAL-VLAN32 rule 1110 protocol 'udp' set firewall name LOCAL-VLAN32 rule 1110 source group network-group 'NET-MANAGEMENT' set firewall name LOCAL-VLAN32 rule 1110 state new 'enable'
set firewall name LOCAL-VLAN40 default-action 'drop' set firewall name LOCAL-VLAN40 rule 1001 action 'accept' set firewall name LOCAL-VLAN40 rule 1001 source group network-group 'NET-MANAGEMENT' set firewall name LOCAL-VLAN40 rule 1010 action 'accept' set firewall name LOCAL-VLAN40 rule 1010 state established 'enable' set firewall name LOCAL-VLAN40 rule 1010 state related 'enable' set firewall name LOCAL-VLAN40 rule 1011 action 'drop' set firewall name LOCAL-VLAN40 rule 1011 state invalid 'enable' set firewall name LOCAL-VLAN40 rule 1020 action 'accept' set firewall name LOCAL-VLAN40 rule 1020 icmp type-name 'echo-request' set firewall name LOCAL-VLAN40 rule 1020 protocol 'icmp' set firewall name LOCAL-VLAN40 rule 1020 state new 'enable' - Применяем локальную политику к интерфейсам на VyOS1 и VyOS2
set interfaces ethernet eth0 firewall local name 'LOCAL-VLAN17' set interfaces ethernet eth1 firewall local name 'LOCAL-VLAN30' set interfaces ethernet eth2 firewall local name 'LOCAL-VLAN31' set interfaces ethernet eth3 firewall local name 'LOCAL-VLAN32' set interfaces ethernet eth4 firewall local name 'LOCAL-VLAN40'
Настройка правил файервола между защищаемыми внутренними сетями
Создаём политику для входящего трафика из сетей VLAN32 и VLAN17 – политика, которая устанавливается для трафика, который входит на интерфейс из локальной сети, защищаемой файерволом, с последующим его транзитом к другим сетям (снаружи, или защищаемым этим же файерволом).
С целью упрощения конфигурации тестового стенда и диагностики сети, политики для сетей VLAN30, VLAN31 и VLAN40 настраивать не будем, но можете создать правила для них самостоятельно.
Помните, что в производственной среде, отсутствие политики файервола на внешнем интерфейсе недопустимо!
Важное примечание
Все наборы политик для файервола, описанные в этой статье, даны для случаев обычной маршрутизации. Для случаев асимметричной маршрутизации (asymmetric routing), правила будут выглядеть немного по-другому, без поддержки SPI (stateful packet inspection).
- Создаём политики для входящего трафика из сетей VLAN32 и VLAN17 к другим сетям
set firewall name VLAN32-IN default-action 'drop' set firewall name VLAN32-IN rule 1010 action 'accept' set firewall name VLAN32-IN rule 1010 state established 'enable' set firewall name VLAN32-IN rule 1010 state related 'enable' set firewall name VLAN32-IN rule 1011 action 'drop' set firewall name VLAN32-IN rule 1011 state invalid 'enable' set firewall name VLAN32-IN rule 9000 action 'accept' set firewall name VLAN32-IN rule 9000 source group network-group 'NET-VLAN32' set firewall name VLAN32-IN rule 9000 state new 'enable'
set firewall name VLAN17-IN default-action 'drop' set firewall name VLAN17-IN rule 1010 action 'accept' set firewall name VLAN17-IN rule 1010 state established 'enable' set firewall name VLAN17-IN rule 1010 state related 'enable' set firewall name VLAN17-IN rule 1011 action 'drop' set firewall name VLAN17-IN rule 1011 state invalid 'enable' set firewall name VLAN17-IN rule 9000 action 'accept' set firewall name VLAN17-IN rule 9000 source group network-group 'NET-VLAN17' set firewall name VLAN17-IN rule 9000 state new 'enable' - Применяем политики для входящего трафика, к соответствующим интерфейсам
set interfaces ethernet eth0 firewall in name 'VLAN17-IN' set interfaces ethernet eth2 firewall in name 'VLAN32-IN' - Создаём политики для исходящего трафика из других сетей, к сетям VLAN32 и VLAN17, т.е. выходящего из интерфейса файервола в защищаемую локальную сеть.
set firewall name VLAN32-OUT default-action 'drop' set firewall name VLAN32-OUT rule 1010 action 'accept' set firewall name VLAN32-OUT rule 1010 state established 'enable' set firewall name VLAN32-OUT rule 1010 state related 'enable' set firewall name VLAN32-OUT rule 1011 action 'drop' set firewall name VLAN32-OUT rule 1011 state invalid 'enable' set firewall name VLAN32-OUT rule 1020 action 'accept' set firewall name VLAN32-OUT rule 1020 icmp type-name 'echo-request' set firewall name VLAN32-OUT rule 1020 protocol 'icmp' set firewall name VLAN32-OUT rule 1020 state new 'enable' set firewall name VLAN32-OUT rule 1100 action 'accept' set firewall name VLAN32-OUT rule 1100 source group network-group 'NET-VLAN40' set firewall name VLAN32-OUT rule 1100 state new 'enable' set firewall name VLAN32-OUT rule 1110 action 'accept' set firewall name VLAN32-OUT rule 1110 source group network-group 'NET-VLAN17' set firewall name VLAN32-OUT rule 1110 state new 'enable' set firewall name VLAN32-OUT rule 1120 action 'accept' set firewall name VLAN32-OUT rule 1120 source group network-group 'NET-VLAN30' set firewall name VLAN32-OUT rule 1120 state new 'enable' set firewall name VLAN32-OUT rule 1130 action 'accept' set firewall name VLAN32-OUT rule 1130 source group network-group 'NET-VLAN31' set firewall name VLAN32-OUT rule 1130 state new 'enable' set firewall name VLAN32-OUT rule 1140 action 'accept' set firewall name VLAN32-OUT rule 1140 source group network-group 'NET-VLAN38' set firewall name VLAN32-OUT rule 1140 state new 'enable'
set firewall name VLAN17-OUT default-action 'drop' set firewall name VLAN17-OUT rule 1010 action 'accept' set firewall name VLAN17-OUT rule 1010 state established 'enable' set firewall name VLAN17-OUT rule 1010 state related 'enable' set firewall name VLAN17-OUT rule 1011 action 'drop' set firewall name VLAN17-OUT rule 1011 state invalid 'enable' set firewall name VLAN17-OUT rule 1020 action 'accept' set firewall name VLAN17-OUT rule 1020 icmp type-name 'echo-request' set firewall name VLAN17-OUT rule 1020 protocol 'icmp' set firewall name VLAN17-OUT rule 1020 state new 'enable' set firewall name VLAN17-OUT rule 1100 action 'accept' set firewall name VLAN17-OUT rule 1100 source group network-group 'NET-VLAN32' set firewall name VLAN17-OUT rule 1100 state new 'enable' - Применяем политики для исходящего трафика, к соответствующим интерфейсам
set interfaces ethernet eth0 firewall out name 'VLAN17-OUT' set interfaces ethernet eth3 firewall out name 'VLAN32-OUT'
Не забываем, что после создания политик, и их применения к интерфейсам, нужно сделать commit и save.
- включаем логирование по snmp изменений в конфигурации файервола
set firewall config-trap 'enable' - логируем трафик, который доходит до правила по умолчанию для именованной политики (в нашем случае это default drop)
set firewall name VLAN17-IN 'enable-default-log' set firewall name VLAN17-OUT 'enable-default-log' set firewall name VLAN32-IN 'enable-default-log' set firewall name VLAN32-OUT 'enable-default-log' - пример, как это работает, когда нужно поймать отбрасываемый трафик:
set firewall name VLAN17-LOCAL 'enable-default-log' commit exit show log firewall name VLAN17-LOCAL configure delete firewall name VLAN17-LOCAL 'enable-default-log' commit - включаем глобальные настройки файервола, обычно настроенные по умолчанию
set firewall all-ping 'enable' set firewall broadcast-ping 'disable' set firewall config-trap 'disable' set firewall log-martians 'enable' set firewall receive-redirects 'disable' set firewall source-validation 'disable' set firewall syn-cookies 'enable' set firewall send-redirects 'enable' set firewall ipv6-receive-redirects 'disable' set firewall ipv6-src-route 'disable' set firewall ip-src-route 'disable'
Настройка vrrp для отказоустойчивой маршрутизации
Ссылка на документацию – High availability (VRRP).
После выполнения базовых настроек маршрутизаторов VyOS, перейдём к настройке отказоустойчивой связи между хостами во внутренних сетях и их шлюзами по умолчанию.
Достигается это с помощью протокола vrrp, настраиваемого на обоих маршрутизаторах, в результате чего появляется виртуальный высокодоступный IP адрес — HAIP (Highly Available IP), являющийся шлюзом по умолчанию для внутренней сети. Этот адрес активируется на ведущем роутере, и через него идёт обмен трафиком между подключенной к нему какой-либо внутренней сетью, с остальными внутренними или внешними сетями. В случае сбоя ведущего роутера, этот HAIP автоматически переключается на ведомый (резервный) роутер, и трафик начинает идти через него.
Если вы когда-либо использовали HAIP, настраиваемый в keepalived, то это практически тоже самое, но ещё интересным и полезным может отказаться тот факт, что такая связка вполне работает между VyOS и обычным хостом с Linux, на котором настроен HAIP и keepalived (конечно же с идентичными настройками). Такая возможность может пригодиться при каких-то миграциях, или при отладке конфигурации на роутере или другом устройстве.
Для более глубокого погружения в детали настроек vrrp, рекомендуется статья от IBM, она относится к виртуальному маршрутизатору Vyatta 5600 от Brocade, но нам подойдёт, так как корни VyOS растут из проекта Vyatta (который в 2012 году был перекуплен Brocade).
VLAN17, HA VIP – 172.20.1.1/24
Ведущий хост – 172.20.1.253/24
Резервный хост – 172.20.1.254/24VLAN32, HA VIP – 172.20.32.1/23
Ведущий хост – 172.20.33.253/23
Резервный хост – 172.20.33.254/23VLAN40, HA VIP – 172.20.40.1/23
Ведущий хост – 172.20.40.253/23
Резервный хост – 172.20.40.254/23set firewall name LOCAL-VLAN32 rule 1120 action 'accept'
set firewall name LOCAL-VLAN32 rule 1120 protocol 'vrrp'
set firewall name LOCAL-VLAN17 rule 1120 action 'accept'
set firewall name LOCAL-VLAN17 rule 1120 protocol 'vrrp'
set firewall name LOCAL-VLAN40 rule 1030 action 'accept'
set firewall name LOCAL-VLAN40 rule 1030 protocol 'vrrp'set high-availability vrrp group haip-1 vrid 17
set high-availability vrrp group haip-1 interface eth0
set high-availability vrrp group haip-1 virtual-address 172.20.1.1/24
set high-availability vrrp group haip-1 priority '200'
set high-availability vrrp group haip-1 authentication type 'plaintext-password'
set high-availability vrrp group haip-1 authentication password 'b65495f9'
set high-availability vrrp group haip-1 preempt 2
set high-availability vrrp group haip-1 advertise-interval '1'
set high-availability vrrp group haip-2 vrid 32
set high-availability vrrp group haip-2 interface eth3
set high-availability vrrp group haip-2 virtual-address 172.20.32.1/23
set high-availability vrrp group haip-2 priority '200'
set high-availability vrrp group haip-2 authentication type 'plaintext-password'
set high-availability vrrp group haip-2 authentication password 'b65495f9'
set high-availability vrrp group haip-2 preempt 2
set high-availability vrrp group haip-2 advertise-interval '1'
set high-availability vrrp group haip-3 vrid 40
set high-availability vrrp group haip-3 interface eth4
set high-availability vrrp group haip-3 virtual-address 172.20.40.1/23
set high-availability vrrp group haip-3 priority '200'
set high-availability vrrp group haip-3 authentication type 'plaintext-password'
set high-availability vrrp group haip-3 authentication password 'b65495f9'
set high-availability vrrp group haip-3 preempt 2
set high-availability vrrp group haip-3 advertise-interval '1'
commitset high-availability vrrp group haip-1 vrid 17
set high-availability vrrp group haip-1 interface eth0
set high-availability vrrp group haip-1 virtual-address 172.20.1.1/24
set high-availability vrrp group haip-1 priority '199'
set high-availability vrrp group haip-1 authentication type 'plaintext-password'
set high-availability vrrp group haip-1 authentication password 'b65495f9'
set high-availability vrrp group haip-1 preempt 2
set high-availability vrrp group haip-1 advertise-interval '1'
set high-availability vrrp group haip-2 vrid 32
set high-availability vrrp group haip-2 interface eth3
set high-availability vrrp group haip-2 virtual-address 172.20.32.1/23
set high-availability vrrp group haip-2 priority '199'
set high-availability vrrp group haip-2 authentication type 'plaintext-password'
set high-availability vrrp group haip-2 authentication password 'b65495f9'
set high-availability vrrp group haip-2 preempt 2
set high-availability vrrp group haip-2 advertise-interval '1'
set high-availability vrrp group haip-3 vrid 40
set high-availability vrrp group haip-3 interface eth4
set high-availability vrrp group haip-3 virtual-address 172.20.40.1/23
set high-availability vrrp group haip-3 priority '199'
set high-availability vrrp group haip-3 authentication type 'plaintext-password'
set high-availability vrrp group haip-3 authentication password 'b65495f9'
set high-availability vrrp group haip-3 preempt 2
set high-availability vrrp group haip-3 advertise-interval '1'
commitКоманды для просмотра информации о работе vrrp:
run show vrrp statistics
run show vrrp detail
run show log allvyos@VyOS1# run show vrrp
Name Interface VRID State Last Transition
------ ----------- ------ ------- -----------------
haip-1 eth0 17 MASTER 13m48s
haip-2 eth3 32 MASTER 13m48s
haip-3 eth4 40 MASTER 13m48s
vyos@VyOS2# run show vrrp
Name Interface VRID State Last Transition
------ ----------- ------ ------- -----------------
haip-1 eth0 17 BACKUP 11m26s
haip-2 eth3 32 BACKUP 11m27s
haip-3 eth4 40 BACKUP 5m17s- на роутере VyOS1
set high-availability vrrp group haip-1 disable set high-availability vrrp group haip-2 disable set high-availability vrrp group haip-3 disable commit run show vrrp - проверяем видимость тестовых хостов test-17, test-IM3 и test-IM40 друг с друга, на них шлюзом должен быть настроен соответствующий HAIP:
ping 172.20.32.239 ping 172.20.1.239 ping 172.20.40.239 - после всех проверок, на роутере VyOS1 включаем vrrp обратно:
delete high-availability vrrp group haip-1 disable delete high-availability vrrp group haip-2 disable delete high-availability vrrp group haip-3 disable commit run show vrrp
Настройка выхода в Интернет через двух провайдеров.
Официальная документация – WAN load balancing.
Балансировка исходящего трафика из датацентра к внешним сетям (в Интернет), может производиться между двумя и более внешними интерфейсами, понятно, что для этого датацентр должен быть подключен как минимум к двум независимым провайдерам.
В случае потери доступа к кому-либо из провайдеров, происходит балансировка трафика между оставшимися рабочими линиями связи, а после восстановления работоспособности канала, ранее сбоивший маршрут автоматически добавляется обратно в таблицу маршрутизации, для его дальнейшего использования балансировщиком. Балансировщик автоматически добавляет маршруты для каждого внешнего интерфейса в таблицу маршрутизации и балансирует трафик между ними, в зависимости от их состояния и веса.
Наша задача состоит в том, чтобы обеспечить выход в Интернет одновременно через двух провайдеров (балансировку нагрузки), для хостов из внутренних сетей: VLAN17, VLAN32 и VLAN40.
Установку и настройку IP адресов на «внешних» (провайдерских) роутерах, мы должны были выполнить ещё в самом начале, сейчас нам нужно будет настроить между ними маршрутизацию с помощью протокола BGPv4 и сервиса bgpd, являющегося составной частью пакета Quagga.
Установка пакета Quagga делается относительно просто, а управление ею производится через CLI, вызываемый командой vtysh. Сам CLI довольно простой, и если сетевой администратор уже знаком с маршрутизаторами Cisco, то никаких проблем он не вызовет.
Безусловно, правильнее было бы на «внешних» (провайдерских) роутерах тоже установить VyOS и настраивать BGP на них, но целью статьи это не является, чтобы не перегружать читателей лишней информацией. Показать, как на VyOS настраивается BGP и политики маршрутизации, это возможная тема одной из следующих статей, поэтому в целях экономии времени и упрощения настройки тестового стенда, используется самый обычный CentOS и Quagga.
- Установка пакета Quagga:
yum install -y quagga systemctl enable zebra && systemctl start zebra && systemctl status zebra cp /usr/share/doc/quagga-0.99.22.4/bgpd.conf.sample /etc/quagga/bgpd.conf systemctl start bgpd && systemctl enable bgpd && systemctl status bgpd chmod -R 777 /etc/quagga/ vtysh show running-config config t - Настройка BGP на маршрутизаторе Provider-1
Provider-1# sh running-config Building configuration... Current configuration: ! hostname Provider-1 log file /var/log/quagga/quagga.log hostname bgpd log stdout ! password zebra ! interface eth0 ipv6 nd suppress-ra ! interface eth1 ipv6 nd suppress-ra ! interface lo ! router bgp 65860 bgp router-id 172.16.10.9 network 172.16.1.0/24 neighbor 172.16.10.10 remote-as 65880 neighbor 172.16.10.10 description "Provider-3" neighbor 172.16.10.10 timers 30 90 neighbor 172.16.10.10 soft-reconfiguration inbound ! ip forwarding ! line vty ! end - Настройка BGP на маршрутизаторе Provider-2
Provider-2# sh running-config Building configuration... Current configuration: ! hostname Provider-2 log file /var/log/quagga/quagga.log hostname bgpd log stdout ! password zebra ! interface eth0 ipv6 nd suppress-ra ! interface eth1 ipv6 nd suppress-ra ! interface lo ! router bgp 65870 bgp router-id 172.16.10.13 network 172.16.2.0/24 neighbor 172.16.10.14 remote-as 65880 neighbor 172.16.10.14 description "Provider-3" neighbor 172.16.10.14 timers 30 90 neighbor 172.16.10.14 soft-reconfiguration inbound ! ip forwarding ! line vty ! end - Настройка BGP на маршрутизаторе Provider-3
Provider-3# sh running-config Building configuration... Current configuration: ! hostname Provider-3 log file /var/log/quagga/quagga.log hostname bgpd log stdout ! password zebra ! interface eth0 ipv6 nd suppress-ra ! interface eth1 ipv6 nd suppress-ra ! interface eth2 ipv6 nd suppress-ra ! interface lo ! router bgp 65880 bgp router-id 172.16.3.1 network 172.16.3.0/24 neighbor 172.16.10.9 remote-as 65860 neighbor 172.16.10.9 description "Provider-1" neighbor 172.16.10.9 timers 30 90 neighbor 172.16.10.9 soft-reconfiguration inbound neighbor 172.16.10.13 remote-as 65870 neighbor 172.16.10.13 description "Provider-2" neighbor 172.16.10.13 timers 30 90 neighbor 172.16.10.13 soft-reconfiguration inbound ! ip forwarding ! line vty ! end
После настройки BGP, не забываем также про настройку iptables на «внешних» маршрутизаторах, если это необходимо.
Если всё было сделано правильно, то таблица маршрутизации на Provider-3 должна выглядеть так:
[root@Provider-3 ~]# ip route
169.254.0.0/16 dev eth0 scope link metric 1002
169.254.0.0/16 dev eth1 scope link metric 1003
169.254.0.0/16 dev eth2 scope link metric 1004
172.16.1.0/24 via 172.16.10.9 dev eth0 proto zebra
172.16.2.0/24 via 172.16.10.13 dev eth1 proto zebra
172.16.3.0/24 dev eth2 proto kernel scope link src 172.16.3.1
172.16.10.8/30 dev eth0 proto kernel scope link src 172.16.10.10
172.16.10.12/30 dev eth1 proto kernel scope link src 172.16.10.14То есть мы должны получать на этот роутер анонсы по BGP о сетях 172.16.1.0/24 и 172.16.2.0/24, и маршруты к ним должны присутствовать в таблице маршрутизации.
Соответственно, на маршрутизаторах Provider-1 и Provider-2, маршрут к сети 172.16.3.0/24 также должен находиться в таблице маршрутизации.
- настраиваем правила балансировки исходящего трафика между роутерами Provider-1 и Provider-2:
set protocols static route 0.0.0.0/0 next-hop 172.16.1.1 set protocols static route 0.0.0.0/0 next-hop 172.16.2.1 set load-balancing wan interface-health eth1 failure-count 3 set load-balancing wan interface-health eth1 nexthop 172.16.1.1 set load-balancing wan interface-health eth1 test 10 type ping set load-balancing wan interface-health eth1 test 10 target 172.16.3.1 set load-balancing wan interface-health eth2 failure-count 3 set load-balancing wan interface-health eth2 nexthop 172.16.2.1 set load-balancing wan interface-health eth2 test 10 type ping set load-balancing wan interface-health eth2 test 10 target 172.16.3.1 - исключаем трафик к внутренним сетям из балансировки трафика:
set load-balancing wan rule 10 inbound-interface eth+ set load-balancing wan rule 10 destination address 172.20.40.0/23 set load-balancing wan rule 10 exclude set load-balancing wan rule 20 inbound-interface eth+ set load-balancing wan rule 20 destination address 172.20.32.0/23 set load-balancing wan rule 20 exclude set load-balancing wan rule 30 inbound-interface eth+ set load-balancing wan rule 30 destination address 172.20.1.0/24 set load-balancing wan rule 30 exclude - применяем балансировку нагрузки для трафика из внутренних сетей в Интернет, на внешних сетевых интерфейсах:
set load-balancing wan rule 1000 inbound-interface eth0 set load-balancing wan rule 1000 interface eth1 set load-balancing wan rule 1000 interface eth2 set load-balancing wan rule 1010 inbound-interface eth3 set load-balancing wan rule 1010 interface eth1 set load-balancing wan rule 1010 interface eth2 set load-balancing wan rule 1020 inbound-interface eth3 set load-balancing wan rule 1020 interface eth1 set load-balancing wan rule 1020 interface eth2 commit
Примечание:
eth+ используется как алиас (или псевдоним), который относится ко всем сетевым интерфейсам.
Проверка работы балансировки нагрузки:
show wan-load-balance
show wan-load-balance connectionПерезагрузка балансировщика:
restart wan-load-balanceТестирование работы внутренней маршрутизации и выхода в Интернет, при различных условиях
- Всё включено и настроено
- Отключение интерфейса VLAN30 на роутере Provider-1
- Отключение сервиса bgpd на роутере Provider-1
- Отключение интерфейса VLAN31 на роутере Provider-2
- Отключение сервиса bgpd на роутере Provider-2
- Выключение роутера VyOS1
- Включение роутера VyOS1
- Выключение роутера VyOS2
- Включение роутера VyOS2
Во время тестирования каждого пункта, указанного выше, обычно проверяется:
- прохождение ping и traceroute к внешнему хосту в Интернете,
- прохождение ping и traceroute между хостами во внутренних сетях,
- дополнительно рекомендовал бы ещё проверять доступность хостов по ssh и, например, по http.
Для балансировки нагрузки можно задавать и другие параметры – вес и ограничение пропускной способности для канала, а также различные проверки для определения доступности внешнего канала. Можно самостоятельно разобраться с этими настройками, и даже протестировать как они работают – не зря же мы строили наш тестовый стенд.
Публикация в Интернет внутренних ресурсов через NAT, специально не рассматривалась, чтобы читатель имел возможность самостоятельно выполнить такую настройку, благо вся подготовительная работа для этого сделана (не забываем только про настройку политик файервола).
Также вполне может иметь место вариант, когда кто-либо из провайдеров, или даже оба провайдера, выдали не по два публичных адреса, а по одной подсети каждый, например, c префиксами /27.
В этом случае, чтобы иметь возможность выхода с хоста с двумя публичными адресами от двух разных провайдеров в Интернет, а также для подключения из Интернета к его публичным адресам, на нём необходимо будет настроить PBR (policy-based routing) и multipath routing. Впрочем, это уже тема для другой статьи (не разбирайте тестовый стенд, может ещё пригодится :)).
Заключение
В этой статье мы вкратце рассмотрели настройку виртуальных маршрутизаторов VyOS, и довольно часто встречающийся вариант выхода в Интернет через двух независимых провайдеров – в принципе, без надёжной связи, датацентр со всей инфраструктурой в нём, не может считаться отказоустойчивым.
В частном случае, если необходима публикация большого числа каких-то внутренних ресурсов в Интернет, то можно рассмотреть аренду у какого-либо провайдера блока публичных IP адресов с префиксом не меньше /24, и анонсирование их по протоколу BGP через двух независимых провайдеров.
Такой вариант подключения нашего датацентра к Интернет может быть даже более интересным и предпочтительным, чем описанная в этой статье балансировка нагрузки на внешних каналах, так как позволяет организации в дальнейшем подключить второй датацентр с использованием публичных адресов из уже имеющегося блока адресов. Второй датацентр конечно же повысит не только отказоустойчивость, но и катастрофоустойчивость всего проекта в целом, понятно что нужно будет выполнять доработку проекта, но это уже другая история.
С формальной точки зрения, цикл статей о создании отказоустойчивой ИТ инфраструктуры можно было бы и закончить, так как все задачи, которые стояли перед нами в самом начале, были успешно выполнены:
- всё железо настроено и подключено к сети и СХД;
- настроен кластер oVirt;
- настроена внутренняя маршрутизация и выход в Интернет.
Обычно ко времени начала развёртывания аппаратной инфраструктуры, разработчики уже должны иметь как минимум черновой вариант веб-проекта, который вероятно уже тестировался где-то в облаке. Так что пришло время начать развёртывать виртуальные машины, устанавливать на него ПО и настраивать публикацию ресурсов наружу.
Конечно, у нормального администратора неизменно возникнут вопросы про мониторинг и резервное копирование всего нашего хозяйства… В этом цикле статей такие вопросы не поднимались, но наверняка в будущих статьях мы к ним ещё вернёмся. Необходимо сразу отметить, что всем известный Veeam – НЕ поддерживает резервное копирование oVirt/RHEV и вообще виртуальных машин KVM, от слова никак, поэтому придётся использовать или другие коммерческие решения, или «ваять» что-то своё, или «допиливать» какие-то уже имеющиеся OpenSource решения, найденные на просторах Интернета.
Ну а что касается мониторинга железа и виртуальных машин, то тут дело вкуса и личных предпочтений, обычно на проектах используется Zabbix – бесплатное и довольно надёжное решение, с массой доступных шаблонов на любой вкус и цвет.
Но, впрочем, вернёмся обратно к нашей инфраструктуре – напомню, что в первой статье в составе железа была указана пара замечательных коммутаторов Cisco 3850, и было бы очень странно не использовать их по прямому предназначению – скоростной маршрутизации трафика между сетями. Поэтому в следующей статье мы и рассмотрим их интеграцию в нашу инфраструктуру, так как работа для них обязательно найдётся.
oller
Отсутствие специалистов на рынке по этому решению делают серьезные опасения по внедрению
документация обширна, но 24*7 уже стремновато…
А так очень красивое решение
BNKT0P Автор
Спасибо за комментарий, самое главное — решение рабочее :) и работает 24x7x365
VyOS используются давно, и полностью удовлетворяют всем требованиям, а главное надёжны и предсказуемы.
Что касается специалистов… Поверьте, порог вхождения не очень высок, особенно если человек уже работал с Juniper, или даже Cisco. Единственный недостаток, если с точки зрения не слишком сетевого админа, то это отсутствие GUI, но то в общем такое…
igrblkv
Насколько я помню, изначально Vyatta была попыткой написания софтового аналога JunOS. При этом в качестве базы используется не FreeBSD, как в JunOS, а Debian.
Так-же компания Ubiquiti написала свой веб-интерфейс и назвала это всё EdgeOS для использования в своих маршрутизаторах серии EdgeRouter.
Потом Vyatta Inc. купила компания Brocade и использовала как основу для исключительно коммерческого продукта Brocade Vyatta Network OS.
VyOS является форком с открытыми исходниками последнего издания Vyatta Routing Community Edition…
Таким образом, я-бы не сказал, что на рынке нет специалистов. Juniper и Ubiquiti вполне распространённые решения в определенных кругах…
BNKT0P Автор
Совершенно верно, если работал с каким-либо из продуктов, типа Juniper (JunOS), Ubiquitu (EdgeOS ) и Vyatta, то работать с VyOS — это как семечки грызть :)
Ну и если говорить в общем, то принципы работы с VyOS и Cisco ASA примерно похожи: тот же режим конфигурирования устройства (любимый conf t), те же именованные группы правил применяемые к интерфейсу, и т.п. Команды конечно разные, это да :)
oller
Проще, почему vyos а не pfsense?
Как раз выбор стоит для стойки.
BNKT0P Автор
в двух словах — это проверенное и надёжное решение
oller
Такое же как и pfsense вот в чем вопрос
Но pfsense больше графика и понятно интуитивно интерфейс
а vyos это своя коммандная строка
BNKT0P Автор
Тут не поспоришь, графическая управлялка конечно же во многих случаях — это аргумент, особенно когда нет под рукой более-менее квалифицированного админа, или просто нет времени разбираться с CLI.
Но с другой стороны, работая с CLI, приходится влезать во внутренности устройства, иначе без знания команд элементарно ничего не настроить, особенно какие-то сложные конфиги.
GUI позволяет это делать в некоторых случаях даже методом тыка или просто запустив мастер настроек — тут да, простота может быть решающим аргументом, но до определённых пределов.
oller
После тех пределов придет понятие:
Вот тут уже получается только cisco juniper…
Кстати цена микротика копейки, между микротиком и vyos и pfsense что выбрать?
Это можно сказать жду статью с аналитикой какойнить адекватной)))
BNKT0P Автор
:)))
Ну да, асисяй это конечно нужный товарищ в хозяйстве, но пока рано :))
Чтобы сделать такую статью со сравнительным анализом, надо сесть, и проанализировать эти три решения — как устанавливать, как настраивать, степень сложности, интуитивности использования графической оболочки если есть, и т.п.
И всё равно найдутся или спорщики, или недовольные, так как сравнение как ни крути, будет субъективным в какой-то степени.
Поэтому совет простой — выбирайте то, с чем уже работали,
но исходя из настоящих и будущих требований по проекту и соотвествия им возможностей самого решения, чтобы потом не было мучительно больно и трудно всё или делать по новой, или ставить костыли.
Лично предпочитаю делать всё на Cisco, но даже у них не всегда есть то, что нужно, а уж слово "дешевле" — это явно не про них ;)))
oller
Когда нехватает на cisco берут микротик
Там хватает и экспертов уровня ccnp (выше у микрота хрен найдешь) и главное отдельные железки за копье, да и с графикой все весьма неплохо
BNKT0P Автор
Ну так то да, хотя предпочитаю использовать микротики для офисов — тут они наверное вне конкуренции точно, и главное GUI, с которым любой виндовс админ справится.
В своё время в плане простоты работы, ещё нравилось решение от M$ — TMG 2010, очень хорошая вещь была, особенно для публикации сервисов от M$ (правда без CLI), жалко что перестали его поддерживать, да и вообще завалили полностью это направление, всё пытаются запихнуть людей к себе в облака...