Re: policy routing
On Mon, Jul 25, 2011 at 03:44:13PM +0100, Stanislav Maslovski wrote:
> On Пнд, 2011-07-25 at 16:22 +0400, sergio wrote:
> > On 07/23/2011 06:38 PM, Stanislav Maslovski wrote:
> >
> > https://www.jespercheetah.dk/page/howtos/owner_based_routing
> > Решение точно такой же проблемы.
> >
> > Как я понимаю основное отличие заключается в:
> >
> > iptables -t nat -A POSTROUTING -o wlan0 -m mark --mark 0xa -j MASQUERADE
>
> Нат тут должен быть не при чем (и мне он не нужен). Но вообще интересно:
> за исключением ната конфигурация по ссылке та же самая, что и у меня, и
> якобы работает...
Так, похоже ситуация проясняется. Возможны два варианта
1) tor стартует до поднятия tun0;
2) tor стартует после поднятия tun0.
Надо заметить, что у меня в конфиге tor-а OutboundBindAddress не
прописан, то есть, исходящие соединения идут от того IP, что Линус на
душу положит. И тут начинается интересный цирк.
В варианте 1 до поднятия tun0 пакеты tor-а уходят с src ip 192.168.0.2
на default gw 192.168.0.1 через wlan0. После поднятия tun0, при
котором также происходит добавление отдельного правила и отдельной
таблицы маршрутизации для tor-а (с дефолтовым маршрутом, идущим через
192.168.0.1), исходящие пакеты (с тем же src ip) от тора _игнорируют_
nfmark и эту отдельную таблицу и тупо лезут в туннель по
свежепоявившемуся дефолтовому маршруту в таблице main (ведет в
туннель). Openvpn радостно дропает эти пакеты (и правильно делает). ip
route flush cache не помогает. Эта ситуация описана в моем исходном
письме. Интересно, что если подождать довольно долго, то tor, видимо,
пытается переинитить коннект с пирами, и с некторого времени появляются
пакеты _по_прежнему_лезущие_в_туннель_, но уже от адреса одного из
концов туннеля (A.A.A.A). Такие пакеты openvpn пропускает, но от этого
не легче, так нужно совершенно другое: пакеты должны уходить через
192.168.0.1 со старого src ip 192.168.0.2.
В варианте 2 пакеты сначала идут по маршруту, прописанному в отдельной
таблице для тора (т.е., на gw 192.168.0.1, как указано), но теперь они
уже идут от src ip A.A.A.A и дропаются на шлюзе 192.168.0.1. Опять же,
если подождать некоторое время, то появляются пакеты, которые снова
плевали на nfmark и отдельную таблицу маршрутизации, и которые
пытаются лезть через тунель (от src ip A.A.A.A).
Цирк этот меня весьма забавляет, но тем не менее объясняет причину
MASQUERADE в конфигурации по ссылке (она соответствует случаю 2).
--
Stanislav
Reply to: