LINUX.ORG.RU
ФорумAdmin

Перенаправление пакетов через VPN

 , ,


0

1

Доброго времени. Есть задача: все запросы с локального компа на ip-адреса с определённого ipset'a отправлять через vpn. В сети полно руководств, но что-то идёт не так.

Что делаю: 1. создал ipset

# ipset list
Name: vk
Type: hash:ip
...
Number of entries: 55
...
т.е. ipset у меня не пустой

2. для каждого ip из сета добавляю флаг

# iptables -t mangle -A OUTPUT -m set --match-set vk dst -j MARK --set-mark 0x1
других правил iptables нет.

Параметр ядра для fwmark установлен:

# sysctl net.ipv4.tcp_fwmark_accept
net.ipv4.tcp_fwmark_accept = 1

3. создаю таблицу маршрутизации и настраиваю правила

# ip rule list table vk.out
1000:	from all fwmark 0x1 lookup vk.out

# ip route list table vk.out
default via 10.8.0.5 dev tun0
(tun0 и ip шлюза корректные, других правил для fwmark 0x1 нет)

Проверяю пингом — ничего :( Когда перенаправляю все пакеты через vpn, пинг проходит, т.е. с vpn всё в порядке.

Подскажите, плз, что я забыл. Мб ещё какой-то параметр ядра?

На всякий случай: арч, ядро 4.11.8-1-ck-ivybridge x86_64 (с патчами CK)

Ответ на: комментарий от melkor217

Но почему? Разве не сравнивается fwmark ? У меня таблиц не много:

# ip rule list
0:	from all lookup local 
1000:	from all fwmark 0x1 lookup vk.out 
32766:	from all lookup main 
32767:	from all lookup default

OramahMaalhur
() автор топика
Последнее исправление: OramahMaalhur (всего исправлений: 1)

Предполагаю, что ответ вы найдете запустив tcpdump.

anc ★★★★★
()
15 декабря 2017 г.
Ответ на: комментарий от OramahMaalhur

Удалось решить? Та же самая проблема. Если делать

ip rule add to 8.8.8.8 table 10


То все работает, пинги идут через впн. Но если средствами fwmark
ip rule add fwmark 0xa table 10


То не работает. WTF?

as_lan ★★
()
Последнее исправление: as_lan (всего исправлений: 1)
Ответ на: комментарий от pekmop1024

Проблема в rp_filter. Его отключение помогает. Но если его выключить, у меня некоторые пакеты начинают уходить не по тому интерфейсу.

Чтоб было понятней. Есть некоторый список сайтов (заблокированныйх). Хочу их перенаправить через vpn (опенвпн до своей vps). Чтоб не создавать кучу правил типа ip rule add to ...., решил все добавить в ipset, дальше их маркировать в iptables и уже ip rule add fwmark... отправлять через тунель. Но тут облом. Ничего не работает. Отключение rp_filter помогает. Но потом заметил, что в tcpdump на моем внешнем интерфейсе пакеты, которые по идее должны уходить в впн тунель. А уходят в eth. Если отключить rp_filter то этого нет. Но и вообще все перестает работаеть.

Суть даже не в этом. Вообще не понятная логика. Почему ip rule add to/from работает, а ip rule add fwmark без rp_filter не работает.

as_lan ★★
()
Ответ на: комментарий от pekmop1024

1. Это шлюз. Там и транзитный трафик
2. У меня там торрент клиент, который тоже гоняю через впн. А он слушает не 127.0.0.1. Разве routable loopback поможет в этом случае?

as_lan ★★
()
Ответ на: комментарий от as_lan

Вот почти уверен, что все что за шлюзом - роутится на отличненько, а именно сам шлюз - нет.

ЗЫ. Интерфейс с routable loopback лучше настраивать через ребут, ибо не во всех условиях он корректно поднимается наживо.

pekmop1024 ★★★★★
()
Ответ на: комментарий от pekmop1024

Как раз таки нет. Все что я маркирую - все перестает ходить. Внезависимости от того локальный или транзитный трафик. Либо отключать rp_filter либо через ip rule from/to

as_lan ★★
()
Ответ на: комментарий от anc

Там все стандартно. В таблице mangle 3 правила

-A PREROUTING -m set --match-set rkz dst -j MARK --set-xmark 0xa/0xffffffff
-A OUTPUT -m owner --uid-owner 1001 -j MARK --set-xmark 0xa/0xffffffff
-A OUTPUT -m set --match-set rkz dst -j MARK --set-xmark 0xa/0xffffffff

as_lan ★★
()
Последнее исправление: as_lan (всего исправлений: 2)

Я так понимаю это все by_design. Я другое понять не могу. Почему это относиться с ситуации именно с маркированными пакетами? Почему проблемы нет если просто добавлять через ip rule from/to?

as_lan ★★
()
Ответ на: комментарий от as_lan

И с сетом все в порядке? Если следовать вашему же примеру и заменить сет на -d 8.8.8.8 тоже не работает?

anc ★★★★★
()
Ответ на: комментарий от anc

Не знаю правильно ли вас понял, но если вы имеет ввиду, что в iptables я буду маркировать в mangle просто по -s 8.8.8.8, то да, так же пропадает пинг. Так что ipset вообще не причем.

as_lan ★★
()

все запросы с локального компа на ip-адреса с определённого ... отправлять через vpn.

Ну я прям не знаю, такая фигня всю жизнь делалась без всяких ipset/fwmark/iproute2 и прочей зауми, просто тупо добавлением маршрутов до указанных сетей через нужный интерфейс. Для локального компа и nat не нужен, само выберет нужный output адрес.

vodz ★★★★★
()
Ответ на: комментарий от vodz

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от vodz

Выше вам ответили, чем не подходит добавление маршрутами. И будьте добры. Скажите как роутит не по адресу назначения/источника, а по uid/gid ? Вопрос не только в моей торрент качалке. Может я веб трафик хочут через один гетвей, а отсльной трафик через другой? Или завел пользователей на шлюзе и их трафик на шлюзе роутить по разному? Я кроме mark ничего не могу вспомнить.

as_lan ★★
()
Ответ на: комментарий от vodz

А еще я поднимал года 2 назад тему, когда пытался в таблицу маршрутов пару тысяч записей добавлять (сейчас у роскомпозора в пару раз больше записей). Мало того что это не правильно. Так и таблица не очищалась до конца, если надо было сбросить таблицу. Надо было запустить пару раз команду очистки таблицы, чтоб все удалилось. Был конечно и альтернативный способ добавления маршрутов. Записи очищались. Но мне он не нравился.

as_lan ★★
()
Ответ на: комментарий от Iron_Bug

Вы думаете, что если вы поднимите при двух каналах какой, прости господи, BGP, то таблица маршрутизации будет махонькой, а все маршруты будет выполнять user-level процесс этого демона маршрутизации? ;) Да таблицы рутинга — самое маложручее и самое удобное из всех возможных решений именно для задачи, которую я и процитировал из стартового поста, а не сам выдумал.

vodz ★★★★★
()
Ответ на: комментарий от as_lan

Выше вам ответили, чем не подходит добавление маршрутами. И будьте добры. Скажите как роутит не по адресу назначения/источника, а по uid/gid ?

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

vodz ★★★★★
()
Ответ на: комментарий от vodz

при чём тут юзер-левел? вопрос в том, как эту беду обслуживать и легко добавлять маршруты. только ради этого вообще сделан ipset.

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

только ради этого вообще сделан ipset

ipset хорош для группировки адресов в псевдосети. А когда нам надо маршрутизировать сети, то зачем навешивать ещё одну абстракцию? Какие проблемы добавлять/убавлять маршруты? Можно руками, не так часто в vk.com появляются и исчезают сети, а можно и свой демон динамической маршрутизации написать.

vodz ★★★★★
()
Ответ на: комментарий от telikan

ipset, который ТС и заюзал. и который как раз сделан для удобного управления маршрутизацией кучи айпишников.

конечно, некоторые предпочитают вместо этого «свой демон динамической маршрутизации написать». впрочем, путь per anus as astra никто не запрещает.

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

некоторые предпочитают вместо этого

Враньё. В указанной задачи это равносильно будет демону для iptables -t mangle -m set --match-set

vodz ★★★★★
()
Ответ на: комментарий от Iron_Bug

что враньё?

Всё, что в предыдущих ваших комментах. Я сейчас много написал и стёр нафиг. Смысл писать, если вы осиливаете только первое предложение и то, если оно было только из одного слова? Ибо «что враньё» было сразу же объяснено после слова «враньё».

vodz ★★★★★
()
Ответ на: комментарий от vodz

Что бы не было вопросов ip rule flush не удаляет все

Я вам еще раз говорю. Это не правильный инструмент. не я один жаловался на то, что flush не чистить таблицы. Люди предлагали делать в цикле это. Но чистить таблицу циклом на баше это велосипед с квадратными колесами.

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

as_lan ★★
()
Ответ на: комментарий от vodz

В каком месте правила изменяются на ходу? Я третьим сообщением уточнил, что мне еще надо по uid/gid тоже отправлять это по разным маршрутам. Я просил вас пример реализации средствами ip route/ip rule. Ответа я не получил. Поэтому еще раз спрашиваю (без сарказма). Можно это реализовать без ipset?

К тому же. Изначально я вообще задался вопросом. Почему ip rule from/to не требует отключения rp_filter, а fwmark требует. Я просто не совсем понимаю логики. Опять таки без сарказма, хотелось бы получить объяснение. Чисто для себя.

as_lan ★★
()
Ответ на: комментарий от as_lan

Что-то у вас все-таки еще наверчено. Судя по вашим исправлениям что-то тама таки есть. А сферически должно работать.

anc ★★★★★
()
Ответ на: комментарий от as_lan

В каком месте правила изменяются на ходу?

Видите ли, вы меняли условия почти в каждом сообщении. Я отвечал на стартовое, где была простейшая задача насчёт «каждый пакет локальной машины». Это отдельная простая задача. Потом вы зачем-то взяли и добавили транзит, а мне зачем-то добавили uid/gid. Добавлять условия — ваше право, но за возмущения о том,что вам не решали пока неозвученные задачи полагается канделябром.

vodz ★★★★★
()
Ответ на: комментарий от as_lan

Отлично че. Давайте для тривиальных задач еще и демон напишем.

Да еще с чтением у всех проблема. Ну как можно не понять, что демон я предлагал тем, кому сложно управлять маршрутизацией? То бишь просто подколкой. И даже два раза разжевал, что это аналогично добавлению демона для управления решением через iptables.

vodz ★★★★★
()
Последнее исправление: vodz (всего исправлений: 1)
Ответ на: комментарий от anc

Исправил, потому что я параллельно эксперементировал и смотрел, от чего может зависеть. Думал может отдельно маркировать пользовательский трафик. В итоге ничего не изменилось. Что в моем последнем изменении то и есть сейчас.

Мы все сейчас из пустого в порожнее льем. Изачально хотелось бы понять, почему вообще именно так все работает. Вот похожие ссылки
http://gentoo.ru/node/28224
Multihomed, CONNMARK и rp_filter.

У меня по tcpdump видно, что пекет уходит в tun и ответ приходит туда же. Но он отбрасывается. Почему? Ведь пакет должен отбрасываться если уходит в один интерфейс, а приходит в другой.

Пока решил переводом rp_filter в «2»

as_lan ★★
()
Ответ на: комментарий от as_lan

Думаете, что ядро запоминяет для каждого интерфейса все ушедшие через него пакеты, чтобы потом ответные сопоставлять с этим списком? При получении пакета с интерфейса, у которого rp_filter != 0, вычисляется маршрут до src-адреса этого пакета и смотрится какой там получился интерфейс.

Раньше вобще с rp_filter=1 работало только если маршрут через этот интерфейс был в main таблице маршрутизации, если в вашем ядре работает и при выборе таблицы маршрутизации по src-ip через ip rule это хорошо. Но сделать, чтобы rp_filter прогонял фейковый пакет через iptables чтобы определить какой он получить MARK сложно.

mky ★★★★★
()
Ответ на: комментарий от mky

Спасибо. Подобного пояснения я и ждал. Теперь понятно. Мне казалось что он помнит ушедшие пакеты. Что-то вроде кэша.

as_lan ★★
()
Последнее исправление: as_lan (всего исправлений: 1)
Ответ на: комментарий от as_lan

Уточним по первому посту.

Отключение rp_filter помогает.

Хорошо

Но потом заметил, что в tcpdump на моем внешнем интерфейсе пакеты, которые по идее должны уходить в впн тунель. А уходят в eth.

Вот это плохо.

Если отключить rp_filter то этого нет. Но и вообще все перестает работаеть.

Здесь опечатка? Имелось ввиду «Если включить rp_filter то этого нет» ?

У меня по tcpdump видно, что пекет уходит в tun и ответ приходит туда же. Но он отбрасывается. Почему? Ведь пакет должен отбрасываться если уходит в один интерфейс, а приходит в другой.

Теперь к этому сообщению.

У меня по tcpdump видно, что пекет уходит в tun и ответ приходит туда же. Но он отбрасывается. Почему? Ведь пакет должен отбрасываться если уходит в один интерфейс, а приходит в другой.

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

Пока решил переводом rp_filter в «2»

Так что проблемой того что пакеты через eth летят вместо vpn? ее нестало?

anc ★★★★★
()
Последнее исправление: anc (всего исправлений: 2)
Ответ на: комментарий от mky

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

Это скорее всего проистекает от желания маркировать пакеты не только в ядре, но и в Интернете. А раз это невозможно, то логически хочется чтобы ядро запоминало. :)

Раньше вобще с rp_filter=1 работало только если маршрут через этот интерфейс был в main таблице маршрутизации

Ну теперь то при наличии rp_filter=2 и проблемы нет для конфигурации с несколькими интерфейсами, как бы там не сконфигурена маршрутизация.

vodz ★★★★★
()
Ответ на: комментарий от anc

Так что проблемой того что пакеты через eth летят вместо vpn? ее нестало?

Удивительно, как вам хватает терпения лечить подземный стук... ;)

vodz ★★★★★
()
Ответ на: комментарий от anc

Здесь опечатка? Имелось ввиду «Если включить rp_filter то этого нет» ?

Да. Пардон. При включении не замечал пакетов, которые уходят не туда. Возможно потому что просто все дропается в ядре.

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

Ну мне не понятно было то, что после маркировки iptables, ip rule об этом знал, так как через fwmark он знал в какую таблицу послать пакет. Но вот ответ при этом дропал. То есть когда надо вычислить маршрут для проверки - он не использует маркировки. Не знаю как правильно мысль объяснить.

Так что проблемой того что пакеты через eth летят вместо vpn? ее нестало?

Да. И я подозреваю потому, что при отключении rp_filter на tun, еще приходилось и в /proc/sys/net/ipv4/conf/all/rp_filter отключать. То есть в двух местах. Иначе не работало. А если делать echo «2» для tun интерфейса, то в all ничего отключать не надо. Достаточно только в tun.

as_lan ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.