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 -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110725213255.GA28624@kaiba.homelan