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

FastTrack вызывает медленную загрузку HTTPS

FastTrack вызывает медленную загрузку HTTPS, RouterOS

dromon

Guest

10.01.2022 03:02:00

В последнее время я много экспериментировал с WireGuard и немного запутался, как именно работают правила FastTrack. Детали моей настройки тут. Кроме того, я реализовал MSS clamping, как описано здесь. В итоге соединение работает, но TCP-соединения очень долго инициализируются и начинают передавать данные. Это видно в сетевом мониторе Firefox — длительное ожидание (5-50 секунд) перед началом получения данных. При этом, как только данные начинают приходить, всё работает быстро, и загрузка обычно занимает несколько миллисекунд.

Я смог решить проблему, отключив правило FastTrack в цепочке forward. Меня смущает, почему это изначально не работало.

Рассмотрим следующие правила файрвола:
[admin@MikroTik] > /ip/firewall/filter/print
Flags: X - отключено, I - неверно; D - динамическое
0 D ;;; специальное пустое правило для отображения счётчиков fasttrack
chain=forward action=passthrough

1 ;;; FastTrack
chain=forward action=fasttrack-connection hw-offload=no connection-state=established,related

2 ;;; Established, Related
chain=forward action=accept connection-state=established,related

<сокращено для краткости>

[admin@MikroTik] > /ip/firewall/mangle/print
Flags: X - отключено, I - неверно; D - динамическое
0 D ;;; специальное пустое правило для отображения счётчиков fasttrack
chain=prerouting action=passthrough

1 D ;;; специальное пустое правило для отображения счётчиков fasttrack
chain=forward action=passthrough

2 D ;;; специальное пустое правило для отображения счётчиков fasttrack
chain=postrouting action=passthrough

3 chain=prerouting action=mark-connection new-connection-mark=pia_wireguard_conn src-address=192.168.0.0/16 dst-address=!192.168.0.0/16 connection-mark=no-mark

4 chain=prerouting action=mark-routing new-routing-mark=routes-pia src-address=192.168.0.0/16 connection-mark=pia_wireguard_conn

5 chain=forward action=change-mss new-mss=clamp-to-pmtu passthrough=yes tcp-flags=syn protocol=tcp routing-mark=routes-pia

Как видно, у меня есть два правила mangle для маркировки VPN-трафика и ещё одно для ограничения MSS. Кроме того, есть общее правило FastTrack в цепочке forward. Пока вроде всё нормально.

Теперь, согласно официальной документации (здесь):
3. Пакет попадает в процесс forward;
a. проверяется TTL;
b. пакет обрабатывается в цепочке Mangle forward;
c. пакет обрабатывается в цепочке Filter forward;
d. пакет отправляется на учёт;

Если я правильно понимаю, поскольку пакет проходит через Mangle forward перед Filter forward, MSS должен ограничиваться до того, как применяется FastTrack.

Тем не менее, описанные выше проблемы есть.

Если я отключаю правило FastTrack в цепочке forward (через /ip/firewall/filter/set disabled=yes 1), всё работает как надо, без задержек.

Короче, почему так происходит? Где в моём понимании этого процесса зарыта ошибка?

chiem Guest	#2 0 17.06.2022 12:33:00 Спасибо за подтверждение и за то, что всё объяснили!

emk2203

Guest

10.02.2022 14:04:00

Я вижу по вашим правилам, что у вас есть соединение WireGuard с VPN Private Internet Access, если только название PIA не означает что-то другое. Не могли бы вы поделиться своей настройкой? Я новичок в WireGuard, и что-то вроде шаблона было бы очень полезным.

chiem

Guest

16.06.2022 04:00:00

Извиняюсь за «оживление» темы, но поиск по PIA и wireguard привел меня сюда. Похоже, что dromon так и не поделился своим скриптом для RouterOS, к сожалению, и после своих постов здесь он больше на форум не заходил. Я расскажу, что знаю, так как недавно сам этим занимался и все еще свежо в памяти.

Если скачать https://github.com/pia-foss/manual-connections и внимательно посмотреть файл connect_to_wireguard_with_token.sh, станет понятно, что там происходит:
- создается пара ключей Wireguard — приватный и публичный;
- связывается с мета-сервером PIA и отправляется туда публичный ключ;
- в ответ приходит IP интерфейса, IP:порт эндпоинта и публичный ключ для пира;
- на основе этого генерируется конфиг /etc/wireguard/pia.conf, примерно такой:

[Interface]
Address = 10.7.199.123
PrivateKey = <privKey>

[Peer]
PersistentKeepalive = 25
PublicKey = <pubKey>
AllowedIPs = 0.0.0.0/0
Endpoint = 91.90.120.123:1337

Эти данные можно напрямую перевести в RouterOS, например:

/interface wireguard add mtu=1420 name=wg-pia private-key="<privKey>"
/interface wireguard peers add allowed-address=0.0.0.0/0 endpoint-address=91.90.120.123 endpoint-port=1337 interface=wg-pia persistent-keepalive=25s public-key="<pubKey>"
/ip address add address=10.7.199.123/17 interface=wg-pia

Вот так практически полностью совпадает конфигурация wireguard на unix и в RouterOS.

Чтобы все заработало с вашей локальной сетью, нужно настроить NAT:

/ip firewall nat add action=masquerade chain=srcnat out-interface=wg-pia

Затем ограничить MSS для исходящего трафика:

/ip firewall mangle add action=change-mss chain=postrouting new-mss=clamp-to-pmtu out-interface=wg-pia protocol=tcp tcp-flags=syn

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

/routing table add fib name=pia
/ip firewall address-list add address=dns.google list=vpn
/ip firewall mangle add action=mark-routing chain=prerouting dst-address-list=vpn new-routing-mark=pia passthrough=no
/ip route add distance=1 dst-address=0.0.0.0/0 gateway=wg-pia pref-src=0.0.0.0 routing-table=pia scope=30 suppress-hw-offload=no target-scope=10

Это должно направлять весь трафик к dns.google через VPN-интерфейс PIA Wireguard.

Теперь момент, который меня сбивает: при тестах iperf3, входящий трафик (-R) по VPN работает нормально, а исходящий почти 0 кбит/с, хотя пинг проходит и исходящие подключения тоже устанавливаются.

В ходе экспериментов я выяснил, что нужно отключить ipv4 fasttrack, чтобы исходящий трафик нормально работал. Не понимаю, почему это нужно.

Ранее настраивал site-to-site Wireguard, road-warrior Wireguard и Wireguard на виртуальных машинах в роли шлюзов с похожей маршрутизацией, и у всех этих вариантов ipv4 fasttrack был включен и работал без проблем.

Кто-нибудь может объяснить, зачем для этого случая нужно отключать ipv4 fasttrack?

Znevna Guest	#5 0 16.06.2022 06:53:00 http://forum.mikrotik.com/t/fastrack-and-mark-routing/122888/1

teleport

Guest

25.07.2022 04:07:00

Синди, есть ли окончательное резюме последних правил, которые ты применяешь, с комментариями по настройке fast-track (если есть, кроме того, что это применяется только к вещам без маркировки соединений? Похоже, ты уже несколько раз это пересматривала). У меня специально была отдельная тема только для этого. Mikrotik ProtonVPN Wireguard Setup

chiem

Guest

16.06.2022 10:32:00

Спасибо за подсказку. Пост, на который ты дал ссылку, ведёт сюда: http://forum.mikrotik.com/t/static-default-route-im-missing-something/119183/2

Из этого я понял, что fasttrack-connection ускоряет обработку соединения на основе входящего пакета, из-за чего исходящий пакет пропускает обработку в mangle и, соответственно, не получает метку для маршрутизации, правильно? Значит, для той логики, которую я использовал, чтобы ставить метку маршрутизации на пакет, надо переключиться на маркировку соединения (но только на первый/новый пакет). Потом я должен использовать эту метку соединения, чтобы применять метку маршрутизации.

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

/ip firewall mangle add chain=prerouting connection-state=established,related connection-mark=no-mark action=accept
# если пакет из уже существующего соединения не имеет метки соединения, ему нужно обработать стандартным способом

add chain=prerouting connection-state=established,related in-interface=your-wan
# пакеты загрузки НЕЛЬЗЯ помечать routing-mark

add chain=prerouting connection-mark=handling-A action=mark-routing new-routing-mark=handling-A
# passthrough=no — поведение по умолчанию, но можно указать явно

add chain=prerouting connection-mark=handling-B action=mark-routing new-routing-mark=handling-B
# то же, что и выше

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

5. add chain=prerouting …список условий для обработки A… connection-state=new action=mark-connection new-connection-mark=handling-A passthrough=yes
6. add chain=prerouting …список условий для обработки B… connection-mark=no-mark connection-state=new action=mark-connection new-connection-mark=handling-B passthrough=yes
# начальные пакеты новых соединений, которые не попали под оба предыдущих правила, попадают сюда без метки соединения; здесь мы просто повторяем правила mark-routing выше

7. add chain=prerouting connection-mark=handling-A action=mark-routing new-routing-mark=handling-A
8. add chain=prerouting connection-mark=handling-B action=mark-routing new-routing-mark=handling-B

Разве строки #3-4 не совпадают со строками #7-8? Нужно ли их располагать до и после строк с метками соединений (#5-6)?
В строке #2 нет action, что она вообще должна делать? Там должно было быть action=accept? Если да, то, похоже, её задача — чтобы входящие пакеты с WAN имели метки соединений, но при этом им не ставились метки маршрутизации, чтобы они не маршрутизировались обратно через туннель?
Строка #1 вроде как не обязательна, а скорее оптимизация для производительности, да? И тогда она бы мешала, если бы мне понадобилось помечать соединения/пакеты другими способами?

sindy

Guest

16.06.2022 11:22:00

Они есть, но для них есть причина быть «дважды». Нужно экономить ресурсы процессора, поэтому правила №3 и №4 обрабатывают пакеты, идущие уже внутри соединения, которые уже помечены connection-mark, и такие пакеты не проходят дальше по цепочке правил, так как для этих правил выставлен passthrough=no. Но нужно также присвоить routing-mark начальному пакету каждого соединения, который только что получил connection-mark, поэтому то же самое правило встречается снова после правила с action=mark-connection. Всё правильно — действие по умолчанию для правила — accept (хотя моя ошибка, что не указал это явно, извините), и да, цель — не допустить, чтобы пакеты из внешней сети получили routing-mark и снова отправились через WAN, вместо того чтобы дойти до своего настоящего назначения в LAN. Тоже верно.

Пока что я перешёл на другую структуру, где помечаю все соединения через отдельную цепочку:

chain=prerouting connection-mark=no-mark action=jump jump-target=mark-conns
chain=prerouting connection-mark=CM1 in-interface-list=LAN action=mark-routing new-routing-mark=RM1 passthrough=no
...
chain=prerouting connection-mark=CMn in-interface-list=LAN action=mark-routing new-routing-mark=RMn passthrough=no

chain=mark-conns
..некоторые условия совпадения… action=mark-connection new-connection-mark=CM1 passthrough=yes
chain=mark-conns
..некоторые условия совпадения… connection-mark=no-mark action=mark-connection new-connection-mark=CM2 passthrough=yes
...
chain=mark-conns connection-mark=no-mark action=mark-connection new-connection-mark=use-main

Так что средний пакет внутри соединения всё равно проходит только (N+1)/2 правил, где N — количество routing-mark, при этом дублирующих правил нет, так что возможные ошибки удобно централизованы.

Кстати, action=jump на самом деле лучше назвать вызовом — если только какое-то правило внутри цепочки не вынесет окончательное решение (passthrough=no, action=accept и т.п.), обработка пакета возвращается в исходную цепочку после последнего правила вызванной.

chiem

Guest

16.06.2022 12:46:00

Хорошо, теперь я понял. Сначала я думал, что это ошибка или ненужная оптимизация, потому что они появляются снова всего через несколько строк с отметками соединений, но если в среднем соединение содержит, скажем, 10000 пакетов, то 99,99% из них закончат обработку здесь, а не через несколько строк позже. Ладно, тогда у меня новые вопросы по твоему новому методу:

chain=prerouting connection-mark=no-mark action=jump jump-target=mark-conns
chain=prerouting connection-mark=CM1 in-interface-list=LAN action=mark-routing new-routing-mark=RM1 passthrough=no
…
chain=prerouting connection-mark=CMn in-interface-list=LAN action=mark-routing new-routing-mark=RMn passthrough=no

chain=mark-conns ..some match conditions… action=mark-connection new-connection-mark=CM1 passthrough=yes
chain=mark-conns ..some match conditions… connection-mark=no-mark action=mark-connection new-connection-mark=CM2 passthrough=yes
…
chain=mark-conns connection-mark=no-mark action=mark-connection new-connection-mark=use-main

Так passthrough=yes в цепочке mark-conns действительно относится к правилу jump, из которого оно пришло? И если они возвращаются к этому правилу jump, когда принимается решение, тогда connection-mark=no-mark не нужен в строках (e)-(f), верно? И к чему вообще нужна строка (f)? В этом случае нужно будет изменить правило fasttrack-connection так, чтобы оно срабатывало только на пакетах с меткой соединения ‘use-main’, правильно?

Я понимаю, что in-interface-list=LAN в строках (b)-© убирает необходимость в строке 2 из предыдущего примера, но строка 1 всё ещё полезна как оптимизация, если убрать строку (f), не так ли? Не должно ли в строке (a) быть connection-state=new, что сделает connection-mark=no-mark и строку (f) ненужными? Тогда метки будут ставиться только на новые соединения, и у новых пакетов в этот момент ещё не может быть метки соединения.

Итак, подытоживая на основе твоих примеров, почему бы не сделать так?
chain=prerouting connection-state=established,related connection-mark=no-mark action=accept
chain=prerouting connection-state=new action=jump jump-target=mark-conns

chain=prerouting connection-mark=CM1 in-interface-list=LAN action=mark-routing new-routing-mark=RM1 passthrough=no
…
chain=prerouting connection-mark=CMn in-interface-list=LAN action=mark-routing new-routing-mark=RMn passthrough=no

chain=mark-conns ..some match conditions... action=mark-connection new-connection-mark=CM1 passthrough=yes
…
chain=mark-conns ..some match conditions... action=mark-connection new-connection-mark=CMn passthrough=yes

sindy

Guest

#10

16.06.2022 13:13:00

Существует множество способов сделать одно и то же. Если добавить connection-mark к каждому соединению, правило jump сможет сопоставляться только по connection-mark и не будет требовать совпадения по connection-state; наоборот, если вы можете обработать ситуацию, когда не удаётся присвоить connection-mark некоторым соединениям (или если это задумано специально), то достаточно, чтобы правило jump сопоставлялось только по connection-state=new. Это также определяет, нужна ли вам строка (f) или нет.

Но, мне кажется, вы неправильно поняли один момент — после того, как пакет прошёл последнее правило цепочки prerouting, он не продолжает обработку в цепочке mark-conns; единственный способ попасть в mark-conns — это когда пакет направляют туда из какой-то другой цепочки с помощью jump.

Что касается содержимого mark-conns, то условия сопоставления классификатора могут частично пересекаться, поэтому их порядок может иметь значение, и в таких случаях connection-mark=no-mark служит для того, чтобы не переписывать уже установленный connection-mark. Вы не можете ставить passthrough=no для этих правил, потому что после прохода через mark-conns пакет должен дальше обрабатываться в prerouting, чтобы в итоге получить routing-mark.

chiem

Guest

#11

16.06.2022 14:07:00

Нет, я предполагал этот момент. Я пытаюсь понять, как именно оценивается правило jump. Думаю, моё недоразумение было в том, что я исходил из того, что правило jump неявно продолжается на следующей строке после возврата из пользовательской цепочки. Например, с такими правилами:
chain=prerouting connection-state=established,related connection-mark=no-mark action=accept
chain=prerouting connection-state=new action=jump jump-target=mark-conns
chain=prerouting connection-mark=CM1 in-interface-list=LAN action=mark-routing new-routing-mark=RM1 passthrough=no
chain=prerouting connection-mark=CM2 in-interface-list=LAN action=mark-routing new-routing-mark=RM2 passthrough=no
chain=prerouting connection-mark=CM3 in-interface-list=LAN action=mark-routing new-routing-mark=RM3 passthrough=no
…
chain=prerouting connection-mark=CMn in-interface-list=LAN action=mark-routing new-routing-mark=RMn passthrough=no
chain=mark-conns ..some match conditions… action=mark-connection new-connection-mark=CM1 passthrough=yes
chain=mark-conns ..some match conditions… action=mark-connection new-connection-mark=CM2 passthrough=yes
chain=mark-conns ..some match conditions… action=mark-connection new-connection-mark=CM3 passthrough=yes
…
chain=mark-conns ..some match conditions… action=mark-connection new-connection-mark=CMn passthrough=yes

Допустим, у нас есть пакет для нового соединения, который должен соответствовать CM2, каков порядок обработки? Я думал, что это будет:
1, 2, 7, 8, 3, 4

То есть, как только строка 8 совпадёт, произойдёт возврат, а параметр “passthrough=yes” из строки 8 повлияет на поведение действия jump в строке 2, таким образом обработка продолжится на строках 3 и 4.

Но если я правильно понял то, что вы говорите, порядок должен быть таким:
1, 2, 7, 8, 9, 10, 3, 4?

Если да, то, наверное, мне стоит добавить строку:
chain=mark-conns connection-mark=no-mark action=accept
в конце цепочки mark-conns, чтобы не пришлось обрабатывать строки 3-6?

sindy Guest	#12 0 16.06.2022 17:36:00 passthrough=yes изменяет поведение правила, где он указан, так что в вашем примере это относится только к правилу 8. И да, будет выбран более длинный маршрут. Да, вы можете так сделать, ведь если connection-mark не назначен, то и переводить в routing-mark нечего. Конечно, в целом можно перевести отсутствие connection-mark в какой-то routing-mark, но это не самый распространённый подход.

Читают тему

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