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 nat firewall
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 як в / ip або 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 nat firewall
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 nat firewall
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 nat firewall
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 таку конфігурацію звертайтеся в лічку, мій сайтик не витримає хабраэфект

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.