+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Странное поведение P2P IPSEC

Странное поведение P2P IPSEC, RouterOS

mdd

Guest

04.05.2022 06:09:00

Всем привет! Странная проблема с настройкой IPSEC P2P. Всё работает некоторое время, а потом через случайный промежуток трафик по туннелю просто перестаёт передаваться. В ipsec пишется, что соединение установлено, но трафик не идёт ни туда, ни обратно. Если попробовать отключить пиры и политики, а потом снова включить — трафик снова начинает передаваться, но не всегда.

mdd Guest	#2 0 22.06.2022 12:21:00 Окей, ребята, нашёл, в чём была проблема — железо не справлялось с высоким уровнем шифрования. Теперь, когда мы снизили настройки шифрования, всё работает.

mdd

Guest

09.08.2022 12:34:00

К сожалению, проблема всё ещё существует. Трафик идёт в одну сторону (на мой взгляд, судя по счётчикам в правилах, он увеличивается)

при пинге до удалённого узла. Снова несколько дней всё работало после отключения и повторного включения пиров, туннель поднят, но трафик не проходит. Пингуем с 10.254.0.0/24. Есть ли предложения, как отследить этот трафик с помощью логирования или чем-то ещё?

sindy Guest	#4 0 09.08.2022 13:32:00 Когда это происходит, что показывает команда /ip ipsec statistics print с обеих сторон?

mdd

Guest

10.08.2022 06:43:00

Настроено два IPSec-туннеля с клиентами: (с их стороны проверить нельзя, но они утверждают, что все остальные существующие туннели у них работают нормально, только с моим возникают проблемы). Можно ли понять, в чем у меня проблема?

На моей стороне команда /ip ipsec statistics показывает:
in-errors: 0
in-buffer-errors: 0
in-header-errors: 0
in-no-states: 233
in-state-protocol-errors: 0
in-state-mode-errors: 0
in-state-sequence-errors: 0
in-state-expired: 0
in-state-mismatches: 0
in-state-invalid: 0
in-template-mismatches: 0
in-no-policies: 0
in-policy-blocked: 0
in-policy-errors: 0
out-errors: 0
out-bundle-errors: 0
out-bundle-check-errors: 0
out-no-states: 3012
out-state-protocol-errors: 8
out-state-mode-errors: 0
out-state-sequence-errors: 0
out-state-expired: 8
out-policy-blocked: 0
out-policy-dead: 0
out-policy-errors: 0

sindy

Guest

10.08.2022 07:49:00

Этот момент может быть очень важен — IPsec сопоставляет пакеты с селекторами трафика отдельных политик до первого совпадения, так что если селектор трафика вашего туннеля перекрывается селектором какого-то другого туннеля, трафик, который клиент отправляет вам, может попасть к другому пиру. Это не та ошибка, которую я ожидал увидеть, но ненулевые значения действительно указывают на проблему. Когда всё ломается, что показывает команда /ip ipsec installed-sa print? Если хотите скрыть данные, достаточно затушевать IP-адреса, все ключи временные, так что потенциальному злоумышленнику пришлось бы использовать их пока они ещё действительны. Но сами значения ключей были бы интересны только если у вас есть данные с обоих устройств за одно и то же время (чтобы сравнить и проверить, совпадает ли результат перегенерации ключей у обоих пиров, пару лет назад там был баг). Бывали ли у вас моменты, когда вы терпеливо ждали 30+ минут после обрыва туннеля? Если проблема связана с перегенерацией ключей, велика вероятность, что результат следующей перегенерации будет корректным — это подтвердит, что проблема именно в перегенерации, а не в чём-то другом. Отлаживать сложно, когда нет информации с обеих сторон. Можно запустить /tool sniffer quick ip-protocol=ipsec-esp и посмотреть, отправляет ли ваш роутер что-то при попытке сгенерировать трафик к пиру, и получает ли он что-то, когда с другой стороны начинают отправлять данные. Если что-то приходит с удалённой стороны, вероятно, это проблема с перегенерацией ключей (но при этом в статистике должны отображаться ненулевые значения в другой строке, я просто не помню какую именно); если ничего не приходит, у удалённой стороны может быть проблема с «теневым» перекрытием политики — или что-то ещё.

mdd

Guest

12.08.2022 07:51:00

Привет, Синди. Судя по поведению и по тому, что я читал на всех форумах, возможно, дело в NAT-правилах, которые влияют на трафик (только предположение). Но я уже сделал RAW-правила, чтобы NAT не участвовал в трансляции. Однако счётчики этих правил не растут, когда трафик не идёт ни туда, ни обратно. Туннель всегда установлен.

/ip firewall raw print
Flags: X - отключено, I - недействительно, D - динамическое
0 ;;; iii
chain=prerouting action=notrack log=no log-prefix="" src-address=10.254.0.0/24_MYLAN dst-address=172.16.3.0/30_CLIENT_LAN
chain=prerouting action=notrack log=no log-prefix="" src-address=10.251.0.0/24_MYLAN dst-address=10.14.0.0/16_CLIENT_LAN
chain=prerouting action=notrack log=no log-prefix="" src-address=172.16.3.0/30 dst-address=10.254.0.0/24
chain=prerouting action=notrack log=no log-prefix="" src-address=10.14.0.0/16 dst-address=10.251.0.0/24

На данный момент трафик через оба туннеля отсутствует.

/ip ipsec installed-sa print
Flags: H - hw-aead, A - AH, E - ESP
0 HE spi=0xF0D0A4F src-address=CLIENT_IP dst-address=MY_WAN state=mature auth-algorithm=sha1
enc-algorithm=aes-cbc enc-key-size=256 auth-key="1de0"
enc-key="e7e23da6a4b2bcb94f17922d3970e1915d5ba3cf49c6f34" add-lifetime=48m/1h
replay=128

1 HE spi=0x9884EAF6 src-address=MY_WAN dst-address=CLIENT_IP state=mature auth-algorithm=sha1
enc-algorithm=aes-cbc enc-key-size=256 auth-key="26a66ed094f8ee0ef5cb"
enc-key="5eb3259s8f487c3b1661d1c67e9fb46" add-lifetime=48m/1h
replay=128

2 HE spi=0x637A3BB src-address=CLIENT_IP2 dst-address=MY_WAN state=mature auth-algorithm=sha1
enc-algorithm=aes-cbc enc-key-size=128 auth-key="7b89486ad9c61183d0992b54cc8"
enc-key="5d0765sc5c3385ee481" add-lifetime=24m/30m replay=128

3 HE spi=0x85F90A9 src-address=MY_WAN dst-address=CLIENT_IP2 state=mature auth-algorithm=sha1
enc-algorithm=aes-cbc enc-key-size=128 auth-key="573608f9ss59b5cddcaee01c13e"
enc-key="00bbads27cb33a26" addtime=aug/12/2022 10:25:43 expires-in=16m15s
add-lifetime=24m/30m current-bytes=2048 current-packets=40 replay=128

sindy

Guest

14.08.2022 16:03:00

NAT может быть необходим для работы IPsec, а может и мешать, всё зависит от конкретного случая. Но для того, чтобы неправильные правила NAT вызывали такие случайные сбои, нужно ещё кое-что — например, в стандартной маршрутизации должны поменяться маршруты, потому что какой-то интерфейс отключится (или включится), и тогда трафик пойдёт по другому маршруту, а значит, попадёт под другое правило NAT. Это важное замечание, оно может указывать на то, что проблема не в IPsec, и что трафик, который должен идти через туннель, на самом деле вовсе не доходит до вашего Mikrotik. Но это верно только в том случае, если весь ваш трафик — это ответы (то есть ваша сторона ничего не отправляет активно на удалённую сторону). Короче говоря, пока информации недостаточно, чтобы помочь. Мне нужен экспорт конфигурации и немного информации о топологии приложения — серверы на обеих сторонах, серверы только у вас, серверы только у них, с какой частотой ходит трафик, когда всё работает... Возможно, у них стоит фаервол, который не делает NAT, но блокирует входящий трафик ESP, если между пакетами был достаточно долгий период тишины. Кстати, с вашей стороны всё же был небольшой объём трафика к ним:

mdd

Guest

16.08.2022 13:17:00

Когда мы делаем ping до конечной точки туннеля, увеличиваются только счетчики с нашей стороны на удаленную сторону в RAW-правилах. Ниже добавил часть конфигурации, IP/подсети созданы случайно для публичного просмотра.

/interface wireless security-profiles set [ find default=yes ] supplicant-identity=MikroTik

/ip ipsec profile
add dh-group=modp1024 enc-algorithm=3des name=profile_1
add dh-group=modp1024 enc-algorithm=3des name=profile_2
add dh-group=modp1024 enc-algorithm=aes-128 name=CLIENT1 nat-traversal=no
add dh-group=modp1536 enc-algorithm=aes-256 lifetime=2h10m name=CLIENT2 nat-traversal=no

/ip ipsec peer
add address=3.3.3.3/32 local-address=2.2.2.2 name=CLIENT1 profile=CLIENT1 send-initial-contact=no
add address=1.1.1.1/32 local-address=2.2.2.2 name=CLEINT2 profile=CLIENT2 send-initial-contact=no
add disabled=yes name=peer2 passive=yes profile=profile_2
add disabled=yes name=peer1 passive=yes profile=profile_1

/ip ipsec proposal
set [ find default=yes ] disabled=yes enc-algorithms=3des pfs-group=none
add enc-algorithms=aes-128-cbc name=CLIENT1
add enc-algorithms=aes-256-cbc lifetime=1h name=CLEINT2 pfs-group=modp1536

/ip dhcp-client add disabled=no interface=ether1

/ip firewall filter
add action=accept chain=input comment="ALLOW IPSEC" protocol=ipsec-esp
add action=accept chain=input comment="ALLOW IPSEC" protocol=ipsec-ah
add action=accept chain=input comment="ALLOW IPSEC" dst-port=500 log=yes protocol=udp
add action=accept chain=input comment="ALLOW IPSEC" dst-port=4500 protocol=udp
add action=accept chain=input dst-port=1701 protocol=udp
add action=accept chain=input comment="ALLOW IPSEC L2TP" dst-port=1723 protocol=tcp
add action=accept chain=input comment="ALLOW GRE" protocol=gre
add action=accept chain=input comment="ALLOW PING" protocol=icmp
add action=accept chain=input comment="ALLOW CLIENT1" dst-address=10.254.0.0/24 src-address=172.16.3.0/30
add action=accept chain=forward dst-address=172.16.3.0/30 src-address=10.254.0.0/24
add action=accept chain=forward dst-address=10.254.0.0/24 src-address=172.16.3.0/30
add action=accept chain=input comment="ALLOW CLIENT2" dst-address=10.251.0.0/24 src-address=10.14.0.0/16
add action=accept chain=forward dst-address=10.251.0.0/24 src-address=10.14.0.0/16
add action=accept chain=input comment="ALLOW SSTP" dst-port=443 protocol=tcp
add action=accept chain=input comment="ALLOW trafic from E1 (established)" connection-state=established in-interface=ether1
add action=drop chain=input comment="DROP trafic from E1 (all)" in-interface=ether1
add action=drop chain=input comment="DROP trafic from PPP (all)" in-interface=all-ppp

/ip firewall nat
add action=accept chain=srcnat comment="CLIENT1" dst-address=172.16.3.0/30 src-address=10.254.0.0/24
add action=accept chain=srcnat comment="CLIENT1" dst-address=10.254.0.0/24 src-address=172.16.3.0/30
add action=accept chain=srcnat comment=CLIENT2 dst-address=10.251.0.0/24 src-address=10.14.0.0/16
add action=accept chain=srcnat comment=CLIENT2 dst-address=10.14.0.0/16 src-address=10.251.0.0/24
add action=src-nat chain=srcnat comment=COMMENTS out-interface=ether1 src-address=192.168.111.0/24 to-addresses=2.2.2.2
add action=masquerade chain=srcnat comment=GW out-interface=ether1 src-address=!10.240.240.250
add action=masquerade chain=srcnat comment=COMMENTS dst-address=10.240.0.0/20
add action=masquerade chain=srcnat comment=COMMENTS dst-address=10.240.18.0/23
add action=masquerade chain=srcnat comment=COMMENTS dst-address=10.240.16.0/24 src-address=192.168.5.0/24
add action=masquerade chain=srcnat comment=COMMENTS dst-address=10.240.16.0/24 src-address=192.168.99.0/24
add action=masquerade chain=srcnat comment=COMMENTS dst-address=10.240.16.0/24 src-address=10.10.10.0/24
add action=masquerade chain=srcnat comment=COMMENTS dst-address=172.16.55.0/24 src-address=10.10.10.0/24
add action=masquerade chain=srcnat comment=COMMENTS dst-address=172.16.66.0/24
add action=masquerade chain=srcnat comment=COMMENTS dst-address=10.254.0.0/16 src-address=10.10.10.14

/ip firewall raw
add action=notrack chain=prerouting comment=CLIENT1 dst-address=172.16.3.0/30 src-address=10.254.0.0/24
add action=notrack chain=prerouting dst-address=10.254.0.0/24 src-address=172.16.3.0/30
add action=notrack chain=prerouting comment=CLIENT2 dst-address=10.14.0.0/16 src-address=10.251.0.0/24
add action=notrack chain=prerouting dst-address=10.251.0.0/24 src-address=10.14.0.0/16

/ip ipsec identity
Suggestion to use stronger pre-shared key or different authentication method
add peer=CLEINT2 secret=secret
Suggestion to use stronger pre-shared key or different authentication method
add peer=CLIENT1 secret=secret
add generate-policy=port-override peer=peer2 remote-id=ignore secret=verysecret
Suggestion to use stronger pre-shared key or different authentication method
add generate-policy=port-override peer=peer1 remote-id=ignore secret=test

/ip ipsec policy
set 0 disabled=yes
add dst-address=172.16.3.0/30 level=unique peer=CLIENT1 proposal=CLIENT1 src-address=10.254.0.0/24 tunnel=yes
add dst-address=10.14.0.0/16 level=unique peer=CLEINT2 proposal=CLEINT2 src-address=10.251.0.0/24 tunnel=yes

/ip route
add comment="comment" distance=15 gateway=99.99.99.99 pref-src=99.99.99.91 routing-mark=DSL1
add comment="comment" distance=16 gateway=88.88.88.88 pref-src=88.88.88.81 routing-mark=DSL3

/ip route rule
add action=lookup-only-in-table dst-address=0.0.0.0/0 src-address=192.168.99.252/32 table=DSL1
add action=lookup-only-in-table dst-address=0.0.0.0/0 src-address=192.168.77.23/32 table=DSL
add action=lookup-only-in-table dst-address=0.0.0.0/0 src-address=10.240.14.24/32 table=DSL
add action=lookup-only-in-table dst-address=0.0.0.0/0 src-address=10.240.14.21/32 table=DSL
add action=lookup-only-in-table dst-address=0.0.0.0/0 src-address=10.240.14.202/32 table=DSL

sindy

Guest

#10

16.08.2022 15:07:00

Если пинги вызывают увеличение счётчиков соответствующих raw-правил, значит трафик действительно доходит до вашего Mikrotik. Если при этом счётчик установленного SA (от вашего публичного адреса к адресу клиента) также растёт при пинге, значит политика IPsec совпадает и работает корректно. Но есть ещё одна возможность, я вижу, у вас мульти-WAN настройка. Что может происходить, и признаю, для этого нужно совпадение нескольких факторов: payload-трафик с обеих сторон прекращается на определённый период (по умолчанию 10 минут), из-за чего ESP-соединение пропадает из трекинга соединений; основной WAN выходит из строя; при этом какой-то payload-трафик с вашей стороны отправляется во время простоя основного WAN, то есть отправляется ESP transport пакет, но поскольку основной WAN недоступен, и отслеживаемого соединения нет, новое отслеживаемое соединение, созданное ESP пакетом, получает src-nat на адрес резервного WAN; если payload-пакеты продолжают приходить, это соединение с активным src-nat постоянно обновляется, и ESP пакеты продолжают приходить на приемник с неожиданного исходного адреса, даже если основной WAN восстановился. Поскольку Mikrotik не поддерживает MOBIKE, получатель просто игнорирует такие пакеты, а не перенаправляет SA на новый адрес. Вы можете использовать команду /tool sniffer ip-protocol=ipsec-esp ip-address=ip.of.the.client, чтобы перепроверить, через какой интерфейс и с каким исходным адресом выходят транспортные ESP пакеты при пинге.

mdd

Guest

#11

17.08.2022 10:42:00

Если пинги вызывают срабатывание соответствующих raw-правил, это значит, что трафик действительно доходит до вашего Mikrotik. Пакеты эхо-пинга отправляются с моего роутера, но обратно не возвращаются. Просто чтобы прояснить. Если соответствующий installed-sa (от вашего публичного адреса к клиентскому) тоже учитывается при пинге, значит, политика IPsec тоже работает. При пинге счетчики SA увеличивают количество байт только с моей стороны.

Но есть ещё одна возможность: вижу, что у вас настроено несколько WAN-линий. Что может происходить (и признаю, для этого нужно, чтобы совпало несколько факторов): с обеих сторон трафик перестаёт идти на определённое время (по умолчанию 10 минут), из-за чего ESP-соединение исчезает из трекинга соединений.

Как это проверить???

Основной WAN постоянно мониторится и не падает. Комментарии про DSL — это остатки, сейчас у вас все — оптоволокно. Пока не было сбоев. Резервные линии — только на случай аварии.

Для IPSEC у нас используется всего одна линия, например: IPSEC P2P OUTSIDE:1.1.1.3/30

Основной маршрут: 0.0.0.0 через 1.1.1.1, distance 1, предпочтительный источник 1.1.1.3.

Если с вашей стороны идёт какой-то трафик, пока основной WAN упал, отправляется ESP-пакет, но так как основной WAN недоступен и отслеживаемое соединение отсутствует, новое соединение, создаваемое ESP-пакетом, получает src-nat на адрес резервного WAN. Если пакеты трафика продолжают поступать, это соединение с активным src-nat продолжает обновляться, и ESP-пакеты приходят с неожиданного исходного адреса, даже если основной WAN уже восстановился.

Поскольку Mikrotik не поддерживает MOBIKE, получатель игнорирует такие пакеты, вместо того чтобы перенаправить SA на новый адрес.

Вы можете использовать команду /tool sniffer ip-protocol=ipsec-esp ip-address=ip.of.the.client, чтобы проверить, через какой интерфейс и с какого исходного адреса уходят ESP-пакеты во время пинга.

Я пытался захватить пакеты, но не поймал ни одного — ни с IP клиента, ни с локального IP, ни без фильтра.

Что это может быть? Пытался сбросить, отключить и включить IPSEC peers — пакеты не появляются. Соединения всё ещё показываются как установленные. ???

sindy Guest	#12 0 17.08.2022 10:54:00 Какая конкретно команда у тебя была для сниффинга (подставь только публичные IP-адреса, если они использовались в команде)?

mdd

Guest

#13

18.08.2022 11:12:00

/tool sniffer
set filter-ip-protocol=ipsec-eso
set filter-ip-address=.163 or .177
.163 — это мой шлюз, .177 — шлюз клиента

Хорошо, кажется, я просто переутомился. Сейчас пакеты были захвачены. И, похоже, пакеты ESP идут. Но опять же, похоже, в одну сторону... пока я пингую из подсети моего туннеля.

И правильно ли открыты пакеты с интерфейсом/публичными IP?

sindy

Guest

#14

18.08.2022 11:32:00

Я в замешательстве. Анализ пакета (самая нижняя картинка) показывает пакет от клиента к вашему Mikrotik (src-mac-address Cisco, dst-mac-address Mikrotik). Это значит, что трафик ESP идет только от клиента к вашему Mikrotik, так как никаких пакетов ESP с вашего адреса не отправляется. В таком случае получается, что трафик ESP с их стороны не вызван вашими пингами, и ваш Mikrotik его просто игнорирует.

mdd Guest	#15 0 19.08.2022 07:21:00 Какие есть варианты проверить это? Потому что все очень странно: я пингую, но трафика нет, а потом он вдруг появляется? Может, правила файрвола блокируют?

mdd Guest	#16 0 19.08.2022 08:23:00 Еще одно странное поведение: у ether1 GW несколько публичных IP — 162, 163, 16X. Для нескольких IPSEC туннелей я пытаюсь использовать только один — .163. По какой-то причине один из IPSEC клиентов с адресом .177 подключился к моему GW именно через .163, туннель установился, и трафик по нему теперь идет в обе стороны. Почему это вдруг заработало — не пойму. Но для другого клиента с адресом .75 мой GW пытается установить IPSEC туннель не через .163, а через .162. При этом у меня нет никаких настроек приоритета маршрутизации, которые могли бы вызвать такое поведение.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры