Неочевидный вопрос: почему в WireGuard трафик для удалённых узлов (peers) идёт через стандартные маршруты, а не через тоннель?

Question

[Sap_ru]

Просьба внимательно прочитать вопрос - вопрос не про маршрутизацию внутри тоннеля WireGuard!
Обратите внимание, что вопрос сложнее чем кажется и требует понимания процессов маршрутизации в ядре Linux.
Речь в вопросе идёт о стандартном и ожидаемом поведении WireGuard, а все изменения конфигцрации системы выполняются утилитой wg-quick при поднятии интерфейса.

Предположим, что у нас (с помощью wg-quick) настроен тоннель WireGuard с именем интерфейса "wg0". В конфигурации описан peer с адресом 100.100.100.100 и allowed-ips 0.0.0.0/0.
Создаваемые WireGuard правила маршрутизации (ip rules) в таком случае предписывают для всего немаркированного трафика использовать таблицу маршрутизации 100500:
> ip rule

0: from all lookup local
32765: not from all fwmark 0x1234 lookup 100500
32766: from all lookup main
32767: from all lookup default

В таблице 100500 прописан маршрут по-умолчанию через тоннель WireGuard:
> ip route show table 100500

default dev wg0 scope link
192.168.0.1 dev wg0 scope link

Исходящий трафик к пиру 100.100.100.100 не маркирован и должен идти через тоннель.
Более того, если выполнить "ip route get 100.100.100.100", то мы увидим что-то вроде:

100.100.100.100 dev wg0 table 100500 src 192.168.0.2

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

Вопрос: каким образом после поднятия тоннеля WireGuard маршрутизируется трафик к пирам?

Важное замечание: Обратите внимание, что WG сколько-либо стандартным образом может маркировать только пакеты, которые порождаются в его сетевом интерфейсе или отправляются через его интерфейс.
В описании WG также написано, что маркируются пакеты, которые были инкапсулированы внутри тоннеля (т.е. были порождены его сетевым интерфейсом на локальной системе). Исходящий трафик к пирам не был порождён в интерфейсе WG.
Отправляемые пакеты сначала проходят процедуру роутинга, а уже потом могут попасть в сетевой интерфейс WG, где они могут быть промаркированы. Но тогда и они отправлены будут через этот же интерфейс!
Наблюдаемое поведение можно получить путём добавления pre-routing правил в файрвол, но никаких правил в nft/iptables WireGuard не создаёт.

Answer 1

[Valentin Barbolin]

not from all - ни откого не принимать, по факту никогда не будет работать

не маркированый 1234
32765: from all not fwmark 0x1234 lookup 100500

вообще без меток
32765: from all fwmark 0x0/0xFFFFFFFF lookup 100500

Надеюсь ты в курсе что в wg0.conf можно указать таблицу маршрутизации (Table=100500) для интерфейса WG и не издеваться так над правилами?

Comments

[Sap_ru]

Всё верно, и я не издеваюсь над правилами. Это стандартные настройки WG, которые создаёт wg-quick при поднятии интерфейса.
Из твоего объяснения получается, что трафик до пиров также должен идти через интерфейс wg0, правильно? Но он идет через стандартный маршрут. Почему?
Получается, что WG маршрутизирует трафик до пиров каким-то нестандартным образом - каким?

И сразу упреждая ссылку на мануал WG: если WG использует стандартные сокеты, то он не может маркировать трафик, который он направляет к пирам. По крайней мере без применения грязных хаков, ломающих всю схему маршрутизации пакетов внутри ядра. WG может маркировать только те пакеты, которые ПОРОЖДАЮТСЯ в его сетевом интерфейсе. В описании WG также написано, что маркируются пакеты, которые были инкапсулированы внутри тоннеля (т.е. на локальной системы были порождены его сетевым интерфейсом). Исходящий трафик к пирам не был порождён в интерфейсе WG.
Отправляемые пакеты сначала проходят процедуру роутинга,а уже потом могут попасть в сетевой интерфейс WG, где они могут быть промаркированы. Но тогда они и отправлены будут через этот же интерфейс.
Наблюдаемое поведение можно получить путём добавления pre-routing правил в файрвол, но никаких правил в nft/iptables WireGuard не создаёт.

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