LINUX.ORG.RU
ФорумAdmin

Ошибка выборочной маршрутизации

 , , , ,


0

1

Господа, очень нужна подсказка с настройками маршрутизации, а то у меня уже глаз дёргается) Имеется роутер с прошивкой FreshTomato (этакий OpenWrt на минималках) на стареньком ядре 2.6.36.4brcmarm Требуется настроить выборочное открытие сайтов через VPN. Реализация: WireGuard на удалённом сервере, клиент на роутере, айпишники сайтов в ipset, маркировка совпадений в netfilter, направление маркированных пакетов в туннель с помощью iproute2. Проблема: ответы не маршрутизируются надлежащим образом.

Теперь по-порядку. Имеется настроенный WireGuard на удалённом сервере. Также WG настроен и работает на роутере с интерфейсом wg0 (подчеркну, что если отправлять весь трафик, то всё работает, т.е. сам туннель настроен корректнро). Для примера, в качестве сайта, доступ к которому надо получить через туннель, использую адрес zx2c4.com/ip с IP 136.144.57.121 Создаю таблицу ipset и добавляю туда адрес сайта:

ipset create ipaddrs hash:ip
ipset -exist add ipaddrs 136.144.57.121

Создаю правило netfilter для маркировки:

iptables -A PREROUTING -t mangle -m set --match-set ipaddrs dst -j MARK --set-xmark 0x1/0xffffffff

Создаю правило iproute2, принимающее пакеты с этой маркировкой и помещаю его сразу под local, ну и таблицу для попавших в него пакетов (уходить на интерфейс WG):

ip rule add table 100 fwmark 0x1 prio 100
ip route add default dev wg0 table 100

Вот и всё. Теперь из браузера загружаю zx2c4.com/ip рассчитывая увидеть адрес VPN-сервера, но ничего не происходит, просто таймаут соединения. Смотрю в логи: трафик в туннель заходит и выходит, но прилетают только пакеты с SYN, больше ничего не происходит. И на этом мои полномочия всё. Надо сказать, что я нуб и могу не понимать каких-то самых элементарных вещей. Побродил по форуму, обратил внимание, что многие при настройке раздельной маршрутизации смотрят в сторону CONNTRACK. Но если по iptables документации бохато, то по Коннтраку что-то вообще скудненько, поэтому так толком не разобрался что это, просто, особо не понимая, что делаю, попробовал добавить ещё 2 инструкции:

iptables -t mangle -I PREROUTING -j CONNMARK --restore-mark
iptables -A PREROUTING -t mangle -m set --match-set ipaddrs dst -j CONNMARK --save-mark

но это тоже ни к чему не привело.

Вот и всё. Надо ещё добавить, что если, например, маршрутизировать весь трафик, добавив правило сверху:

ip rule add table 50 prio 50
ip route add 136.144.57.121 dev wg0 table 50

то всё прекрасненько залетит в туннель и проверочный сайт откроется без проблем. Т.е. видимо, по какой-то причине, обратная маршрутизация ломается только в случае, если трафик направляется меткой MARK. И это кажется очень странно, самому разобраться не под силу, прошу помощи.


Ответ на: комментарий от no-dashi-v2

Да, изначально так и хотел сделать, но потом почитал, что это плохой подход на слабых устройствах. Предполагается, что количество адресов будет измеряться сотнями, в идеале хотелось бы предусмотреть возможность масштабирования до тысяч (чтобы сразу готовыми списками подтягивать). Насколько я уловил рассуждения людей уже решавших подобные задачи, ipset менее ресурсоёмок в этом смысле

RDF
() автор топика
Ответ на: комментарий от RDF

Во-первых, не занимайся преждевременной оптимизацией - там внутри совсем не тупой перебор списка маршрутов.

Во-вторых, mangle тебе недостаточно будет. Он срабатывает на отправляемый пакет, а пакет отправляется уже с source IP, и выбор этого source IP делается через таблицы маршрутизации. Так что как минимум тебе еще нужна запись в nat-таблице, которая будет подменять IP отправителя на IP туннельного интерфейса.

no-dashi-v2 ★★
()
Ответ на: комментарий от RDF

Отключается именно через 0, 2 это strict mode. Возможно, тебе как раз это и нужно, но лучше прочитай внимательно документацию, RP filter это огромное поле для хождения по граблям в случае если применяется асимметричная маршрутизация.

Khnazile ★★★★★
()