Mikrotik ros, полезные мелочи

Настройка роутера

Роутер на то и роутер чтобы управлять трафиком через firewall. Но мы не будем настраивать правила фильтрации в данной статье. Так же у нас не будет включена Hardware Offload т.к. мы используем лабораторный стенд и отсутствуют какие-либо чипы коммутации. Чипы коммутации отсутствуют на RouterBoard серии CCR и виртуалок CHR. Первым делом создадим bridge и добавим в него ether2-5.

На вкладке VLANs укажем сети.

Согласно схеме коммутации, у нас есть ПК в VLAN100 за Mikrotik2, Mikrotik4, Mikrotik5, в связи с этим указываем соответствующие Tagged интерфейсы. Добавляем бридж в бридж, это так сказать некий порт, между роутером и сетью который позволяет понимать трафик в определенном VLAN. Проделываем аналогично для 200-ой сети.

Далее настроим сеть управления, в которой будут коммутаторы и роутер, а также ПК VPC7.

«Почему так?» —спросите вы. Потому что данный тег нужно передавать на все коммутаторы, чтобы ими управлять, принимая его на устройствах.

Далее создадим VLAN интерфейсы и укажем на них адреса. В Interfaces создадим новый указав понятное название и VID. Обязательно указываем bridge1, т.к. повесить метку на физический интерфейс не получится, в связи с тем, что он находится в slave режиме (зависит от bridge).

Создаем по аналогии для меток 200 и 99.

Далее задаем адреса на интерфейсы:

• VLAN100 – 192.168.100.1/24;
• VLAN200 – 192.168.200.1/24;
• VLAN99 – 192.168.99.1/24.

По аналогии добавляем адреса для сетей 200 и 99 выбрав соответствующее интерфейсы.

Все что мы сделали выше – подготовительные работы. Еще ничего не работает, метки не бегают, адреса фейковые. Обязательно все перепроверим и только после этого, открываем свойства bridge1 и включаем VLAN Filtering. Все начинает работать, до этой галочки – нет.

Сохраняем и перейдем к созданию DHCP серверов для Vlan сетей на нашем микротике Открываем IP – DHCP Server и жмем DHCP Setup.

Выбираем интерфейс, на котором будет работать служба DHCP.

На следующем шаге ничего не меняем.

Следом необходимо указать шлюз. В данном случае будет 192.168.100.1

Далее нам предлагают указать выдаваемый пул адресов.

DNS-сервер. В нашей инсталляции будет свой на каждый VLAN, т.е. 192.168.100.1. Если у вас уже есть DNS сервера, можете указать их.

И последнее – время аренды. Оставим по умолчанию.

После создания проверим, на верном ли интерфейсе у нас работает служба.

По аналогии создаем для 200 и 99.

На этом базовая настройка шлюза завершена.

Реализация

Поднимаем первой виртуалкой chr по .

Если пользуетесь приведенным скриптом, обратите внимание, что проверяется в начале наличие каталога -d /root/temp, а если его нет, создается каталог /home/root/temp, однако работа дальше ведется все равно с каталогом /root/temp. Скрипт необходимо исправить для создания соответствующего каталога

Добавляем сабинтерфейс с номером VLAN, указываем, что настройка адресов будет происходить на бриджах используя inet manual

ВАЖНО. Нельзя настраивать IP-адреса на интерфейсах, которые вы затем будете включать в бридж, как это будет работать и будет ли вообще никому неизвестно

После переписки со службой поддержки Hetzner стало ясно, что добавить дополнительный мак для подсети так же, как и для выделенного адреса они не смогут. То есть нельзя включать в бридж локальный интерфейс на сервере и интерфейс нашей виртуальной машины CHR. Hetzner присылает уведомление с требованием убрать лишний мак. Убираем бридж vmbr0 и назначаем адрес напрямую на интерфейс eno1.

Далее создаем бридж vmbr1 – и вешаем на него произвольный адрес, который будет конечной точкой наших маршрутов из CHR, а так же указываем дополнительной командой добавление маршрута на нашу дополнительную сеть, заказанную в Hetzner для этого сервера через этот бридж. Добавление маршрута сработает, когда интерфейс поднимается.

Вторым бриджом будет у нас интерфейс для локального трафика, добавляем на него адрес для получения связности между разными серверами Proxmox по локальной сети без выхода в интернет и указываем портом сабинтерфейс eno1.4000, который выделен для нашего VlanID.
При начальной настройке попадаются советы, что можно поставить для Proxmox дополнительно пакет ifupdown2 и можно при изменениях в сетевых интерфейсах сервер целиком не перезагружать. Однако это характерно только для первичной настройки, и при использовании бриджей и настройке уже виртуальных машин сталкиваешься с проблемами отвала сети в виртуалках. При том, что вы правили, например, интерфейс vmbr2, а при применении конфигурации сеть отваливается уже на всех внутренних интерфейсах и не поднимается до полного перезапуска сервера. ifdown&&ifup не помогают. Если у кого-то есть решение – буду благодарен.

Сам первый настроенный интерфейс на сервере остается рабочим и доступным.

Странность в том, что гейтом предлагается использовать собственный адрес физического сервера.

Классический вариант, предлагаемый самим Hetzner указан в постановке задачи и был реализован клиентом самостоятельно. В этом варианте клиент теряет первый адрес на адрес сети, второй адрес на бридже proxmox и он же будет шлюзом, и последний адрес для бродкаста. Адреса IPv4 лишними не бывают. Если же вы впрямую попробуете прописать на CHR IP адрес 136.х.х.177/29 и шлюз для 0.0.0.0/0 148.х.х.165 то сделать это сможете, однако шлюз не будет Direct Connected и поэтому будет unreachable.

Выйти из положения можно, если использовать 32 сеть на каждый адрес и в качестве имени сети указав нужный нам адрес, который может быть любым. Получается аналог point-to-point соединения.

В этом случае шлюз разумеется будет доступен, и все будет работать так, как нам нужно.
Учитывайте, что в подобной конфигурации не рекомендуется использовать правило SRC-NAT masquerade, потому что выходной адрес будет неопределенно различным, а правильнее указать action: src-NAT и конкретный адрес, из которого вы будете выпускать клиента.

Не стоит использовать firewall, предлагаемый hetzner, чтобы не запутаться в месторасположении настроек. Так же hetzner будет действовать на все сети, в том числе на те, которые заведены на CHR и для открытия и проброса портов будет необходимо открывать еще и в веб-интерфейсе провайдера.

Netwatch не работает, основной провайдер меняет шлюз у DHCP client

Для решения этой проблемы можно адаптировать такие скрипты:

Вариант-1

:global ispgw [ip dhcp-client get  gateway ];
:global ispgwstat [ip route get  gateway ];

#:log info ("$ispgw" )
#:log info ("$ispgwstat" )

:if ($ispgw = $ispgwstat ) do={ :log info ("ISP-1 Gateway is OK" ) } else={ ip route set  gateway=$ispgw; :log info ("ISP-1 Gateway WAS CHANGED" )}

который сравнивает установленное значение gateway провайдера ISP-1 в маршрутах Routes со значением gateway, установленного в DHCP client.

Вариант-2

В свойствах DHCP клиента добавить скрипт

{
:local rmark "ISP-1"
:local count 
:if ($bound=1) do={
:if ($count = 0) do={
/ip route add gateway=$"gateway-address" comment="ISP-1" distance=1
} else={
:if ($count = 1) do={
:local test 
:if ( != $"gateway-address") do={
/ip route set $test gateway=$"gateway-address"
}
} else={
:error "Multiple routes found"
}
}
} else={
/ip route remove 
}
}

который будет отрабатывать на любое изменение статуса DHCP клиента, удаляя и создавая новый маршрут в таблице маршрутизации.