Виртуальная лаба в домашних условиях. Часть 1: Сеть

На новогодних каникулах появилось, наконец, свободное время, чтобы заняться домашним сервером. Вместо Ubuntu 12.04 LTS был установлен VMWare ESXi 6.5, а сама система была разделена на несколько виртуалок, каждая под свою задачу.
С контейнерами пока решил не связываться – я пока не могу придумать реальную задачу, чтобы ради неё засесть за изучение Docker или LXC. Так что у нас будет классика – Debian 8 с последними апдейтами, свежая VMWare и Mikrotik (“железный”) в качестве роутера для всего этого счастья.

0. Disclaimer

Для начала о том, чего тут НЕ будет.
– Здесь не будет описываться установка VMWare или Debian
– Здесь не будет описываться настройка Mikrotik “с нуля”
– Здесь не будет описываться установка пакетов через apt (будь то ansible, zabbix или apache)
Я предполагаю, что компетенция моих читателей достаточна для того, чтобы не только прочитать всё то, что написано ниже, но и применять на практике с умом и пониманием, что вообще делается и для чего.

1. Связь. Настройка аплинков, failover, nat

С чего начинается лаба? Правильно, с сети. У меня в наличии роутер Mikrotik, два интернет-провайдера и некоторое количество клиентов, часть из которых – собственно сервер с виртуалками, часть – обычная домашняя сеть.
Разделять локалку на подсети не будем (пока), без ipv6 тоже обойдемся (хотя в будущем, разумеется, попробуем). Зато сделаем балансировку трафика (виртуалки должны ходить через резервный канал связи по умолчанию) и failover. А т.к. у меня на виртуалках есть ресурсы, опубликованные в интернет, то хотелось бы иметь к ним доступ изнутри сети, не заморачиваясь с перенастройкой DNS.
Нечто похожее я описывал 4,5 года назад в своей статье про policy-based routing на Mikrotik. С тех пор утекло много воды (и версий ROS), так что пользоваться ip rule уже не модно – гораздо проще маркировать пакеты с помощью mangle-цепочки фаервола.

1.1 Два провайдера: балансировка нагрузки

Имеем: два провайдера.
Один из них отдаёт нам честный белый ip-адрес по DHCP. Его мы будем использовать для доступа к виртуалкам снаружи и выпуска самих виртуалок в инет. Для остальных клиентов в локалке он является резервным.
Второй провайдер интернет даёт через l2tp-подключение, и выделенный ip не предоставляет. Его мы будем использовать для всей остальной локалки, как основной, и резервный для виртуалок. В принципе, можно даже настроить DynDNS, чтобы не терять связи с виртуалками в случае падения первого канала. Но не будем пытаться объять необъятное и впихнуть невпихуемое.
Основная задача – настроить автоматическое переключение между каналами в случае падения одного из линков.

Начальная конфигурация:
Активируем dhcp-клиенты на интерфейсах, куда включены провайдеры (у меня это первый и пятый порты)

Поднимаем l2tp-сессию с оператором:

Настраиваем роутинг. Т.к. нам нужно иметь два активных маршрута, то используем routing-mark. Да, маршруты придётся дублировать с теми, что прилетели по dhcp, а что делать?
В некоторых мануалах по настройке мультипровайдерной конфигурации советуют использовать директиву check-gateway в вариантe arp или ping. Это разумно, но нужно быть внимательным – шлюз провайдера на icmp-запросы отвечать, в общем случае, не обязан.

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

Правила NAT. Ну тут совсем всё просто: делаем src-nat на всех исходящих интерфейсах (у меня это два eth-интерфейса и l2tp).

Осталось только собрать всё это вместе и проверить, что всё работает. Отключить сначала один шнурок, потом второй. Переключение должно произойти автоматически.

В таблице маршрутизации после всех настроек мы увидим примерно следующее (сейчас работают оба провайдера):

1.2 Hairpin NAT в условиях балансировки трафика

Балансировку мы настроили, теперь идем дальше. Некоторые ресурсы, расположенные на виртуалках, опубликованы в инет. Изнутри локалки тоже хотелось бы иметь к ним доступ, и при этом не мудрить с подменой DNS-записей. При обычном DST-NAT у нас ничего не получится – т.к. сервер увидит, что src-ip находится в одной с ним подсети, и просто пошлёт ему ответный пакет, минуя роутер. Таким образом, TCP-соединение не сможет установиться. Чтобы обойти эту проблему, был придуман механизм hairpin NAT, когда при обращении из локалки на внешний ip роутера делается не только DST-NAT, но и SRC-NAT в адрес роутера, смотрящий в локалку.

Настраивается всё это достаточно просто. Для начала, добавляем нужные записи в настройки NAT:

В таблице mangle мы добавляем правила hairpin в “исключения” (я просто навесил routing-mark, который нигде более не используется), чтобы они не попадали в правила балансировки исходящего трафика. Эти правила необходимо поместить ДО правил, отвечающих за маркировку пакетов

Если у вас есть на роутере еще VPN для качания торрентов доступа, например, к рабочим ресурсам и сетям, то нужно поступить по аналогии и добавить правило, вешающее соответствующий routing-mark:

В dst-address VPN помещаем ресурсы, к которым мы ходим через VPN.

На этом всё. Сеть мы настроили, теперь можно идти дальше – к настройке reverse proxy, ssl и прочего хозяйства.

Бонус

Бонусом к этой части я оставлю два скрипта, которые существенно ускоряют процесс переключения. Первый определяет шлюз по умолчанию, выданный по l2tp (а он время от времени меняется), и подставляет его в наш маршрут.

Теперь добавляем наш скрипт в шедулер.
Заодно пишем второй – он раз в 30 секунд резолвит имя l2tp-терминатора Билайн через его же DNS-сервер (т.к. при переключении на резервный канал становятся активными его DNS-сервера, и достучаться до точки входа становится невозможно).

Вот теперь точно всё. Ждите следующую серию ;)