PBR и WoT

Обсуждение ПО и его настройки
Ответить
ooptimum
Сообщения: 3
Зарегистрирован: 05 фев 2018, 09:16

Дано: 2 канала в Интернет через 2 различных провайдеров и желание поиграть в танки. Один из каналов безлимитный, шлюз в сети этого провайдера является на микротике шлюзом по умолчанию, но этот канал несколько перегружен, имеют место потери пакетов, иногда довольно существенные, и поскольку почти все данные в игре передаются по UDP, не предоставляющем информации о доставке пакетов, играть дискомфортно - частые лаги, зависоны и прочее. Очевидным решением является пускать все соединения с серверами Wargaming через второго провайдера, где нет потерь пакетов и довольно комфортное значение пинга до серверов.

Все сделано следующим образом: все новые соединения с серверами Wargaming маркируются файрволом и затем эти соединения маршрутизируются через шлюз второго провайдера (Policy Based Routing - PBR):

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

/ip address
add address=198.51.100.22/24 comment="Му 2nd ISP" interface=ether2 network=198.51.100.0

/ip firewall address-list
add address=64.94.253.0/24 list=Wargaming
add address=74.201.99.0/24 list=Wargaming
add address=92.223.0.0/17 list=Wargaming
add address=185.12.240.0/22 list=Wargaming

/ip firewall mangle
add action=mark-connection chain=prerouting connection-state=new dst-address-list=Wargaming new-connection-mark=WoT passthrough=yes
add action=mark-routing chain=prerouting connection-mark=WoT dst-address-list=Wargaming new-routing-mark=My2ndISP passthrough=yes

/ip firewall nat
add action=src-nat chain=srcnat out-interface=ether2 to-addresses=198.51.100.22

/ip route
add distance=1 gateway=198.51.100.1 routing-mark=My2ndISP


При этом все работает, но любое действие в игре происходит с большими задержками. Например, снятие/установка оборудования или пересадка членов экипажа длится секунд 10. В бою танк часто просто не реагирует на нажимаемые клавиши или реагирует с очень большой задержкой - можно начать двигаться вперед и так и продолжать двигаться, пока куда-нибудь не упрешься, несмотря ни на что. Если же все 4 подсети из списка Wargaming маршрутизировать самым обычным образом через /ip route, то все работает без нареканий. Очевидно, что проблема в моих настройках PBR на микротике. При этом я уверен, что в обоих случаях пакеты идут в нужный интерфейс и mikrotik имеет свободные ресурсы (нагрузка ниже 10% и масса свободной памяти).

Имею данную проблему в 2 разных местах с разными провайдерами дополнительного канала Интернет на разном оборудовании Mikrotik: hAP (RB951Ui-2nD) и RB2011UiAS-RM, оба с MikrotikOS v6.41.

Что я сделал не так, кроме траты времени на игру в танки?


KARaS'b
Сообщения: 1199
Зарегистрирован: 29 сен 2011, 09:16

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

Вот для примера маркировка набора сайтов к которым нужно обращаться через забугорный впн.

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

add action=mark-routing chain=prerouting dst-address-list=freeVPN new-routing-mark=freeVPN passthrough=no

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


Аватара пользователя
kursy_po_it_ru
Сообщения: 37
Зарегистрирован: 24 ноя 2016, 11:52
Контактная информация:

KARaS'b писал(а):Может я не прав и боле опытные товарищи меня поправят, но мне непонятен принцип маркировки в вашем случае, сначала вы маркируете соединения и причем, насколько я понял, только новые!!!, а потом из этих соединений уже роуты, но по метке только новых!!! соединений.


С маркировкой у него проблем нет. Возможно Вы путаете маркировку пакета и маркировку соединения. Для упрощения приведу аналогию: соединение - это поезд, первый пакет соединения (connection-state=new) - это локомотив поезда. Правило говорит: если пришел локомотив, то промаркировать весь поезд. Читай: если пришел первый пакет нового соединения, то промаркировать все соединение. Таким образом в конечном счете оказываются промаркированными все пакеты соединения пока оно существует.


===
Скоромнов Дмитрий
Официальный тренер MikroTik
Автор видеокурса "Настройка оборудования MikroTik" (аналог MTCNA)
Отзывы на курс во ВКонтакте: https://vk.com/topic-130020919_34950142
100 дней поддержки по курсу вместо 30 по промокоду forummikrotik
KARaS'b
Сообщения: 1199
Зарегистрирован: 29 сен 2011, 09:16

kursy_po_it_ru писал(а):С маркировкой у него проблем нет. Возможно Вы путаете маркировку пакета и маркировку соединения. Для упрощения приведу аналогию: соединение - это поезд, первый пакет соединения (connection-state=new) - это локомотив поезда. Правило говорит: если пришел локомотив, то промаркировать весь поезд. Читай: если пришел первый пакет нового соединения, то промаркировать все соединение. Таким образом в конечном счете оказываются промаркированными все пакеты соединения пока оно существует.

Оу, спасибо, буду знать!
Но тогда рождается вопрос, зачем маркировать их, если можно сразу сделать как у меня?


ooptimum
Сообщения: 3
Зарегистрирован: 05 фев 2018, 09:16

KARaS'b писал(а): 06 фев 2018, 22:25 Но тогда рождается вопрос, зачем маркировать их, если можно сразу сделать как у меня?
Во-первых, потому что там еще некие дополнительные манипуляции с маркированными соедиенениями происходят, например, маркируются уже все пакеты данного соединения для полисинга (данные пакеты имеют в очереди приоритет над прочими, чтобы не было лагов при забитом канале), но я опустил эти детали как несущественные в рамках заданного вопроса. Во-вторых, с точки зрения вычислительных ресурсов проще проверять пакет на принадлежность соединению, т.к. statefull файрвол и так (кроме случаев явного указания no track) "раскладывает" пакеты по соединениям (/ip firewall connection print), чем сверять принадлежность адресата каждого пакета со списком IP адресов.

Но вообще с PBR какие-то непонятки. Забудем про Варгейминг и его игры. Если пускать весь трафик с любого произвольного хоста в локальной сети через альтернативный шлюз с помощью PBR, то всё работает еле-еле. Если же подключить этот хост к альтернативному провайдеру через выделенный маршрутизатор, то всё работает как надо. Возможно, я не совсем верно понимаю логику работы PBR на микротике? Я считаю, что команда "add distance=1 gateway=198.51.100.1 routing-mark=XYZ" однозначно задает единственный шлюз по умолчанию для всех пакетов, имеющих марку маршрутизации "XYZ". Но может быть этой командой мы задаем лишь дополнительный шлюз для таких пакетов, вдобавок к уже имеющемуся шлюзу по умолчанию, так что пакеты идут по 2 маршрутам в соответствии с некой логикой (round robbin)? Пока я просто не понимаю, что является причиной тормозов. Причем, аналогичные тормоза на 2 разных микротиках с 2 разными альтернативными провайдерами.


Obi Van
Сообщения: 15
Зарегистрирован: 02 фев 2018, 12:52

Из логики работы 2-х операторов в линукс я почерпнул простой факт: для каждого оператора своя таблица с дефолт роутом. В этой же таблице можно указать второго оператора с большей метрикой (distance в микротик). Дальше командой ip route rule обращение к конкретному IP адресу (или сети) направляется в нужную таблицу и как следствие на свой дефолт роут. Не тормозит.


Mikhail
Сообщения: 11
Зарегистрирован: 11 дек 2016, 19:26

Попробуйте отключить фасттрек.


Ответить