Для таких мелких задач обычно не пишутся ТЗ, а максимум достаточно схемы в 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 к маршрутизатору через другие маршрутизаторы.
Первая проблема, которую пришлось решать это конечно же провайдеры на маршрутизаторе 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 такую конфигурацию обращайтесь в личку, мой сайтик не выдержит хабраэфект
Комментарии (50)
nikerossxp
03.05.2016 15:39+1Если везде микротики, почему не стали использовать EoIP? Можно было сделать одну большую локалку. Разве что, широковещательные пакеты могут канал забивать.
vasilevkirill
03.05.2016 15:42Задачи такой не стояло, да и менять структуру сети нельзя было, нужно было обойтись только изменением на роутерах.
ikormachev
03.05.2016 16:02+4Никогда не понимал админов, которые используют в офисной сети адреса 192.168.0.0/24 и 192.168.1.0/24.
Во-первых, половина голосовых шлюзов и коммутаторов имеют эти адрес по умолчанию и будучи неаккуратно подключенными в сеть (или сброшенными на заводские настройки) они в подобной сети создают сетевые проблемы.
Ну и подавляющее большинство домовых маршрутизаторов используют подобную же адресацию, как следствие — VPN пользователи не видят в сети половины (а то и всех) ресурсов.
Попадись мне такая бы задача, первое с чего бы начал — со смены адресации и не городил бы всех остальных костылей.vasilevkirill
03.05.2016 16:20+2Ну начнём с того, что я выполнял то что было оговорено в ТЗ, а во вторых где вы увидели тут костыли?
ikormachev
03.05.2016 16:28+4У вас решение архитектурно ошибочно. И далее неважно, насколько технически грамотно оно реализовано — это все-равно называется костылем.
Правильное решение — потратить деньги клиента на смену адресации в сетях, а не на настройку костылей. Учитывая, что у клиента сеть 192.168.0.0 (да еще и провайдер такой же адрес дает) — там явно ничего критичного из сервисов не было.vasilevkirill
03.05.2016 16:35+2У меня архитектурно? я его не строил и не проектировал, и не обслуживал! Я просто настроил маршрутизаторы под инфраструктуру заказчика.
Я бы на вашем месте не был так уверен. Скажем так, в сетях стоит оборудование, за которое отвечают третьи лица, и поменять на них сеть не представляется возможным, а точнее по договору не имеют право.ikormachev
03.05.2016 16:59+6У меня архитектурно? я его не строил и не проектировал, и не обслуживал! Я просто настроил маршрутизаторы под инфраструктуру заказчика.
Да, у вас архитектурно ошибочно. Решая задачу, вы пошли самым легким для себя путем. По большому счету, вы не уменьшили проблемы вашего заказчика, а только увеличили их. Напряги вы тех, кто это строил и обслуживал — решение получилось бы и прямее и надежнее и дешевле в обслуживании.vasilevkirill
03.05.2016 17:04=) это даже забавно
martin74ua
03.05.2016 18:07+11пройдет полгода. У провайдеров что то поменяется, в сети клиента что то поменяется, вы будете на мальдивах вне зоны доступа… В результате прийдет другой, и мы почитаем еще одну статью на хабре «как я разбирался с настройками микротика и сделал все с нуля»…
Из личного опыта — чем проще решение — тем лучше. Его легче обслуживать, легче в нем разбираться…vasilevkirill
03.05.2016 18:24+1Что же вы все упёрлись ….
Это желание заказчика, заказчик захотел так. И точка.
Вся конфигурация было описана в документации, и конфигурация была согласованна с ИТ отделом.martin74ua
03.05.2016 18:31+2Да это понятно.
Плохо что согласовано с ИТ отделом ;)
А вообще — надо разговаривать с провайдерами ;) Если провайдер выдает на соединение серые адреса — то либо провайдер небольшой и адресов не так уж и мало, либо в целях экономии сидим на «квартирном» подключении. А ведь если поговорить с провайдером — то может и найдется возможность подключиться к инету напрямую, без туннелей, натов, серых адресов…vasilevkirill
03.05.2016 18:40Как я понял, что это арендатор помещения на заводской территории, который сам находится в промзоне.
В итоге это два провайдера от завода и промзоны, там что ли VDSL модемы, которые нельзя перенастраивать толи ещё какое-то брахло.
l0ser140
03.05.2016 18:47Вообще странно, что «провайдеры» выдают адреса из 192.168.0.0/24 сети.
Но зачем тогда эту же сеть использовать в офисе.
«Провайдеры» не в курсе о существовании друг друга?
А еще мне не понятно как реализован failover.
То, что другая офисная сеть будет доступна при падении 1 бриджа это понятно.
А вот что будет с доступом в интернет при неполадках у одного провайдера не понятно.
А если линк будет, а доступа в интернет не будет? (Если там VDSL модемы, то линк получается ни при каких неполадках не упадёт, только если не с самим модемом проблемы)vasilevkirill
03.05.2016 18:54С моей стороны заказчику было предложено построить рекурсивный маршрут с изменением target-scope, но заказчик попросил с помощью netwatch проверять доступность более десятка адресов, для уверенности, что точно провайдер не работает.
l0ser140
03.05.2016 18:56А как вы при помощи netwatch определяете, что основной канал вновь работоспособен?
vasilevkirill
03.05.2016 19:02трафик ICMP до проверяемых адресов маркируется и отправляется только через первого провадера.
l0ser140
03.05.2016 19:08Ping позволяет явно указать какую таблицу маршрутизации использовать. Мне кажется это менее костыльное решение.
Netwatch в микротике для каких-то непонятных мне целей сделан.vasilevkirill
03.05.2016 19:10тут вопрос вкуса, либо явно указать таблицу маршрутизации в пинге.
Либо сказать что весь ICMP трафик до данных узлов идёт через такую то таблицу маршрутизации.l0ser140
03.05.2016 19:13Ну а потом их местный админ, когда будут проблемы с интернетами, решит попинговать какой нибудь 8.8.8.8 (он же есть в списке, наверное) и будет в замешательстве.
vasilevkirill
03.05.2016 19:19скажу ещё в «двадцатый раз», если есть документация «что и почему и для чего», то у грамотного админа вопросов не возникнет.
Turilion
05.05.2016 13:53+1Мдя. Я за такое сетестроительство руки бы отрывал.
А вообще, делаю либо хорошо, либо не делаю вовсе. То есть в вашем случае отказался бы от объекта. На крайний случай поставил бы перед выбором, либо делаем по уму либо я умываю руки и ищете другого исполнителя. По опыту знаю, что подобные заказы на «срубить бабла по быстрому» выливаются потом в кромешный ад.
И не надо говорить, что таким образом без заказчиков остаться можно.
Именно благодаря такой политике наработал себе неплохую репутацию, которая теперь работает на меня.
bigov
11.05.2016 03:50… потом Заказчику захочется еще что-нибудь. За Вами придет следующий грамотный админ и тоже напишет статью. Потом еще… Конечно, клиент всегда прав. Но если он захотел переделать картонный плот в яхту, может стоит сказать ему, что плот придется разобрать, полностью?
vasilevkirill
03.05.2016 19:16+3Кстати вот вам ещё пример.
Дали мне два не настраиваемых LTE модема одинаковых, сказали настрой, так чтобы обо одновременно работали. и как вы думаете какие там адреса? правильно одинаковые.
и вам ещё один пример.
Было объединение двух филиалов с каждый из сторон три десятка сетей /24 из 10.0.0.0/24 и одна сеть пересекалась, одна из шестидесяти. Так как план и сроки были утверждены временно использовали конструкцию, которую я описал выше и уже потом, медленно и не спеша стали выводить данную сеть из продакшена.
HunterXXI
03.05.2016 16:24+1Я приношу извинения, но я три раза перечитал, но к сожалению так и не понял о чем статья. Вероятно проблема во мне. Что я должен понять из названия статьи MikroTik и 192.168.0.0/24?
Может быть это инструкция по использованию vrf в микротик?
ValdikSS
03.05.2016 17:15+2Если кто не знает, в OpenVPN есть опция
--client-nat, которая в юзерспейсе сделает ремап одного диапазона адресов в другой. Бывает удобно ее использовать не по самому прямому назначению, а для того, чтобы подключаться к одному и тому же адресу через разные VPN, подключаясь на разные адреса на стороне клиента.
evg_krsk
03.05.2016 17:16«на всех маршрутизаторах включен RoMON, который позволяет подключатся с помощью winbox по mac к маршрутизатору через другие маршрутизаторы, очень похож на BGP.»
Кто на кого похож?martin74ua
03.05.2016 18:15+1This page contains information about RoMON feature in RouterOS. RoMON stands for «Router Management Overlay Network». RoMON works by establishing independent MAC layer peer discovery and data forwarding network. RoMON network operates independently from L2 or L3 forwarding configuration.
Each router on RoMON network is assigned its RoMON ID. RoMON ID can be selected from port MAC address or specified by user.
RoMON protocol does not provide encryption services. Encryption is provided at «application» level, by e.g. using ssh or by using secure winbox
Фантазия автора безгранична. Какая связь между протоколом передачи маршрутной информации и протоколом удаленного управления микротиков? Кстати, я бы этот romon в доверенной сети только держал. Исключительно ;)
salsaly4
03.05.2016 18:18+1Как я в своё время запарился выкорчёвывать адреса типа 1.1.1.1 и так далее с ptp интерфейсов в одной не маленькой сети…
awsswa59
03.05.2016 20:25Туже задачу разрулил с помощью VLAN на микротик — всё гораздо проще.
vasilevkirill
03.05.2016 20:25+1Расскажите как
nikerossxp
03.05.2016 23:38видимо, в каждом влане одна из «одинаковых» сетей, и потом какие-то маршрутизации идут.
vasilevkirill
03.05.2016 23:41А чем собственно vlan отличается от ethernet интерфейса?
nikerossxp
04.05.2016 00:05Я же не вместо него отвечаю, я предполагаю.:) Либо он имел в виду EoIP, который в статье на хабре же обзывают как VLAN.
LoadRunner
04.05.2016 08:40Вопрос от новичка:
А почему именно MikroTik, и можно ли решить эту же задачу другими средствами, например, pfSense?vasilevkirill
04.05.2016 08:51Статья именно про микротик, но думаю любой маршрутизатор с vrf на борту справится с такой задачей
LoadRunner
04.05.2016 09:12Ну статья-то — всего лишь описание проделанной Вами работы. Мне просто любопытно, почему выбран именно MikroTik.
Chupaka
04.05.2016 08:54Наверное, логичнее всё же использовать action=netmap в обоих случаях (как в srcnat, так и в dstnat) — именно для этого оно и делалось.
Да, я заметил, что action=same при использовании целой подсети в параметре to-addresses ведёт себя аналогично action=netmap, но какова причина такого совпадения — всё руки не доходят узнать у разработчиков… В любом случае, action=same, судя по мануалу, не гарантирует соответствия 1:1, в отличие от action=netmap, и поведение вполне может измениться в будущем.vasilevkirill
04.05.2016 08:55судя по мануалу, не гарантирует соответствия 1:1
покажите пруфChupaka
05.05.2016 15:48http://wiki.mikrotik.com/wiki/Manual:IP/Firewall/NAT
netmap — creates a static 1:1 mapping of one set of IP addresses to another one. Often used to distribute public IP addresses to hosts on private networks
same — gives a particular client the same source/destination IP address from supplied range for each connection. This is most frequently used for services that expect the same client address for multiple connections from the same client
То есть same гарантирует только то, что новые соединения каждого клиента будут натироваться тем же адресом, что и текущие, уже снатированные
Maxlinus
04.05.2016 14:24за статью плюс:) но как вариант да можно использовать 1:1 wiki.mikrotik.com/wiki/Manual:IP/Firewall/NAT#1:1_mapping
vasilevkirill
04.05.2016 14:25Но тогда src адрес для всех соединений всегда один
Chupaka
05.05.2016 15:56Где вы это увидели? action=netmap работает так (напримере to-addresses=11.11.11.0/24 и клиента 192.168.30.40):
1) отсекает у адреса (src или dst — в зависимости от того, в какой цепочке натируем) сетевую часть (при заданной маске /24 от адреса останется 0.0.0.40);
2) на её место ставит сеть из to-addresses (получается 11.11.11.40).
Так что адреса всё же будут разниться в указанных пределах.
И — это по сути есть именно то, что вы и реализовали, пусть немного другим синтаксисом :)
Maxlinus
04.05.2016 14:28да, у вас схема сложнее той что приходилось настраивать мне, вариант 1:1 как альтернатива с более простой схемой.
nikerossxp
Странно, что-то не вижу я тут комментаторов с цитатами модели OSI, и что «годик понастраиваешь разные железки и потом такоё слёту будет отскакивать». Извините, о наболевшем.
vasilevkirill
Рано ещё, да и
пивнойдачный сезон начался