MikroTik и 192.168.0.0/24
Вышел на меня заказчик на первый взгляд с нетривиальной задачей «поднять два провайдера и настроить VPN между двумя офисами».
Для таких мелких задач обычно не пишутся ТЗ, а максимум достаточно схемы в Visio.
А вот и сама схема
А вот в чём собственно проблема.
Проблема в том, что на маршрутизаторе R1 три 192.168.0.0/24 сети, а также третья проблема — это то что удалённая сеть также имеет сеть 192.168.0.0/24
На момент начала работ проблему с двумя провайдерами решили подключением маршрутизаторов к каждому из провайдеров, VPN соединения не было.
Задача, настроить центральный маршрутизатор на работу с двумя провайдерами и вывести из сети два промежуточных маршрутизатора, настроить VPN между R1 и R2, трафик между офисами равномерно разделить по каналам.
Ну что же задача поставлена, вроде понятна, приступаем к построению лабы в UnetLab
Мне необходимо было полностью предоставить конфиг на оборудование, поэтому делал «один к одному», все реальный IP адреса и прочее.
Вот так выглядит схема в UnetLab
Между маршрутизаторами «провайдеров» и центральным маршрутизатором «internet» поднят BGP все провайдеры соединены с AS 65530.
Транспортная сеть 10.0.0.0/8
Для того чтобы исключить ошибку в конфигурации и не городить кучу сетей для управления, на всех маршрутизаторах включен RoMON, который позволяет подключатся с помощью winbox по mac к маршрутизатору через другие маршрутизаторы, очень похож на BGP.
Первая проблема, которую пришлось решать это конечно же провайдеры на маршрутизаторе R1.
Проблема заключается в том, что у маршрутизатора IP адрес 192.168.0.1/24, а провайдер отдаёт по DHCP адрес из такой же сети 192.168.0.0/24.
Хорошо, что шлюз не менялся.
Если оставить всё как есть, то MikroTik начинает строить ECMP на Connected маршруты, поведение ожидаемое. Но нам необходимо отделить эти сети, чистый Policy Base Routing нам не поможет, так как он применяется только к трафику в mangle.
Наше решение — это использовать статический VRF, который позиционируется на интерфейсе.
Основное отличие RBP и VRF в том, что при RBP по умолчанию если не найден подходящий маршрут в таблице, то поиск продолжится в таблице main, для VRF по умолчанию трафик будет искаться только в своей таблице.
И так приступим к настройке R1.
/ip address
add address=192.168.0.1/24 interface=ether4
/ip firewall nat
add action=masquerade chain=srcnat out-interface=ether1
add action=masquerade chain=srcnat out-interface=ether2
/ip dhcp-client
add default-route-distance=0 dhcp-options=hostname,clientid disabled=no interface=ether1
add default-route-distance=0 dhcp-options=hostname,clientid disabled=no interface=ether2
/ip route vrf
add interfaces=ether1 routing-mark=ISP1
add interfaces=ether2 routing-mark=ISP2
Обратите внимания на три последние строки, это есть статический VRF.
На данный момент таблица маршрутизации выглядит следующим образом.
Всё бы нечего, но как я говорил ранее из VRF не так просто выбраться, и для этих целей в MikroTik предусмотрена «утечка маршрута».
Реализуем утечку указываем два дефолтных маршрута.
/ip route
add check-gateway=ping distance=10 gateway=192.168.0.1%ether1
add check-gateway=ping distance=20 gateway=192.168.0.1%ether2
Обратите внимание как написан шлюз, к нему в конец через знак процента добавлен интерфейс, тот самый который находится в VRF.
Теперь при обращении из main таблицы через дефолтный маршрут, трафик попадёт в VRF таблицу. Но тут кроется загвоздка, так как это VRF, то вернувшийся трафик сам не попадёт в таблицу main из VRF ему необходимо помочь=)
/ip firewall mangle
add action=mark-connection chain=input in-interface=ether1 new-connection-mark=Input/ISP1
add action=mark-routing chain=prerouting connection-mark=Input/ISP1 new-routing-mark=ISP1 passthrough=no
add action=mark-routing chain=prerouting in-interface=ether1 new-routing-mark=main passthrough=no
add action=mark-connection chain=input in-interface=ether2 new-connection-mark=Input/ISP2
add action=mark-routing chain=prerouting connection-mark=Input/ISP2 new-routing-mark=ISP2 passthrough=no
add action=mark-routing chain=prerouting in-interface=ether2 new-routing-mark= main passthrough=no
1,2,4,5 — это стандартные правила в них нету нечего интересного, они гарантируют возвращение локального трафика обратно.
А вот третье и шестое правила там, где new-routing-mark= main, и есть исключение из VRF таблицы трафика
И так настройка двух провайдеров закончена, переходим к VPN
Настройка VPN
Так как на R1 нету реального адреса, и провайдер отказывается прокидывать хоть пару портов, решено было использовать один из Client-to-Server туннелей, выбор пал на SSTP
Начал я настраивать SSTP сервер профили и прочее, как до меня дошло, что со стороны клиента я не смогу указать src-address как в ipip или gre туннеле, другими словами мне не зацепится за трафик, чтобы второй туннель отправить через второго провайдера. Адрес назначения у двух туннелей одинаковый, на сервере не поднять два sstp сервера на разных IP или разных портах.
Решение не заставило себя долго ждать, вспомнил я про dst-nat, кто нам мешает изменить порт уже на сервере средствами фаервола?! некто! Тем более что в MikroTik есть action redirect, одно из подмножеств dst-nat. В итоге на клиенте используем два порта 443(ISP1) и 1443(ISP2)
R2
/ppp profile
set *0 local-address=172.31.255.254
/ppp secret
add name=ppp1 password=ppp1 remote-address=172.31.255.1 service=sstp
add name=ppp2 password=ppp2 remote-address=172.31.255.2 service=sstp
/interface sstp-server server
set enabled=yes
/ip firewall nat
add action=redirect chain=dstnat dst-port=1443 in-interface=ether1 protocol=tcp to-ports=443
Последнее правило, как раз отвечает за редирект с 1443 на 443(sstp Server)
R1
/interface sstp-client
add connect-to=1.1.1.2 disabled=no mrru=1600 name=ISP1/R2 password=ppp1 profile=default-encryption user=ppp1
add connect-to=1.1.1.2:1443 disabled=no mrru=1600 name=ISP2/R2 password=ppp2 profile=default-encryption user=ppp2
/ip firewall mangle
add action=mark-routing chain=output dst-address=1.1.1.2 dst-port=1443 new-routing-mark=ISP2 passthrough=no protocol=tcp
Последнее правило отвечает за выход sstp клиента через второго провайдера.
Настройка OSPF и NAT
Конечно я не смогу настроить работу между двумя сетями по их оригинальным адресам, если бы был один DHCP сервер с релейом, то можно было либо поднять общий брудкаст домен, или поднимать на маршрутизаторах arp-proxy, но это отдельная история.
И так решение есть, будем подменять адрес назначения и адрес отправителя и апеллировать целыми сетями.
Со стороны R1 будет сеть 192.168.3.0/24
Со стороны R2 будет сеть 192.168.4.0/24
Настроим R1 и OSPF
/routing ospf instance
set [ find default=yes ] disabled=yes redistribute-static=as-type-1 router-id=192.168.3.1
/routing filter
add action=accept chain=ospf-in prefix=192.168.0.0/16 prefix-length=24
add action=discard chain=ospf-in
add action=accept chain=ospf-out prefix=192.168.0.0/16 prefix-length=24
add action=discard chain=ospf-out
/routing ospf network
add area=backbone network=172.31.255.0/24
/ip route
add distance=1 dst-address=192.168.3.0/24 type=prohibit
Настроим R2 и OSPF
/routing ospf instance
set [ find default=yes ] redistribute-static=as-type-1 router-id=192.168.4.1
/routing filter
add action=accept chain=ospf-in prefix=192.168.0.0/16 prefix-length=24
add action=discard chain=ospf-in
add action=accept chain=ospf-out prefix=192.168.0.0/16 prefix-length=24
add action=discard chain=ospf-out
/routing ospf network
add area=backbone network=172.31.255.0/2
/ip route
add distance=1 dst-address=192.168.4.0/24 type=prohibit
Как видите мы опубликовали по одному статическому маршруту типа prohibit, они нам нужны только для публикации через OSPF и поднятия ECMP.
Протокол OSPF лёгкий в настройке и нет смысла его описывать, просто скажу, что при данных настройках по VPN туннелям будет автоматически происходить обмен сетями, а при наличии двух живых туннелей будет подниматься ECMP.
Немного по фильтрам пройдёмся
Правила в фильтрах терминирующие, так что сначала что-то разрешаем, а потом всё запрещаем.
add action=accept chain=ospf-in prefix=192.168.0.0/16 prefix-length=24
Разрешаем все маршруты из сети 192.168.0.0/16 и длинной /24
add action=discard chain=ospf-in
Запрещаем все маршруты
Я ещё раз напоминаю, о том, что в любом протоколе динамической маршрутизации необходимо использовать фильтры и не надо опубликовывать все подряд сети. Вспомните печальный опыт yandex
Как же мы будем подменивать целые сети?
Всё банально и просто, мы будем использовать специальный правила в NAT same и netmap.
Посмотрим со стороны маршрутизатора R1
Собственно
Сеть 192.168.0.0/24 на R1, будет доступна с R2 по сети 192.168.3.0/24
Сеть 192.168.0.0/24 на R2, будет доступна с R1 по сети 192.168.4.0/24
Собственно, сами правила NAT
Для R1
/ip firewall nat
add action=same chain=srcnat dst-address=192.168.4.0/24 src-address=192.168.0.0/24 to-addresses=192.168.3.0/24
add action=netmap chain=dstnat dst-address=192.168.3.0/24 src-address=192.168.4.0/24 to-addresses=192.168.0.0/24
Для R2
/ip firewall nat
add action=same chain=srcnat dst-address=192.168.3.0/24 src-address=192.168.0.0/24 to-addresses=192.168.4.0/24
add action=netmap chain=dstnat dst-address=192.168.4.0/24 src-address=192.168.3.0/24 to-addresses=192.168.0.0/24
Пруф
MikroTik — OSPF
MikroTik — VRF
MikroTik — NAT
MikroTik — RoMON
UnetLab
Если кто-то хочет развернуть у себя на UnetLab такую конфигурацию обращайтесь в личку, мой сайтик не выдержит хабраэфект
