Создание отказоустойчивой ИТ инфраструктуры. Часть 3. Организация маршрутизации на роутерах VyOS

  • Tutorial

Основная цель статьи – показать процесс установки и настройки виртуальных маршрутизаторов VyOS на кластере oVirt, для организации связи на уровне L3 между внутренними и внешними сетями.


Также в статье будут рассмотрены вопросы, связанные с особенностями настройки выхода в Интернет через двух провайдеров, и повышения отказоустойчивости межсетевой маршрутизации.


Вводная часть


Основываясь на двух предыдущих статьях:



Мы к этому времени создали отказоустойчивый кластер 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.
Как вариант, если без GUI никак не обойтись, можно использовать Web GUI от роутера Vyatta, и попробовать export, а потом import конфигурации в 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 и пакетом QuaggaProvider-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 (можно более свежую)

Имена и IP адреса виртуальных машин для тестового стенда, разворачиваемых на кластере oVirt.
  1. test-17 – 1 Gb RAM, 1 CPU, 10 Gb HDD
    • VLAN17, IP – 172.20.1.239/24, Gateway – 172.20.1.1
  2. test-IM32 – 1 Gb RAM, 1 CPU, 10 Gb HDD
    • VLAN32, IP – 172.20.32.239/23, Gateway – 172.20.32.1
  3. test-IM40 – 1 Gb RAM, 1 CPU, 10 Gb HDD
    • VLAN40, IP – 172.20.40.239/23, Gateway – 172.20.40.1
  4. test-public – 1 Gb RAM, 1 CPU, 10 Gb HDD,
    • VLAN38, IP – 172.16.3.2/24, Gateway – 172.16.3.1
  5. PROVIDER-1 – 1 Gb RAM, 1 CPU, 10 Gb HDD
    • VLAN30, IP – 172.16.1.1/24
    • VLAN36, IP – 172.16.10.9/30
  6. PROVIDER-2 – 1 Gb RAM, 1 CPU, 10 Gb HDD
    • VLAN31, IP – 172.16.2.1/24
    • VLAN37, IP – 172.16.10.13/30
  7. 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
  8. 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
  9. 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, а затем назначить их на хосты кластера.


Делаем всё по инструкциям из предыдущей статьи, а также по официальной документации. Результат этой работы можно посмотреть на скриншотах, настройки сети у обоих хостов кластера должны быть идентичны:


Скриншот логических сетей oVirt


Скриншот логических сетей, привязанных к хосту oVirt


2) Установить ОС на виртуальные маршрутизаторы с пакетом Quagga, а также ОС на клиентские ВМ.


После подключения ВМ к соответствующим логическим сетям, устанавливаем на них ОС, и настраиваем IP адреса и шлюзы в соответствии со списком ВМ и со схемой сети.


Добавлять установочные образы с ОС и создавать виртуальные машины мы научились в предыдущей статье, поэтому особых затруднений этот процесс не должен вызвать.


Дальнейшая настройка этих виртуальных машин будет выполнена далее, по ходу статьи.


Начальная настройка маршрутизаторов VyOS.


Официальная документация по установке VyOS, FAQ.


Для установки маршрутизатора VyOs в качестве виртуальной машины под управлением oVirt:


  • скачиваем ISO с самым последним rolling release по ссылке
  • добавляем этот образ в oVirt
  • создаём виртуальную машину и назначаем для неё логические сети
  • назначаем первым загрузочным устройством установочный ISO образ с VyOS
  • включаем ВМ и приступаем к установке.

Скриншоты с настройками ВМ для 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

Настройка сетевых интерфейсов на VyOS1

Настройка сетевого интерфейса VLAN17:


set interfaces ethernet eth0 address '172.20.1.253/24'
set interfaces ethernet eth0 description 'VLAN17'

Чтобы удалить IP адрес с интерфейса:


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'

Настройка сетевых интерфейсов на VyOS2

Настройка сетевого интерфейса 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.


Настройка дополнительных параметров файервола VyOS
  • включаем логирование по 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).


Список HAIP, использующихся в качестве шлюзов по умолчанию для внутренних сетей:

VLAN17, HA VIP – 172.20.1.1/24


Ведущий хост – 172.20.1.253/24
Резервный хост – 172.20.1.254/24

VLAN32, HA VIP – 172.20.32.1/23


Ведущий хост – 172.20.33.253/23
Резервный хост – 172.20.33.254/23

VLAN40, HA VIP – 172.20.40.1/23


Ведущий хост – 172.20.40.253/23
Резервный хост – 172.20.40.254/23

Настройка локальных политик безопасности на роутерах VyOS1 и VyOS2
set 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'

Настройка vrrp для роутера VyOS1
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'
commit

Настройка vrrp для роутера VyOS2
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 '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 all

Пример работы vrrp:
vyos@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

Проверка работы vrrp
  • на роутере 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 и настройка BGP на «внешних» (провайдерских) маршрутизаторах
  • Установка пакета 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 также должен находиться в таблице маршрутизации.


Настройка на VyOS1 и VyOS2 выхода в Интернет, для хостов из сетей датацентра VLAN17, 32, 40
  • настраиваем правила балансировки исходящего трафика между роутерами 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, от слова никак, поэтому придётся использовать или другие коммерческие решения (Veritas NetBackup, Acronis Cyber Backup, TrilioVault, Bacula Enterprise Edition, SEP, etc.), или «ваять» что-то своё, или «допиливать» какие-то уже имеющиеся OpenSource решения, найденные на просторах Интернета.


Ну а что касается мониторинга железа и виртуальных машин, то тут дело вкуса и личных предпочтений, обычно на проектах используется Zabbix – бесплатное и довольно надёжное решение, с массой доступных шаблонов на любой вкус и цвет.


Но, впрочем, вернёмся обратно к нашей инфраструктуре – напомню, что в первой статье в составе железа была указана пара замечательных коммутаторов Cisco 3850, и было бы очень странно не использовать их по прямому предназначению – скоростной маршрутизации трафика между сетями. Поэтому в следующей статье мы и рассмотрим их интеграцию в нашу инфраструктуру, так как работа для них обязательно найдётся.

Lenvendo
Разработка и техподдержка онлайн-проектов

Комментарии 24

    0

    Отсутствие специалистов на рынке по этому решению делают серьезные опасения по внедрению
    документация обширна, но 24*7 уже стремновато…
    А так очень красивое решение

      +1

      Спасибо за комментарий, самое главное — решение рабочее :) и работает 24x7x365
      VyOS используются давно, и полностью удовлетворяют всем требованиям, а главное надёжны и предсказуемы.
      Что касается специалистов… Поверьте, порог вхождения не очень высок, особенно если человек уже работал с Juniper, или даже Cisco. Единственный недостаток, если с точки зрения не слишком сетевого админа, то это отсутствие GUI, но то в общем такое…

        +1
        Насколько я помню, изначально Vyatta была попыткой написания софтового аналога JunOS. При этом в качестве базы используется не FreeBSD, как в JunOS, а Debian.
        Так-же компания Ubiquiti написала свой веб-интерфейс и назвала это всё EdgeOS для использования в своих маршрутизаторах серии EdgeRouter.
        Потом Vyatta Inc. купила компания Brocade и использовала как основу для исключительно коммерческого продукта Brocade Vyatta Network OS.
        VyOS является форком с открытыми исходниками последнего издания Vyatta Routing Community Edition…
        Таким образом, я-бы не сказал, что на рынке нет специалистов. Juniper и Ubiquiti вполне распространённые решения в определенных кругах…
          0

          Совершенно верно, если работал с каким-либо из продуктов, типа Juniper (JunOS), Ubiquitu (EdgeOS ) и Vyatta, то работать с VyOS — это как семечки грызть :)


          Ну и если говорить в общем, то принципы работы с VyOS и Cisco ASA примерно похожи: тот же режим конфигурирования устройства (любимый conf t), те же именованные группы правил применяемые к интерфейсу, и т.п. Команды конечно разные, это да :)

            –1

            Проще, почему vyos а не pfsense?
            Как раз выбор стоит для стойки.

              0

              в двух словах — это проверенное и надёжное решение

                0
                Такое же как и pfsense вот в чем вопрос
                Но pfsense больше графика и понятно интуитивно интерфейс
                а vyos это своя коммандная строка
                  0

                  Тут не поспоришь, графическая управлялка конечно же во многих случаях — это аргумент, особенно когда нет под рукой более-менее квалифицированного админа, или просто нет времени разбираться с CLI.


                  Но с другой стороны, работая с CLI, приходится влезать во внутренности устройства, иначе без знания команд элементарно ничего не настроить, особенно какие-то сложные конфиги.
                  GUI позволяет это делать в некоторых случаях даже методом тыка или просто запустив мастер настроек — тут да, простота может быть решающим аргументом, но до определённых пределов.

                    +1

                    После тех пределов придет понятие:


                    • выделенное оборудование
                    • наличие недорогих экспертов уровня ccie
                    • и нахрен зоопарк и непонятные решения

                    Вот тут уже получается только cisco juniper…
                    Кстати цена микротика копейки, между микротиком и vyos и pfsense что выбрать?
                    Это можно сказать жду статью с аналитикой какойнить адекватной)))

                      0

                      :)))
                      Ну да, асисяй это конечно нужный товарищ в хозяйстве, но пока рано :))


                      Чтобы сделать такую статью со сравнительным анализом, надо сесть, и проанализировать эти три решения — как устанавливать, как настраивать, степень сложности, интуитивности использования графической оболочки если есть, и т.п.
                      И всё равно найдутся или спорщики, или недовольные, так как сравнение как ни крути, будет субъективным в какой-то степени.


                      Поэтому совет простой — выбирайте то, с чем уже работали,
                      но исходя из настоящих и будущих требований по проекту и соотвествия им возможностей самого решения, чтобы потом не было мучительно больно и трудно всё или делать по новой, или ставить костыли.


                      Лично предпочитаю делать всё на Cisco, но даже у них не всегда есть то, что нужно, а уж слово "дешевле" — это явно не про них ;)))

                        –1

                        Когда нехватает на cisco берут микротик
                        Там хватает и экспертов уровня ccnp (выше у микрота хрен найдешь) и главное отдельные железки за копье, да и с графикой все весьма неплохо

                          0

                          Ну так то да, хотя предпочитаю использовать микротики для офисов — тут они наверное вне конкуренции точно, и главное GUI, с которым любой виндовс админ справится.


                          В своё время в плане простоты работы, ещё нравилось решение от M$ — TMG 2010, очень хорошая вещь была, особенно для публикации сервисов от M$ (правда без CLI), жалко что перестали его поддерживать, да и вообще завалили полностью это направление, всё пытаются запихнуть людей к себе в облака...

        –1
        Вы серьезно предлагаете поднять маршрутизацию внутри ЦОД на «бордеры»? Или в вашем понимании ЦОД это пяток серверов с гигабитными интерфейсам? Почитайте про East-West модель трафика и поймите что ваша архитектура с L3 на бодерах, VRRP и прочим не жизнеспособна.
          0

          … в нашем понимании (согласно трём статьям) у нас сейчас всего-навсего небольшой датацентр с двумя хостами и виртуальными машинами на нём.
          Если попытаться "удивить" заказчика, что для всеобщего счастья и чтобы удовлетворить модели трафика типа east-west, ему понадобится вот прямо сейчас потратить ещё много денег на дополнительное оборудование, то он мягко говоря вас не поймёт. И будет в чём-то прав, так как острой необходимости в таком оборудовании на начальном этапе запуска проекта пока нет.


          И да, эта архитектура с внутрисетевым трафиком на бордерах — вполне жизеспособна, но конечно же до определённых пределов.


          В самом крайнем абзаце этой статьи, я прямо написал — что у нас ещё есть пара 3850, которые как раз и будут решать проблему роста трафика внутри датацентра, чтобы в итоге получить такую картинку
          Но об этом будет в следующей статье :)

            0
            Вот про 3850 я видел. Зачем было так развернуто писать про архитектуру сети которая априори кривая.
            И да, эта архитектура с внутрисетевым трафиком на бордерах — вполне жизеспособна, но конечно же до определённых пределов.

            Да, для маленького офиса. Не для ЦОД. И пределы её заканчиваются на LACP серверов или утыкаются в PPS и проц соответственно. Вместо того что бы коммутировать внутрисетевой трафик на wirespeed на железке специально для этого предназначенной.
            И будет в чём-то прав, так как острой необходимости в таком оборудовании на начальном этапе запуска проекта пока нет.
            И будет не прав в корне. Понятие «Пока» очень эфемерное. Пока нет и тут бац и уже есть. Но трогать ничего нельзя ибо продакшен, а масштабировать тоже нельзя ибо изначально не заложено масштабирование. Сразу продумать адресные планы, технологии и унести л3 на железо специально для этого предназначенное, позволит избежать мегатонны головной боли в дальнейшем. Благо, л3 коммутаторы (не обязательно cisco), сейчас не так дороги.
              +1

              Ну почему же сразу кривая то… Эта архитектура вполне рабочая (особенно при ограниченном бюджете, иначе смысл было её рисовать), и если вдруг не хватает производительности при прокачке внутреннего трафика, то так как у нас виртуальные роутеры, можно для них добавить и процессоров и памяти, в конце концов даже прокинуть напрямую физические сетевые карты с хоста.


              Эта архитектура актуальна для небольшого ЦОДа, и если не предполагается больших потоков внутреннего трафика, то зачем изначально огород городить, и разводить заказчика на деньги и усложнение инфраструктуры, если например в дальнейшем её будет обслуживать он сам и ему лишние сложности и тем более затраты ни к чему?


              Поверьте, внедрение коммутаторов L3 именно в предложенную инфраструктуру -это совсем несложно и не больно, и тем более не представляет из себя никакой головной боли (даже при необходимости делать это уже в работающем проекте на продакшене), а только сплошное удовольствие для настоящего сетевика (пишу совершенно без сарказма), и это будет показано наглядно, но в следующий раз ;)

                –1
                Ну почему же сразу кривая то… Эта архитектура вполне рабочая (особенно при ограниченном бюджете, иначе смысл было её рисовать), и если вдруг не хватает производительности при прокачке внутреннего трафика, то так как у нас виртуальные роутеры, можно для них добавить и процессоров и памяти, в конце концов даже прокинуть напрямую физические сетевые карты с хоста
                Да и это мгновенно становится весьма таки накладно при возросшем трафике обрабатываемым процессором.
                Эта архитектура актуальна для небольшого ЦОДа, и если не предполагается больших потоков внутреннего трафика, то зачем изначально огород городить, и разводить заказчика на деньги и усложнение инфраструктуры, если например в дальнейшем её будет обслуживать он сам и ему лишние сложности и тем более затраты ни к чему?
                1. Это не ЦОД. 2. Разница между l2 и l3 управляемым коммумтатором в данном случае окупается необходимостью утилизации ресурсов CPU на свичинг трафика.
                Поверьте, внедрение коммутаторов L3 именно в предложенную инфраструктуру -это совсем несложно и не больно
                на рабочей инфраструктуре унести л3 на другое железо — ну да, ну да. И это вместо того что бы _Сразу_ сделать все правильно.
                  +1
                  на рабочей инфраструктуре унести л3 на другое железо — ну да, ну да. И это вместо того что бы Сразу сделать все правильно.

                  На рабочей инфраструктуре именно унесём L3 и именно на железо ;)))


                  Ну вот так именно и бывает в жизни — создают изначально одни, потом заказчик говорит что он сам умеет и все свободны, потом оказывается что не очень то и умеет, и приходится браться за дело уже другим и перепроектировать всю сеть без какого-либо перерыва в работе продакшена.


                  В общем считайте, что следующая статья будет именно про такой случай :))
                  В котором будет показано не только как надо было строить сеть правильно изначально, но и что делать то, если она была таки построена немного примитивно и без учёта активного роста сетевых абонентов.

                    0
                    Ну вот так именно и бывает в жизни — создают изначально одни, потом заказчик говорит что он сам умеет и все свободны, потом оказывается что не очень то и умеет, и приходится браться за дело уже другим и перепроектировать всю сеть без какого-либо перерыва в работе продакшена.
                    Ну ко, тогда статья под дивизом «как нельзя проектировать сеть что бы потом не переделывать».
                      +1

                      Не согласен, статья под девизом " как можно спроектировать сеть "на минималках", и чтобы потом можно было бы её проапгрейдить без простоев" ;)))


                      Никто полностью переделывать эту сеть в дальнейшем не собирается, это как-то нерационально. Ну подождите пару недель ещё (может и быстрее), и сами увидите

          0
          Вопрос про vyos. Раньше он был полностью бесплатен, но сейчас www.vyos.io/subscriptions. Вы используете rolling release или делаете самостоятельные build под виртуализацию?
            0

            В некоторых проектах используется бесплатная LTS версия 1.1.8, для некоторых проектов образ билдится самостоятельно.


            Для тестового стенда вполне подойдёт rolling release, а если в процессе развёртывания этого стенда удастся протестировать такой образ в работе под нагрузкой, работе с VRRP, BGP, WLB, и т.п — т.е. с тем, с чем придётся работать в дальнейшем, то не вижу особых препятствий использовать его на продакшене.


            LTS образы по хорошему тоже надо тестировать, мало ли чего найдётся и у них.

            0
            Commvault точно умеет в RHEV. По поводу Ovirt не скажу — но в теории должен.
              0

              Должен конечно, вот сравнительная таблица решений резервного копирования для oVirt/RHEV (немного правда старенькая)



            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое