маршрутизация на основе политик

Давай я объясню, что происходит, может, есть другое решение, чем маршрутизация на основе политик. Сейчас шлюз по умолчанию на моем Microtik – Ether2. Из интернета я могу подключаться к моим локальным машинам через правила dst-nat, используя IP-адрес Ether2. Однако, если я пытаюсь подключиться, используя адрес Ether3, соединения выпадают. Если я меняю шлюз по умолчанию на Microtik на Ether3, то входящие соединения на Ether3 работают, но Ether2 больше не работает. Единственный интерфейс, который принимает входящие соединения – это тот, у которого шлюз по умолчанию. Я предположил, что такое поведение связано с тем, что трафик приходит через один интерфейс и выходит через другой, поэтому я посмотрел в сторону маршрутизации на основе политик. Мне нужно, чтобы я мог принимать входящие соединения на любом интерфейсе и чтобы трафик перенаправлялся на соответствующий локальный IP-адрес. Мне также нужно, чтобы любой локально сгенерированный трафик (например, просмотр веб-страниц и т.д.) выходил через Ether2, поэтому я и установил его как шлюз по умолчанию. Я использую правила, похожие на следующие, для переадресации: add chain=dstnat in-interface=Ether2 protocol=tcp dst-port=25 action=dst-nat \
   to-addresses=192.168.69.250 to-ports=25 comment="" disabled=no

add chain=dstnat in-interface=Ether3 protocol=tcp dst-port=25 action=dst-nat \
   to-addresses=192.168.69.251 to-ports=25 comment="" disabled=no Надеюсь, это проясняет, что я пытаюсь сделать. Mezlo

Спасибо за помощь. Я добавил 2 команды предмаршрутизации, но когда захожу в /ip route и добавляю третью команду, выдает ошибку: no such argument (dst-address!). Я добавляю ее в правильном месте? Mezlo

Я потратил немало времени над этой ситуацией, и вот как я добился работы:

У меня есть роутер с 3 интерфейсами: 1 внутренний и два внешних:

`/interface print`

```
#    NAME                   TYPE             RX-RATE    TX-RATE    MTU  
0  R 1-ISP1                 ether            0          0          1500
1  R 2-ISP2                 ether            0          0          1500
2  R 3-Internal             ether            0          0          1500
3  R 1-2 Bond               bonding          0          0          1500
```

Как видно выше, я создал интерфейс bonding из двух внешних адаптеров:

`/interface bonding print`

```
0  R name="1-2 Bond" mtu=1500 mac-address=XX:XX:XX:XX:XX:XX arp=enabled
   slaves=ISP1,ISP2 mode=balance-rr primary=none
   link-monitoring=mii-type1 arp-interval=100ms mii-interval=100ms
   down-delay=100ms up-delay=100ms lacp-rate=1sec
```

Я добавил IP-адреса к интерфейсам:

`/ip address print`

```
#   ADDRESS            NETWORK         BROADCAST       INTERFACE
0   192.168.1.254/24   192.168.1.0     192.168.1.255   3-Internal
1   85.xx.xx.xx/30     85.xx.xx.xx     85.xx.xx.xx     1-2 Bond
2   195.xx.xx.xx/30    195.xx.xx.xx    195.xx.xx.xx    1-2 Bond
```

Я добавил политику Mangle для трафика. ВАЖНО! dst-address для цепочек 0 и 1 НЕ совпадают с адресами для интерфейса bonding, они находятся в разных подсетях. У меня есть /30 сеть для маршрутизации всего трафика к целевой /26 сети к Mikrotik от ISP1. То же самое касается входящего трафика от ISP2, то есть /30 сеть для маршрутизации всего трафика к целевой /27 сети от ISP2. ВАЖНО! Правило 2 и 3 применяются к трафику, генерируемому сервером во внутренней сети, чтобы направить этот тип трафика через один из ISP. "new-routing" должен быть здесь, чтобы иметь возможность направлять весь исходящий трафик через ISP по моему выбору. Также обратите внимание, что правило #2 — единственное, у которого есть "Passthrough=yes", чтобы добиться принудительной маршрутизации:

`/ip firewall mangle print`

```
0   ;;; ISP1 incoming
   chain=prerouting in-interface=1-2 Bond dst-address=85.xx.xx.xx/26
   connection-state=new dst-address-list=WAN-NetIT action=mark-connection
   new-connection-mark=conn_ISP1 passthrough=no

1   ;;; ISP2: incoming
   chain=prerouting in-interface=1-2 Bond dst-address=195.xx.xx.xx/27
   connection-state=new action=mark-connection
   new-connection-mark=conn_ISP2 passthrough=no

2   ;;; Internal going out
   chain=prerouting in-interface=3-Internal dst-address=!192.168.0.0/16
   connection-state=new action=mark-connection new-connection-mark=conn_out
   passthrough=yes

3   chain=prerouting in-interface=3-Internal connection-mark=conn_out
   action=mark-routing new-routing-mark=route_ISP1 passthrough=no

4   ;;; ISP1: answer to incoming
   chain=prerouting in-interface=3-Internal connection-mark=conn_ISP1
   action=mark-routing new-routing-mark=route_ISP1 passthrough=no

5   ;;; ISP2: answer to incoming
   chain=prerouting in-interface=3-Internal connection-mark=conn_ISP2
   action=mark-routing new-routing-mark=route_ISP2 passthrough=no
```

Я добавил маршруты. ВАЖНО! Маршрут #5 должен существовать, если вы хотите разрешить Mikrotik устанавливать соединения с внешними серверами, то есть для контакта с серверами NTP. В противном случае это не обязательно:

`/ip route print`

```
#     DST-ADDRESS        PREFSRC         G GATEWAY         INTERFACE        ROUTING MARK
0 ADC 85.xx.xx.xx/30     85.xx.xx.xx                       1-2 Bond
1 ADC 192.168.1.0/24     192.168.1.254                     3-Internal  
2 ADC 195.xx.xx.xx/30    195.xx.xx.xx                      1-2 Bond
3 A S 0.0.0.0/0                          r 85.xx.xx.xx     1-2 Bond         route_ISP1
4 A S 0.0.0.0/0                          r 195.xx.xx.xx    1-2 Bond         route_ISP2
5 A S 0.0.0.0/0                          r 85.xx.xx.xx     1-2 Bond
```

Затем я добавил много правил DNAT для направления входящего трафика к серверам во внутренней сети. Каждый сервер имеет адрес в сети 192.168.1.x с Mikrotik в качестве шлюза по умолчанию. Поскольку каждый сервер должен быть доступен через 2 разных ISP (то есть иметь 2 внешних IP-адреса), мне пришлось настроить 2 правила DNAT для каждого сервера:

```
chain=dstnat dst-address=85.xx.xx.yy
protocol=tcp dst-port=80 action=dst-nat
to-addresses=192.168.0.aa to-ports=80

chain=dstnat dst-address=195.xx.xx.zz
protocol=tcp dst-port=80 action=dst-nat
to-addresses=192.168.0.aa to-ports=80
```

Для каждого сервера, которому необходимо инициировать соединение с серверами во внешней сети (например, SMTP-сервером), мне пришлось добавить правила SNAT для каждого ISP:

```
chain=srcnat routing-mark=route_ISP1 action=src-nat to-addresses=85.xx.xx.vv to-ports=0-65535

chain=srcnat routing-mark=route_ISP2 action=src-nat to-addresses=195.xx.xx.ww to-ports=0-65535
```

В целом, это покрывает все, НО! Я не смог успешно пометить и SNAT трафик, генерируемый самим Mikrotik, чтобы устранить необходимость в дополнительном шлюзе по умолчанию в правилах маршрутизации Может быть, кто-нибудь сможет помочь мне с этим, или это "особенность"?

Ясно!!! Нашел время и решил настроить тестовую среду, чтобы разобраться во всем этом… Могу сказать, что разобраться было не совсем просто, и несколько раз хотел все бросить. В общем, вот как все настроено. 6 маршрутизаторов MT.

User1, ether1 192.168.101.50/24, шлюз 192.168.101.1, подключен ether1 к MT ISP1 / ether1 ISP1, ether1 192.168.101.1/24 / ether2 192.168.102.1, подключен ether2 к MT Central / ether2 статический маршрут 192.168.2.0/24 на 192.168.102.2 (central → my network).

User2, ether1 192.168.111.50/24, шлюз 192.168.111.1, подключен ether1 к MT ISP2 / ether1 ISP2, ether1 192.168.111.1/24 / ether2 192.168.112.1, подключен ether2 к MT Central / ether3 статический маршрут 192.168.2.0/24 на 192.168.112.3 (central → my network).

Central:
ether1 192.168.120.1/24
ether2 192.168.102.2/24
ether3 192.168.112.3/24
ether4 192.168.2.221/24 (my network)

Firewall:
ether1 192.168.2.1
ether2 DHCP от моего ISP, статические маршруты для сетей добавлены на 192.168.2.221.

Настройка Central:
`/ip route`
 `add dst-address=0.0.0.0/0 gateway=192.168.112.1 disabled=no`
 `add dst-address=0.0.0.0/0 gateway=192.168.102.1 routing-mark=route-eth2 disabled=no`

Я использую путь к User2 в качестве маршрута по умолчанию, все, что помечено маршрутом route-eth2, должно отправляться по пути к User1.

`/ip firewall connection tracking`
`set enabled=yes tcp-syn-sent-timeout=1m tcp-syn-received-timeout=1m \
   tcp-established-timeout=1d tcp-fin-wait-timeout=10s tcp-close-wait-timeout=10s \
   tcp-last-ack-timeout=10s tcp-time-wait-timeout=10s tcp-close-timeout=10s \
   udp-timeout=10s udp-stream-timeout=3m icmp-timeout=10s generic-timeout=10m`

Убедитесь, что у вас хорошие значения здесь, ОТ ЭТОГО ЗАВИСИТ ВСЕ! Я использовал значения по умолчанию для этого теста.

`/ip firewall mangle`
`add chain=prerouting in-interface=ether2 action=mark-connection new-connection-mark=con-eth2 passthrough=yes disabled=no`
`add chain=prerouting in-interface=ether4 connection-mark=con-eth2 action=mark-routing new-routing-mark=route-eth2 passthrough=no disabled=no`

Это связывает все вместе. Первое правило отмечает все, что приходит (и может быть отслежено механизмом отслеживания соединений!) на ether2 с отметкой соединения con-eth2. Второе правило берет все с отметкой соединения con-eth2 и отмечает его для маршрутизации с меткой маршрутизации route-eth2.  ОБРАТИТЕ ВНИМАНИЕ, что второе правило ТАКЖЕ проверяет источник пакетов, ТОЛЬКО пакеты с отметкой соединения con-eth2, приходящие на ether4, получают метку маршрутизации. Без этой проверки интерфейса ничего не работает, так как трафик, приходящий на ether2, также будет помечен для маршрутизации с route-eth2! С этой конфигурацией я смог выполнить команду "/system telnet 192.168.2.1" с обоих конечных точек MT (User1 и User2) против брандмауэра MT, находящегося за Central MT. Надеюсь, это достаточно понятно для вас всех, я попробую сделать схему позже.
/Jörgen

Спасибо всем, кто писал в теме про маршрутизацию на основе политик – благодаря совокупности вашей мудрости была сформулировано решение проблемы, которая мучила меня более 6 недель, за исключением одной небольшой детали. У меня есть три провайдера, DMZ и внутренняя сеть на Mikrotik роутере (5 интерфейсов). Как и некоторые из вас, у меня были веб-серверы в DMZ с публичными адресами на каждом из провайдеров, чтобы публиковать два разных публичных IP-адреса для одного и того же веб-сервера. Проблема, как многие из вас видели, в том, что соединение, приходящее по ISP1 к веб-серверу, отвечает по ISP1, ISP2 или ISP3 в зависимости от текущей нагрузки на интерфейсы? Это называется некоторыми асимметричной маршрутизацией, поскольку пакеты ответа возвращаются в ваш браузер по разным маршрутам. Работало это как-то, но казалось, что где-то выше в иерархии провайдера провайдер блокирует пакеты с исходным адресом ISP2, отправляемые через интерфейс, принадлежащий ISP1 или ISP3. Используя маршрутизацию на основе политик, мы наконец-то заставили это работать. Входящие соединения маскировались для всех трех провайдеров для исходящего трафика. Чтобы веб-серверы работали, мы использовали mangle для установки метки соединения для каждого соединения, входящего через каждый из интерфейсов ISP. ISP1 был отмечен как ISP1, ISP2 - как ISP2, ISP3 - как ISP3. Правила dst-nat сопоставляли входящие соединения ISP с адресом веб-сервера в DMZ. Следующим шагом было использование mangle для соединения, возвращающегося из DMZ, используя метку соединения, определенную ранее, ISP1, ISP2, ISP3 и теперь использовать метку соединения для создания метки маршрута ISP1, ISP2, ISP3. Используя таблицу маршрутов, метки маршрута используются для направления трафика из DMZ обратно через интерфейс, на котором оно пришло. (Также отображается в таблице соединений) Ура!!! Работало для HTTP-трафика и FTP-трафика ~ вот проблема! ICMP к публичному адресу веб-сервера все еще случайным образом выбирает, какой интерфейс использовать для ответа. Если я пингую публичный IP-адрес на ISP1, пакет доходит до сервера в DMZ, сервер отвечает, пакет возвращается в Mikrotik, и кажется, что он случайным образом выбирает, через какой интерфейс отправить ответ. Пинг приходит по ISP1, а ответ уходит по ISP1, ISP2 или ISP3. Единственное время, когда пинг работает, — это если ответ приходит обратно через тот же интерфейс, через который он пришел. Нужно ли что-то еще определить, чтобы пинг работал??

Спасибо за твои добрые слова, приятно чувствовать признание (ну, как сказать, sp?, английский — не мой родной язык). Это была интересная задачка, так что я потратил на неё немного больше времени… и в итоге получилось более или менее так, как я и предполагал. Для тех, кто задаётся вопросом, как у кого-то может быть 6 MT роутеров для тестовой настройки, скажу, что у меня не было запасных устройств… Я использовал VmWare и настроил 6 MT виртуальных машин, 5 виртуальных сетей и одно подключение к моей физической сети, все MT установлены с лицензией на 24 часа… это подстегнуло меня завершить тестирование в разумные сроки. /Jörgen

После того, как я все это настроил, обнаружил, что не могу пропинговать IP-адрес ether3 из интернета. Все сервисы (ssh, ftp и т.д.) отвечали нормально, но пинг каждый раз не срабатывал. Заглянув в трекер соединений в Winbox, увидел, что ICMP-соединение не отображалось. Добавил следующее правило, и проблема была решена: / ip firewall nat
add chain=dstnat in-interface=ether3 protocol=icmp action=dst-nat to-addresses=192.168.69.250 to-ports=0 \
   comment="" disabled=no Адрес to-address – это IP-адрес одного из моих серверов. Пытался перенаправить его на IP ether1 на MT, но это не помогло. Соединение по-прежнему не отображается в трекере, но меня это совершенно не беспокоит. Mez

Похоже, это еще одна версия проблемы, с которой я столкнулся, когда не добавил "in-interface=ether4" в свой mangle. Суть в том, что трафик получает метку пакета route-eth2, а единственное правило маршрутизации, которое это обрабатывает, не знает, куда отправлять пакеты (оно знает только маршрут 0.0.0.0/0 к твоему второму провайдеру). Попробуй продублировать локальные маршруты (твои локальные сети, должны иметь флаги ADC в /ip route print) и добавь "routing-mark=route-eth2" к ним. Возможно, это поможет /Jörgen

Я не уверен, что понимаю, что вы имеете в виду. Я только метку трафика на ether3, но не могу получить доступ к ether2 или ether3 локально. Я уверен, что я как-то неправильно это вижу, но если бы это была проблема с метками, я бы подумал, что локальные подключения к ether2 должны работать, ведь это мой шлюз по умолчанию, но не ether3. У меня есть 3 маршрута с флагами ADC (по одному на интерфейс). У них нет адреса шлюза (только dst-address, prefsrc и интерфейс). Однако, когда я пытаюсь их скопировать, мне приходится указывать адрес шлюза, так что что мне туда ставить? Спасибо, что не бросили меня в этом вопросе. Mez