Я следовал вики по адресу http://wiki.mikrotik.com/wiki/PCC, чтобы настроить балансировку нагрузки между двумя интернет-соединениями. Из-за ipsec-туннеля я добавил следующее: `/ip firewall mangle add chain=prerouting dst-address=172.29.5.0/24 action=accept /ip firewall mangle add chain=prerouting dst-address=1.2.3.0/24 action=mark-connection new-connection-mark=ISP1_conn /ip firewall mangle add chain=output dst-address=1.2.3.0/24 action=mark-connection new-connection-mark=ISP1_conn` (1.2.3.0/24 — это подсеть, включающая удалённый пир ipsec 1.2.3.4. 172.29.5.0/24 — это удалённая локальная подсеть ipsec). Я подозревал, что это не работает (ipsec был нестабильным), поэтому провёл некоторые тесты. Я удалил два маршрута до 0.0.0.0/0 без routing-mark и добавил следующее: `/ip firewall filter add action=log chain=output disabled=no dst-address=1.2.3.0/24 log-prefix="ipsec out:" routing-mark=to_ISP1 /ip firewall filter add action=log chain=forward disabled=no dst-address=1.2.3.0/24 log-prefix="ipsec fwd:" routing-mark=to_ISP1`. Теперь, когда я пингую 1.2.3.3 или 1.2.3.4 (или пытаюсь установить ipsec с моей локальной стороны до 1.2.3.4), я часто вижу в логах, что пакеты будут использовать ISP2 в качестве исходящего интерфейса, с адресом источника ISP1! Я думаю, это объясняет, почему ipsec так нестабилен. (Дальнейшее логирование показывает, что ipsec-пакеты выходят через интерфейс IPS2, а возвращающиеся пакеты приходят через интерфейс ISP1). И сам факт, что что-то появляется в логах вообще, доказывает, что routing-mark правильный. Затем я запустил следующие команды: `/ip route add dst-address=0.0.0.0/0 gateway=10.111.0.1 distance=5 check-gateway=ping add dst-address=0.0.0.0/0 gateway=10.112.0.1 distance=2 check-gateway=ping`. По моему пониманию работы routing-mark, эти два правила не должны оказывать никакого влияния, поскольку есть другие правила маршрутизации с меньшим расстоянием, которые соответствуют routing-mark. Но они оказывают влияние. После ввода этих двух команд пакеты к ipsec-пиру отправляются через интерфейс ISP2 100% времени, за исключением момента установления туннеля. (По какой-то причине туннель устанавливается. Но все последующие пакеты отправляются через неправильный интерфейс). И пинги всегда отправляются через неправильный интерфейс. Но если добавить маршрут `add dst-address=1.2.3.0/24 gateway=10.111.0.1 distance=1 check-gateway=ping`, всё работает хорошо с ipsec. Но всё же большинство пакетов в интернет используют ISP2. Итак, мой вопрос. Я делаю что-то совершенно не так, или routing-mark часто игнорируется в таблице маршрутизации? Реальная настройка, где я столкнулся с проблемой, была на RB450G с ROS4.11. Проблема воспроизводится на RB751G с ROS 5.11, который я использовал для всех тестов/отладки. Чтобы убедиться, что я не ошибся при переводе адресов в командах из вики, я настроил полную тестовую среду, используя точно те же адреса, что и в вики, используя два других rb751g в качестве ISP* маршрутизаторов, и даже два других, чтобы создать «интернет» с удалённым ipsec-пиром.
Небольшая дополнительная информация: эта логика перехватывает IPsec-пакеты с неправильным исходящим интерфейсом: /ip firewall mangle add action=log chain=postrouting disabled=no dst-address=192.168.9.123 log-prefix=POST: routing-mark=to_ISP1
А вот эти правила не перехватывают: /ip firewall nat add action=log chain=srcnat disabled=yes dst-address=1.2.3.0/24 log-prefix=SRC: add action=log chain=srcnat disabled=yes dst-address=1.2.3.0/24 log-prefix=SRCmark: routing-mark=to_ISP1 (правила перемещены в начало списка)
Насколько я знаю, SRCNAT — это последнее место в роутере, где можно увидеть пакеты перед их отправкой. Странно, что они там не отображаются.
Привет, petterg, я не уверен, связана ли моя проблема с той же самой, но у меня тоже были проблемы с маркировкой IPsec-пакетов, и я нашёл причину/решение/баг?? Я не хочу вставлять сюда всю свою конфигурацию, поэтому постараюсь объяснить проблему как можно лучше. У меня двойная конфигурация WAN (без BGP) (с дополнительными скриптами для переключения при отказе WAN, но это не имеет значения). У меня правила mangle, основанные на этом сайте: https://aacable.wordpress.com/2011/07/27/mikrotik-dual-wan-load-balancing-using-pcc-method-complete-script-by-zaib/ только немного усовершенствованы: /ip firewall mangle add chain=input in-interface=WAN1 action=mark-connection new-connection-mark=WAN1_conn add chain=input in-interface=WAN2 action=mark-connection new-connection-mark=WAN2_conn В моём случае у меня chain=prerouting, поэтому все входящие соединения с роутера (как сам роутер, так и предназначенные для моих локальных подсетей) отмечены соединением. У меня есть VPN-соединения с удалёнными локациями (GRE-туннели, работающие поверх IPsec). GRE-туннели работают на локальных IP-адресах (10.255.255.10/32 - центральный офис, 10.255.255.20/32 - удалённый офис). IPsec-политики настроены только для этих IP-адресов, чтобы они были инкапсулированы и зашифрованы с помощью IPsec. У меня есть два GRE-туннеля до каждой удалённой локации (один работает на нашем WAN1, а второй — на WAN2). Что я обнаружил, что исходящие IPsec-пакеты, которые отмечены для WAN2, на самом деле не выходят через правильный интерфейс (они выходили через WAN1 (по умолчанию)). Поскольку оба наших провайдера не фильтруют наши исходящие адреса, мы можем использовать IP-адрес, назначенное ISP1, и пакет успешно выходит через интерфейс ISP2 и наоборот. Поэтому я даже не подозревал, что происходит что-то не так... После двух дней упорной работы, анализа логов, я нашёл причину!! Все расшифрованные пакеты, которые поступают из IPsec-туннеля (эти с 10.255… на которых работают GRE-туннели) в брандмауэре действуют как входящие интерфейс = физический интерфейс, на который был получен IPsec-пакет. Это на самом деле для меня не ново, я знал это раньше и это, вероятно, нормально. Таким образом, согласно правилам mangle выше, соединения GRE (с локальными/приватными IP-адресами) также отмечаются соединением, что приводит к тому, что исходящий пакет GRE правильно отмечается для правильного исходящего WAN-интерфейса. Но это совершенно не имеет значения, так как исходящий пакет GRE перехватывается IPsec-полисикой, шифруется, инкапсулируется, и весь процесс начинается заново. http://wiki.mikrotik.com/images/thumb/2/2a/IP_final.png/700px-IP_final.png и.. вот где начинаются проблемы.. ! Теперь исходящий IPsec-пакет также должен быть отмечен и направлен через правильный wan-интерфейс, но это не работает. Либо правило маршрутизации не работает, либо метка маршрута игнорируется во время маршрутизации. и.. теперь решение/причина! Эта проблема с маркировкой/маршрутизацией IPsec-пакетов вызвана предыдущей маршрутизацией пакета, который был инкапсулирован в IPsec!! (GRE-пакеты в моём случае). Я совершенно не представляю себе... какая связь/причина маршрутизации пакетов, которые поступают в IPsec-туннель, с маркировкой IPsec-пакетов? Решение было очень простым, я обновил вышеуказанные правила подсетями IP-адресов назначения WAN-ссылок, так что теперь соединения, предназначенные для публичных IP-адресов, поступают только через WAN-интерфейсы и маркируются. (GRE-пакеты теперь не отмечаются). Я провёл несколько тестов, не только с GRE, но и с простым ICMP-пингом по этим приватным IP-адресам, используемым GRE. И я могу подтвердить: каждый пакет, который маркируется для маршрутизации, но в конечном итоге инкапсулируется в IPsec-пакет, приводит к тому, что маршрутизация для этого IPsec-пакета не работает. Пожалуйста, ребята из MikroTik, подтвердите, это баг или я чего-то не знаю? (проверено на ROS 6.18 и 6.20)
На дворе 2023 год, ROS v7.9, всё то же самое, по-прежнему без документации. Пришлось прибегнуть к простому сбросу метки маршрутизации как первому правилу в цепочке обработки исходящего трафика: /ip firewall mangle add chain=output action=mark-connection connection-state=new,untracked ipsec-policy=out,ipsec new-connection-mark=no-mark passthrough=yes log-prefix=cm-reset comment="reset connection mark for outgoing packets to be IPsec encrypted as they break IPsec route adjustment (routing marks on encrypted packets stop working)".
Посмотри на схему потока пакетов и конкретный пример ispec https://help.mikrotik.com/docs/display/ROS/Packet+Flow+in+RouterOS. Если тебе нужно перенаправить ipsec-пакеты, то нужно использовать routing marks после ipsec-инкапсуляции. Ipsec не заботится ни о каких предыдущих метках или предыдущих решениях о маршрутизации. Он инкапсулирует и отправляет пакеты в соответствии со своими политиками. Если тебе нужно перенаправить входящие дешифрованные пакеты, то то же самое, маркировку нужно делать после процесса дешифрования.
В чем разница между режимом туннелирования IPsec и транспортным режимом IPsec? Режим туннелирования IPsec используется между двумя выделенными маршрутизаторами, где каждый маршрутизатор выступает в качестве одного конца виртуального "туннеля" через общедоступную сеть. В режиме туннелирования IPsec зашифровывается исходный IP-заголовок, содержащий окончательный пункт назначения пакета, а также полезная нагрузка пакета. Чтобы промежуточные маршрутизаторы знали, куда пересылать пакеты, IPsec добавляет новый IP-заголовок. На каждом конце туннеля маршрутизаторы расшифровывают IP-заголовки, чтобы доставить пакеты к их пунктам назначения. В транспортном режиме зашифрована только полезная нагрузка каждого пакета, но исходный IP-заголовок не зашифрован. Таким образом, промежуточные маршрутизаторы могут видеть окончательный пункт назначения каждого пакета — если не используется отдельный протокол туннелирования (например, GRE).
Означает ли вышеописанное, что RouterOS всегда использует туннель? В транспортном режиме зашифрована только полезная нагрузка, поэтому используется обычная маршрутизация.