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

Использование NoTrack для туннеля WireGuard

Использование NoTrack для туннеля WireGuard, RouterOS

msatter

Guest

25.08.2022 18:58:00

Я заметил, что ускорение обработки туннеля WireGuard не влияет на счётчики dummy — они не увеличиваются. Значит трафик разделяется и обрабатывается напрямую. Потом вспомнил, что то же самое делается и для IPSEC. Однако это может заметно нагрузить процессор роутера, если много туннелей и значительный трафик на каждом из них. Решение — использовать IP/Firewall/Raw для обхода отслеживания соединений, тем самым исключая необходимость фильтрующих правил, упомянутых выше, и снижая нагрузку на процессор примерно на 30%.

/ip firewall raw add action=notrack chain=prerouting src-address=10.1.101.0/24 dst-address=10.1.202.0/24
add action=notrack chain=prerouting src-address=10.1.202.0/24 dst-address=10.1.101.0/24

Источник: https://help.mikrotik.com/docs/display/ROS/IPsec

Так что я сделал notrack для prerouting и ещё для output в RAW, и WireGuard продолжил работу как раньше. Ты не увидишь строки в connection tracking, а нагрузка, возможно, снизится. Может быть, даже до 30%, как упоминалось выше.

Simonej

Guest

25.09.2022 17:45:00

Дорогие пользователи, пытался настроить NoTrack по советам @msatter и @sindy для WireGuard в режиме Road Warrior, перечитал несколько раз и провёл множество тестов — безуспешно. Вот часть конфигурации фаервола, которая касается этого:

/interface wireguard add listen-port=13231 name=WireGuard private-key="..." disabled=no
/interface wireguard peers add allowed-address=10.10.10.2/32 endpoint-port=13231 interface=WireGuard public-key="..." disabled=no
/ip address add address=10.10.10.1/30 interface=WireGuard network=10.10.10.0

/ip firewall raw add action=notrack chain=prerouting interface=WireGuard

/ip firewall filter add action=accept chain=input connection-state=established,related,untracked
/ip firewall filter add action=accept chain=input dst-port=13231
...
/ip firewall filter add action=accept chain=forward connection-state=established,related,untracked
/ip firewall filter add action=accept chain=forward connection-state=untracked interface=WireGuard out-interface-list=LAN
/ip firewall filter add action=accept chain=forward connection-state=untracked interface=WireGuard out-interface=WAN

Цель — проверить, позволит ли обход трекинга соединений сэкономить ресурсы CPU. Я могу подключиться через туннель, но при этом не получается выйти в интернет или к устройствам в LAN. Делал что-то не так?

msatter

Guest

26.09.2022 07:49:00

«В общем, вы можете использовать notrack для туннеля Wireguard, но только там, где не нужен NAT, то есть обычно для site-to-site подключения.» Я вижу, что RouterOS вполне справляется с этим без проблем. Вот как я это понимаю: роутер выступает в роли клиента WG, роутер инициирует UDP-соединение с сервером через NAT, RouterOS ждёт ответ после RAW/connection tracking, перехватывает возвращающееся соединение и самостоятельно с ним работает. Это касается только UDP-туннеля WG, при этом известен IP-адрес назначения и источник возвращающегося трафика WG-туннеля.

sindy

Guest

26.09.2022 08:08:00

@msatter, то, что ты написал, касается транспортных пакетов Wireguard и, конечно, правильно, но я совсем забыл про этот уровень, так как @Simonej ставит правила в цепочку forward и ссылается на WireGuard как на входящий интерфейс в prerouting, поэтому я предположил, что он хочет отключить отслеживание соединений для пакетов с полезной нагрузкой Wireguard. @Simonej, ты видишь разницу между двумя типами пакетов, о которых шла речь выше?

Simonej

Guest

26.09.2022 09:06:00

Очень хорошо объяснено, спасибо, @sindy. Мой случай — первый, который ты упомянула: Wireguard "сервер", предоставляющий "клиенту" доступ в интернет. Я ещё раз протестирую с твоим предложением и отчитаюсь. Нет, извини. Комментарий @msatter относится к конкретному случаю site-to-site? @msatter, не мог бы ты показать пример из своей конфигурации?

sindy

Guest

26.09.2022 09:24:00

Видимо, совсем плохо объяснили, так что позвольте упростить: если требуется NAT для полезной нагрузки (как в вашем случае), то отключить отслеживание соединений для трафика Wireguard нельзя. Но вы можете исключить из отслеживания соединений транспортный трафик Wireguard, поскольку для него NAT не нужен. Полезная нагрузка – это то, что передаётся внутри туннеля; транспортный трафик – это трафик между устройствами, которые формируют туннель (он состоит из пакетов, в которые заключена полезная нагрузка).

anav

Guest

26.09.2022 13:38:00

В чём преимущество возможности не трекать транспортный слой WireGuard (а не слой полезной нагрузки) по сравнению с полным отказом от использования notrack? Другими словами, это скорее академический вопрос — интересно и круто, насколько детально можно управлять такими вещами, но вряд ли это действительно практично.

sindy

Guest

26.09.2022 14:07:00

Чтобы сэкономить ресурсы процессора. Если подавляющее большинство трафика, который обрабатывает устройство, приходится на Wireguard, пропуск отслеживания соединений для пакетов транспортного уровня Wireguard означает, что фаервол не будет проверять каждый транспортный пакет по полному списку отслеживаемых соединений. Полностью отключить отслеживание соединений нельзя, если вам нужен NAT.

anav

Guest

26.09.2022 14:20:00

Что именно экономить — неясно, 1% от нагрузки или 20%. Для этого нужно знать, сколько CPU обычно занимает активность Wireguard. И в относительном сравнении с любым другим трафиком, чтобы понять масштаб. Потом важно знать, какая у роутера производительность CPU (возможно, стоит учесть и доступную оперативную память). Пытаюсь понять, насколько экономия существенная. Я предполагаю, что если она значительная, то все бы так и делали по умолчанию для любой настройки MT.

sindy

Guest

#10

26.09.2022 14:33:00

Точно. Чтобы отличить одно от другого, нужна лабораторная установка — создать туннель Wireguard между двумя устройствами на столе с некоторыми правилами файрвола, включающими отслеживание соединений, использовать программу для тестирования пропускной способности (не /tool bandwidth-test на той же паре роутеров), а потом исключить пакеты Wireguard из отслеживания соединений и снова измерить пропускную способность.

anav

Guest

#11

25.09.2022 18:28:00

Каких улучшений в производительности процессора вы ожидаете? Как вы понимаете, что производительность процессора ограничена WireGuard и это влияет на другие задачи или пользователей? Мне кажется, это пустая трата времени... если есть явное преимущество у описанного выше подхода, которое работает в большинстве случаев, то это должно быть включено в любой справочник.

Simonej Guest	#12 0 25.09.2022 20:03:00 Согласен, @anav, ничего не жду, скорее всего, будет пустая трата времени, но это просто для учебы и тестирования. PS: надеюсь, что после урагана у всех всё хорошо, желаю всего самого лучшего всем канадцам.

anav

Guest

#13

25.09.2022 20:07:00

На этот раз нам повезло больше по сравнению с нашими соседями на востоке — Кейп-Бретоном, Островом Принца Эдуарда и некоторыми районами Ньюфаундленда. Всё нормально, просто интересно было узнать, насколько это серьёзно…

sindy Guest	#14 0 26.09.2022 06:56:00 Во время prerouting исходящий интерфейс ещё неизвестен. Поэтому ваше правило action=notrack в /ip firewall raw срабатывает только на пакеты, пришедшие через интерфейс WireGuard; пакеты в обратном направлении той же реальной сессии всё ещё обрабатываются модулем отслеживания соединений. Чтобы исключить отслеживание и для них, нужно сделать другие правила в цепочке prerouting в raw, которые будут фильтровать по src-address(-list), dst-address(-list), протоколам, портам — в зависимости от того, как вы выбираете трафик для WireGuard. Конечно, использовать connection-mark нельзя, но нельзя даже packet-mark или routing-mark, потому что они присваиваются после того, как пакет проходит через raw. А сопоставление с address-list по нагрузке примерно равно сопоставлению с connection list. Вы не предоставили достаточно информации, но похоже, что вы хотите, чтобы Mikrotik выступал как WireGuard «сервер», предоставляющий «клиенту» доступ в интернет; если это так, то добавление правила chain=prerouting in-interface=WAN dst-address=10.10.10.2 action=notrack в /ip firewall raw позволит не отслеживать любой пакет, который приходит через WAN на адрес WireGuard «клиента», и такой пакет примется в filter правилом «accept untracked». Однако, если я не ошибаюсь, это все равно не сработает — вы не сможете отключить отслеживание соединений для такого трафика, потому что вам нужно делать NAT, а NAT зависит от отслеживания соединений. Если Mikrotik выступает как WireGuard «клиент», обеспечивая зашифрованное подключение к интернету для локальных устройств через удалённый «сервер», то allowed-address в строке /interface wireguard peer должен быть 0.0.0.0/0, а не только отдельный внутренний адрес «сервера». И даже в этом случае без NAT работать не будет, потому что в этом сценарии нужно делать NAT с LAN-клиентов на 10.0.0.1. В итоге — notrack для туннеля WireGuard применять можно, но только там, где NAT не нужен, обычно это site-to-site туннели. Независимо от всего вышеперечисленного, последние два правила из вашего списка бессмысленны, так как их «перекрывает» третье правило, которое принимает любой неотслеживаемый пакет, независимо от in-interface и out-interface(-list). Условие connection-state совпадает с любым из состояний соединения (которые взаимоисключающие, так как у каждого пакета ровно одно состояние соединения).

Читают тему

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