FAQ ROS 7: BGP

[gmx]

"...мы ночь разбудим светом горящих глаз."
Р. Жуков



Друзья!

Что-то давно я ничего не писал на тему микротика?
Отчасти это связано с текущей ситуацией. Купить микротик стало сложно и дорого.
К сожалению, основное конкурентное преимущество в виде цены, микротик сейчас потерял.
Точнее, цена стала не очень подъемной, хотя он по прежнему будет выгодной покупкой по сравнению с другими вендорами.
Это все лирика, конечно. Уж простите.

Сегодня в этой небольшой статье постараюсь рассмотреть вопрос настройки BGP в ROS 7.
Сразу скажу, что ROS7 я только начинаю изучать и использовать. Поэтому не знаю всех фишек и возможностей.
Если буду писать чушь, то не стеснитесь, поправляйте. А я буду вносить коррективы в текст.

Итак, задача:
получить список сетей (IP адресов) через BGP и трафик к ним отправить по другому маршруту.


Для чего это все?
Я не буду вдаваться в тонкости использования BGP. Не всегда эта функция нужна для очевидных вещей, ее можно использовать для других целей маршрутизации.
Информацию по "очевидному" использованию BGP читайте на ресурсах в Интернете, например, https://antifilter.download/ или https://antifilter.network/


Почему все не так просто?
С одной стороны, кажется, что все очень просто. Берем список, загружаем его в роутер и пользуемся. Но при первом же рассмотрении проблемы более детально, начинаешь понимать, что список адресов очень большой.
На 15.10.2022 список насчитывает более 120 тысяч строк. Представляете себе таблицу маршрутизации из такого количества строк.
Роутеры, которые смогут "пережЕвать" и потом продолжить работу можно пересчитать по пальцам.
Авторы вышеупомянутых ресурсов хорошо понимают эти проблемы, и они проделали большую работу по объединению адресов в подсети разной глубины.
Понятно, что в таком случае в список может попасть IP не заблокированного ресурса, но управлять такими списками, конечно, легче. В целом, чем короче список, тем легче роутеру и человеку, но тем больше вероятность, что в список попадет ресурс, который
не заблокирован или, того хуже, этот ресурс не открывается через VPN. Такую проблему и пути ее решения мы ниже рассмотрим.

Далее в тексте я буду делать примеры, предполагающие использование https://antifilter.download. Переделать под другого постащика, я думаю, проблем не составит.


Итак, начнем.

1. Вы уже обновили ваш роутер до самой последней версии ROS7.
2. Вы подключили VPN, ну или альтернативный маршрут. И если у вас это VPN, который не формирует в ROS отдельного интерфейса, то вы и сами лучше меня все это знаете. Данный мануал рассчитан на новичка.
3. Вы проверили, у вас все работает. Работает и интернет, и VPN.
4. Вы используете публичный DNS. Не важно где он у вас настроен. На конкретном устройстве или на микротике и вы его раздаете по DHCP. Это все не важно. Главное, чтобы он у вас был. Вы также понимаете, что публичные, особенно импортные DNS могут совсем не
резольвить или резольвить неправильно некоторые важные отечественные сайты. Например, сайты Госуслуг или Сбера. Тут уж придется выбирать и искать. В целом Yandex DNS резольвит все верно и пока он не был замечен в каких либо блокировках импортных ресурсов, но вы должны помнить, что Yandex DNS совсем не анонимный.
5. В принципе настройка BGP - это одна строчка в конфиге.

Код: Выделить всё

/routing bgp connection

add as=64514 disabled=no hold-time=4m input.ignore-as-path-len=yes keepalive-time=1m local.address=192.168.220.220 .role=ebgp multihop=yes name=bgp1 remote.address=45.154.73.71/32 .as=65432 routing-table=main

где, 192.168.220.220 - это локальный IP адрес вашего микротика. В принципе этот адрес может быть вообще любым.
45.154.73.71 - это IP адрес сервиса BGP antifilter.download
65432 - номер автономной системы antifilter.download
Последние два параметра жестко выдает ресурс, который предоставляет сервис BGP. Ищите эту информацию на сайте сервиса. На https://antifilter.download/ эта информация расположена внизу главной страницы.

64514 - это номер вашей автономной системы, который вы придумаете сами так, чтобы он был из диапазона от 1 до 65534 и отличался от номера встречной системы, то есть использовать 65432 нельзя.
Правда, согласно рекомендациям RFC6996 диапазон для частного использования вот такой 64512-65543, но это пока только рекомендация.

Вот так это выглядит в виде скринов:

Routing-BGP-синий плюсик.


И...

Надо немного подождать. По разному, от нескольких секунд, до нескольких минут.
Далее заходим в IP-Routes и видим следующую картину.



Обратите внимание на количество маршрутов внизу в строке статуса. Цифры у всех будут разные. Во-первых, сам BGP список постоянно меняется, а во-вторых, у вас же были свои маршруты, которые вы использовали до этого.

Щелкните дважды любой из вновь созданных маршрутов:



Обратите внимание, микротик создавая маршрут сам попытался подобрать для него шлюз и поставил дистанцию 20. В некоторых конфигурациях (особенно, если у вас настроен Wireguard), микротик правильно выбирает в качестве шлюза именно интерфейс ВПН. Но, будет лучше, чтобы вы сами контролировали это процесс. Как это можно сделать в микротике?

Теоретически, на вкладке Extra в настройках BGP можно выбрать таблицу маршрутизации, которую вы специально создадите для этого. Но проблема в том, что как бы я не пробовал менять параметры на этой вкладке - эти параметры не применяются микротиком. Говорят, что разработчики знают об этом, и процесс разработки идет постоянно. Когда-то точно доделают.

Единственный параметр, который работает - это Input Filter на вкладке Filter.

Фильтр создается в Routing-Filters вкладка Rule. Синий плюсик.



В поле Chain впишите название вашего фильтра (придумайте сами).
А в поле Rule впишете текст:

Код: Выделить всё

set gw wireguard1; accept

Дословно эта команда означает: установить каждой строчке маршрута шлюзом интерфейс wireguard1, и принять эту строчку (то есть не игнорировать).

Вам нужно вписать имя своего интерфейса ВПН, естественно.
В качестве шлюза можно использовать его IP адрес. Не буду вдаваться в подробности, чаще всего это IP адрес удаленной стороны в туннеле.

Терминальная команда выглядит так:

Код: Выделить всё

/routing filter rule
add chain=bgp2 disabled=no rule="set gw *0x9; accept"

Вот попробуй догадайся, что "wireguard1" у меня в микротике на самом деле "*0x9"
Поправят, наверное, когда-нибудь.

Осталось в созданной записи BGP выбрать фильтр. Routing-BGP, далее щелкните дважды нужную строчку с параметрами BGP подключения. Перейдите на вкладку Filter. В поле Input Filter выберите нужный фильтр.





Обратите внимание, что шлюз в маршрутах уже поменялся.




Ну, собственно, все!
Можно проверять работу маршрутов.


6. Замечание первое.

Сам BGP ресурс, к которому мы подключается, может быть тоже заблокирован. Поэтому маршрут до него тоже может быть проложен через ВПН.

/ip route add dst-address=45.154.73.71/32 gateway=wireguard1




Обратите внимание, в поле Gateway нет раскрывающего списка, в котором можно было бы выбрать подходящий интерфейс, придется его название вписывать вручную. Естественно, можно использовать IP адрес.

Ну, и конечно же, вы понимаете, что за этим надо следить, и если IP адрес поменяется, его придется менять вручную.

7. Как обойти BGP маршруты?.

Что же делать, если в префиксы попали ресурсы, которые не открываются через ВПН?
Их надо в ручном режиме отправить по обычному маршруту.
И это в принципе не сложно, но это ручной труд, то есть нужный ресурс (домен) с его поддоменами (если есть) придется вручную добавлять в соответствующий адрес лист.

Сначала создадим адрес лист.
Нажмите IP-Firewall-Address List. Затем синий плюсик.



В поле Name впишите название адрес листа. У меня mimobgp.
В поле Address - URL нужного сайта.

Добавьте таких записей столько, сколько вам нужно.

Создайте новую таблицу маршрутизации. Для этого выберите Routing-Tables. Затем синий плюсик.



В поле Name введите название таблицы. Галочка FIB должна стоять.

Ок. Осталось совсем немного.

Нажмите IP-Firewall вкладка Mangle, синий плюсик.

В поле Chain выберите prerouting. В поле Dst. Address List в раскрывающемся выберите название адрес листа, который вы недавно создали.
На вкладке Action в поле Action выберите mark routing, а в поле New Routing Mark из списка выберите называние таблицы маршрутизации из предыдущего шага.

Ок.

Ну и последний шаг.
Нажмите IP-Routes. Синий плюсик.
В поле Dst. Address введите 0.0.0.0/0 (то есть весь интернет).
В поле Gateway введите вручную название вашего Wan интерфейса или IP адрес шлюза. Подсмотрите его на похожем правиле с Dst. Address 0.0.0.0/0.
В поле Routing Table из списка выберите название таблицы маршрутизации, которую создали чуть ранее.



Вот и все, можно проверять.

Что делать, если обход BGP маршрутов не работает? Убедитесь, что в Firewall-Mangle нужные вам сайты не попадают в другие правила маркировки. Это нужно исключить. Если разобраться будет трудно, то поднимите (перетащите) нужное правило в самый верх, а на вкладке Action отключите галочку Passthorough. Правда, если у вас много правил маркировки, не думаю, что вы нуждаетесь в моих подсказках.
Еще стоит убедиться в том, что шлюз указан верно, еще раз сверьте его с правилом, которое у вас работало как "основной шлюз" до всех наших манипуляций.

8. Замечание второе.

Вы можете поглядеть статус подключения BGP на вкладке Sessions в Routing-BGP.
Но есть ряд нехорших "но".



Поглядите на скрин. То, что обведено красным. Мы получили более 10000 префиксов, а в таблице написано 0, и Uptime не может быть таким большим, я за последний час много раз включал и выключал сессию BGP, а у нее написано 496 дней.
Пока эта строчка не очень-то информативна. Хотя в целом, если она здесь появилась, а левом столбце есть буква E (established), то можно говорить, что соединение с BGP системой установлено.

9. Ну и последнее.

Вы уже поняли, что на сегодняшний день (час) мы получаем более 10000 префиксов. Напомню, что это не конкретные адреса, а целые подсети. Понятно, что для большинства задач этот список избыточный. Там много всего лишнего и редко используемого. Стараниями спецов https://antifilter.download был создан телеграм канал, где пользователи сами предлагают добавить тот или иной адрес в список и открывается голосование. Если наберется более 15 голосов "за", то адрес будет добавлен в список. На сегодня там около 700 записей. Так сказать, только самое необходимое. Все ссылки, вы найдете на странице https://antifilter.download

Осталось разобраться, как получить по BGP только этот список.
Сразу скажу, что на сегодняшний день (ноябрь 2022 года) штатным образом эта функция в микротике не работает, но есть обходные пути.

Префиксы в таблице BGP могут быть помечены специальной меткой - bgp community. В данном случае метка имеет значение 500, то есть нужный нам список имеет полный индекс 65432:500.

Отфильтруем эту комюнити, а другие префиксы проигнорируем. Делать это будем через Routing-Filters. На вкладке Rule мы уже ранее создали фильтр для нашего списка. Поправим его. Щелкните на него дважды и измените поле Rule.

Код: Выделить всё

set gw wireguard1; 
if (bgp-communities includes 65432:500) { accept; } else { reject; }

Иными словами мы разрешили роутеру принимать строки с меткой 65432:500, а все остальное он должен игнорировать.

И он их игнорирует, но делает это по своему. Он все равно загружает полный список правил, но те, которые он "игнорирует" он исключает из маршрутизации и помечает их в WinBox красным цветом.



Возможно такое поведение полностью правильное. Для обеспечения целостности списка роутер загружает его полностью. А возможно, функционал просто не доделан. Посмотрим, может разработчики что-то поправят.

На этом пока все!

[Vapix]

Ваше решение, на мой личный взгляд, имеет ряд недостатков. Главный недостаток, что оно создаёт огромну таблицу маршрутов, а это не нужно, все они ведут в одну точку (в тот VPN, или интерфейс, который поднял юзер). Это всё гораздо проще и дешевле (с точки зрения ресурсов) сделать через Mangle, через тот же лист с соответствующим списком IP, подтянутым с того же ресурса. А маршрут с этой меткой прописать один. Причём первым правилом поставить whitelist и маркировать там всё в цепочку main (заснести туда ресурсы, котрый блочатся излишне, и на которые вы однозначно хотите выйти со своего IP), а вторым в лист блокировок, который маркировать в цепочку указывающую на VPN, и не забыть в обеих правилах убрать галку forward (во многих мануала про это забывают, и получают дублирование трафика, или вообще нерабочую схему).



Mangle работает в прероутинге. Маркировка не занимает много памяти и времени СPU, листы хоть в 100k записей будет обрабатывать даже самый хилый домашний девайс. И главный плюс - работает FastPath (правда нужно настроить на ваши интерфейсы и прописать как для входящего так и исходяшего установленных соединений).



Тогда уже установленные соединения оффлоадятся полность хардварно, тот же hEX спокойно качает гигабит с разделением трафика на прямой и VPN Wireguard по тому самому списку. Подробную настройку могу изложить в ЛС, схема рабочая и обкатанная, работает без тормозов вообще с любым по размеру листом. Возможно даже выпущу мануал, т.к. те что я встречал писали видимо не совсем понимающие люди, предлагая то отключение FastPath (а это хана процам домашних железок сразу), то ещё какую то дичь.
P.S. По BGP имеет смысл получать маршруты ведущие в разные точки, для целей же направить трафик по листу в один VPN, абсолютно никакой разницы по какому протоколу получить этот самый список адресов нет. Единственное, заранее вписать адрес с котрого забирать в списк сразу, это абсолютно правильно.

[xvo]

1) Как раз таки маршрутизация требует намного меньше ресурсов, чем firewall (mangle).
Тем более, чем проверка по списку из десятков и сотен тысяч адресов.
А "огромная таблица маршрутов" - это абсолютно типичная задача для маршрутизатора.

2) Именно мангл не совместим с fasttrack, а маршрутизация - совместима.
То что вы что-то там отдельно помечаете не имеет никакого значение - пакеты единожды помеченного для fasttrack соединения вы уже никак, кроме как по таблице main не пустите. Mark routing для них уже работать не будет. А в 7ке, так уже даже и routing cache отсутствует, так что соединения будут перетекать в main сразу, а не с задержкой.

[Vapix]

1) Как раз таки маршрутизация требует намного меньше ресурсов, чем firewall (mangle).
Тем более, чем проверка по списку из десятков и сотен тысяч адресов.
А "огромная таблица маршрутов" - это абсолютно типичная задача для маршрутизатора.

2) Именно мангл не совместим с fasttrack, а маршрутизация - совместима.
То что вы что-то там отдельно помечаете не имеет никакого значение - пакеты единожды помеченного для fasttrack соединения вы уже никак, кроме как по таблице main не пустите. Mark routing для них уже работать не будет. А в 7ке, так уже даже и routing cache отсутствует, так что соединения будут перетекать в main сразу, а не с задержкой.

Вы неправы:
по п.1: mangle в прерутинге работает только на этапе установки соединения, таким образом он отрабатывает один раз, помечая соединение при его установлении, роутинг же будет это делать попакетно обрабатывая заголовки. Огромная таблица маршрутов - для энтерпрайза может и типичное использование, для домашних же устройств это нетипично, у 90% юзеров там что обычно?! Пара строк: 0.0.0.0/0 - внешний интерфейс, 192.168.88.0/24 - bridge.... всё.

по п.2: часто вижу заблуждение что fasttrack несовместим с mangle, это вкорне неверно, и такие выводы пишут те, кто пытается работать с mangle и дефолтными настройками fastrack, и конечно там это не заработает т.к. туда завернётся весь трафик, (дефотное правило fasttrack, если оно создано, например через быструю конфигурацию, подлежит удалению обязательно!). Это всё ясно написано в оригинальных манах, но их реально мало кто вдумчиво читает. fastrack нужно настроить только на обработку установленных соединений причём в обе стороны и строго между вашей сетью и интерфейсом в инет (см. приложенную картинку выше в посте). Установленное соедиение останется в той цепи для котрой оно промаркировано, и да вы конечно правы, оно в mangle больше действительно не попадёт, и не надо! Именно это и обеспечивает быстродействие такого решения. По факту трафик в manglе будет единицы пакетов, только при открытии соединения. Я разумется тестировал быстродействие по схеме автора статьи и по своей, на одном и том же VPN, с одним и тем же списком, и сравнивал нагрузку на процессор. И особенно разница видна в использовании памяти, я вообще не увидел что даже большая таблица маркировки как то существенно грузит память, в вот таблица роутигна очень даже.

Пруфы: трафик mangle при открытии сайта из листа с кучей картинок и прочего контента (через main он недоступен, ибо РКН), загруз проца околонулевой.

Решение разумеется полностью рабочее и проверено на RouterOS 7.7rc4.

[xvo]

Если бы вы понимали, как это работает, то вряд ли писали подобные опусы.

по п.1: mangle в прерутинге работает только на этапе установки соединения, таким образом он отрабатывает один раз, помечая соединение при его установлении, роутинг же будет это делать попакетно обрабатывая заголовки.

Пометить соединение не достаточно.
Вы сначала помечаете соединение, потом вы попакетно отлавливаете те пакеты этих соединений, которые нужно завернуть в туннель.
Итого: нагрузка от firewall уже ровно втрое от обычной (к обычному правилу accept established/related добавляются два правила mangle).
Это в идеале.
Примерно оно у вас и на картинке.
Только вы ещё вместо того, чтобы использовать "легкие фильтры" на новые соединения и дальше - только помеченные соединения, прогоняете весь трафик сразу через тяжелый фильтр по своему списку.
Талантливо.
Это к вопросу про умение работать с mangle.

у 90% юзеров там что обычно?! Пара строк: 0.0.0.0/0 - внешний интерфейс, 192.168.88.0/24 - bridge.... всё.

И? У 90% юзеров в mangle вообще пусто.

На практике домашние железки без проблем переваривают антифильтровскую таблицу.
И гонят по ней трафик без особого влияния на производительность.

и строго между вашей сетью и интерфейсом в инет (см. приложенную картинку выше в посте).

Гениально! То есть вы научились очевидному - исключать из fasttrack трафик, который вам надо завернуть мимо основной таблицы (без чего он туда вообще не завернется). Немного корявым способом, конечно - обычно достаточно просто в дефолтное правило добавить условие routing-table=main, а не городить огород из разных условий на интерфейсы. И основываясь на том, что у вас такого трафика копейки по сравнению с остальным трафиком, продолжающим лететь по таблице main с использованием fasttrack, вы делаете умозаключение, что mangle вам не нагружает железку?

В итоге, вся "рабочесть" вашего решения (что по п1, что по п2) строится только на одном - у вас просто очень мало трафика, который вы заворачиваете в туннель и который у вас идет мимо fasttrack'а.
Стоит нагрузить - железка загнется.

И да, если вдруг у вас появится необходимость отключить fasttrack и для остального трафика по какой-то причине (очереди там, например, или балансировка пары провайдеров) - у вас без оптимизации mangle станет все ещё печальнее.

[xvo]

И ещё разок.

Тут ни для кого не откровение, что в отличие от бытовых роутеров, работа с fasttrack в микроте - это не галка вкл/выкл, а управляемый процесс.
Но это безусловно похвально, что вы самостоятельно дошли до данного "решения".
Каждый второй тут что-то подобное так или иначе использует.
Правда обычно в варианте "завернуть в туннель доступ к какому-нибудь сервису, который за роутером с серым адресом, и доступ куда нужен раз в месяц от силы" и т.д.

А вот заводить разговор о сравнении производительности двух решений, одно из которых работает всегда и для любого трафика одинаково, а достоинство второго только в том, что оно ничего не портит, когда не используется, как минимум странно.

И чтобы не быть голословным, пара картинок:

1) Только свои маршруты (всего 153шт):



2) Маршруты полученные по BGP (всего 10944шт):



То есть прирост нагрузки всего в рамках 15-20%
И это работает для любого трафика, независмо от его назначения.
Плюс сохранена возможность применить fasttrack опять же для всего трафика (конкретно в данном случае он не используется).

Что у вас будет, если вы пустите трафик через свой мангл - можете проверить самостоятельно.
В принципе, для чистоты эксперимента, чтобы не считать нагрузку вносимую самим туннелем, достаточно сделать два теста на основном канале - с fasttrack'ом и без.
Я думаю результаты будут понятны.

[Vapix]

Что у вас будет, если вы пустите трафик через свой мангл - можете проверить самостоятельно.
В принципе, для чистоты эксперимента, чтобы не считать нагрузку вносимую самим туннелем, достаточно сделать два теста на основном канале - с fasttrack'ом и без.
Я думаю результаты будут понятны.

Теперь те же самые картинки делаете на hEX с его 256 мегабайтами памяти и mips процом (раз уж он у вас в профиле имеется), картинки с нагрузкой на ентерпрайс железку вообще из другой оперы.
И разумеется, я делал тесты без fastrack и с включенным fastrack, при включеном magle, как раз на hEX, вполне ожидаемый результат что с отключенным больше 200 мегабит не вытягивает на загрузку, и грузит проц под 100%.






Обязательно проведу всесторонние тесты как и при каких нагрузках это всё будет работать.

конечно - обычно достаточно просто в дефолтное правило добавить условие routing-table=main

Ну ну, вы сами то это пробовали? Или теоретик? Читайте маны, добавление в правила fasttrack любый условий, кроме интерфейсов, fasttrack отключает и он начинает работать как обычный софтовый форвард по long path. Я сам, когда начинал, на эти грабли вставал и удивлялся. Прежде чем писать, хотя бы попробуйте на железе включить и глянуть результат. И, плз, тестируйте на железе где видна разница при хардварном оффлоате трафика, а не на ARM c двумя гигами памяти, который, предположу, вытянет и 10 гигабит чисто софтово.

P.S. автор статьи, кстати, для вайтлиста предлагает использовать mangle, если вы не заметили. И какая тогда разница, два там правила или одно? И ещё раз напишу, что mangle в связке с fasttrack отправит через себя лишь исходящие запросы, а для нашей задачи входящий трафик основной. Единственный вариант, когда эта схема может положить проц, это большой исходящий трафик в туннель. Надо будет проверить, попробую поднять Iperf на vps где установлен wireguard, за эту наводку вам, xvo, благодарность, но для домашнего юзера это уж точно совсем нетиповой трафик, а решение предлагается именно домашнему юзеру.

Но думаю что для проца это будет по нагрузке будет примерно то же самое что и обрабатывать таблицу роутнига.


Вот пример загрузки файла через тоннель, загрузка на проц винда, как и то что трафик в целом через mangle небольшой = исходящему. На большей скорости не нашёл кто может отдать.

Предлагаю таки спор закрыть, решения оба рабочие и проц не грузят на трафике что через прова что через туннель, каждое имеет свои плюсы и минусы.

[xvo]

И разумеется, я делал тесты без fastrack и с включенным fastrack, при включеном magle, как раз на hEX, вполне ожидаемый результат что с отключенным больше 200 мегабит не вытягивает на загрузку, и грузит проц под 100%.

О чем и речь: при попытке запустить весь трафик в туннель с использовании маршрутов производительность упадет НА 20% от исходной, при использовании mangle - плюс-минус в 5 раз, т.е. ДО 20% от исходной.
Так что все зависит от того, насколько много всего вы заворачиваете в туннель.
Если у вас там полтора сайта в третью пятницу каждого месяца, то разумнее завернуть их через мангл, чем потерять 1/5 производительности для остального.
Если же у вас все-таки значимая часть трафика ходит через туннель (а нехитрая математика показывает, что значимая - это начиная от примерно 1/5 : 5 = 1/25 от всего трафика), то вариант с маршрутами, даже не говоря об простоте и удобстве использования, выгоднее чисто с точки зрения производительности.

Теперь те же самые картинки делаете на hEX

А практический смысл какой?
Увидеть, что CPU вместо условных 60% загрузится на 75%? Или вместо 800мбит заткентся на 650мбитах, при прочих равных?
Или вы предполпгаете на hEX’е какие-то другие проценты?
Нет у меня сейчас hEX’а на быстром канале, который можно под тесты переконфигурировать. Все либо на другое настроены, либо висят на 100мбит канале.

Так что, уверен, раз вам это интересно, и вы все равно собрались досконально в этом разобраться, и именно на hEX’е - вам не составит труда к своим тестам добавить и тест с полученными по bgp от антифильтра маршрутами.

[xvo]

Ну ну, вы сами то это пробовали? Или теоретик? Читайте маны, добавление в правила fasttrack любый условий, кроме интерфейсов, fasttrack отключает и он начинает работать как обычный софтовый форвард по long path.

Ну и бред.
Пробовал неоднократно.
С предсказуемым результатом.
На половине машин, где вообще используется fasttrack - есть это исключение, потому что часть трафика ходит по дополнительным таблицам маршрутизации.

И ещё раз напишу, что mangle в связке с fasttrack работает не попакетно, а единожды при окрытии соединения. Попакетно оно будет работать для UDP трафика, возможно для него будет лучше таблица роутнинга.

И снова лютейший бред. Какая тут вообще разница, какой протокол?

Вы хотя бы на счетчик пакетов посмотрите на своём правиле. Сбросьте его и запустите пинг на один из адресов вашего списка.

Это и первого вопроса тоже касается.
Пробуйте и смотрите счетчики.

А спор мы с вами действительно прекратим.
Очевидно он получается несколько выше уровня вашей компетенции.

[Vapix]

Частично согласен, пост поправил, да исходящие пакеты пойдут все через mangle, убедился, картинку приложил. У меня включение правила main в fasttrack его убивает, даже просто на свежесброшенном роутере, без всего, с одним лишь pppoе. Возможно это ограничение домашней железки, возможно в энтерпарайз девайсах такого ограничения нет, но про это ограничение много где написано. Возможно я не умею его готовить. Пруфы в картинках. Проверяйте. В любом случае, ваши замечания принял, попробую разные варианты, для варианта когда нет большого исходящего трафика на туннель, думаю что большой разницы действительно нет.
Ваши предлжения тогда по добавлению вайтлиста? Это можно сделать без mangle с BGP?