LINUX.ORG.RU
решено ФорумAdmin

Перестал работать per-user masquerading в openvpn

 


0

1

Есть скрипт, который определенных системных пользователей пускает через openvpn.
До сегодняшнего дня все работало.
Симптомы: openvpn работает. Если вручную сделать ip route add ip_сайта via ip_vpn dev tun0_vpn, то на сайт пойдет через vpn (проверял через 2ip.ru).
Если же пускаем username через vpn

# Generated by iptables-save v1.4.18 on Sun Apr  7 08:01:33 2013
*mangle
:PREROUTING ACCEPT [210:31347]
:INPUT ACCEPT [102:17398]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [352:32472]
:POSTROUTING ACCEPT [352:32472]
[175:10343] -A OUTPUT -m owner --uid-owner 1003 -j MARK --set-xmark 0x1/0xffffffff
[0:0] -A OUTPUT -m owner --uid-owner 1005 -j MARK --set-xmark 0x1/0xffffffff
COMMIT
# Completed on Sun Apr  7 08:01:33 2013
# Generated by iptables-save v1.4.18 on Sun Apr  7 08:01:33 2013
*nat
:PREROUTING ACCEPT [7:2548]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [103:6095]
:POSTROUTING ACCEPT [0:0]
[103:6095] -A POSTROUTING ! -d 10.1.1.0/24 -o tun0_vpn -j MASQUERADE
COMMIT
# Completed on Sun Apr  7 08:01:33 2013


ip route show table openvpn
default via 10.1.1.9 dev tun0_vpn


ip rule show
0:      from all lookup local 
32765:  from all fwmark 0x1 lookup openvpn 
32766:  from all lookup main 
32767:  from all lookup default 
то получаем фигу без масла.
Если глянуть wireshark, то видно, что ответы приходят. Т.е. и ответы от dns, и icmp response. Например.
Получается, что тот же ping как бы не видит ответы.
Однако опять же, если сделать
ip r a 8.8.8.8 via 10.1.1.9 dev tun0_vpn
то ответы идут (ping в этом случае запускается не от тех пользователей, что через идут через openvpn. Если убрать все правила из таблицы mangle, то и от них ping идет через vpn (это видно по задержке ответа)).


Также если завернуть весь трафик через vpn, оставив только маршрут до сервера, то маскарадинг также работает.

getup
() автор топика

Если убрать все правила из таблицы mangle, то и от них ping идет через vpn (это видно по задержке ответа)).

Почем по задержке ответа, а не с помощью wireshark?

Поведение похоже на включённый ″rp_filter″, но тогда ping от пользователей должен работать просто при добавлении маршрута в main-таблицу маршрутизации, mangle таблицу iptables очищать не надо было бы.

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

Ну ладно, с wireshark и tcpdump тоже смотрел.
А по поводу rp_filter ты оказался прав. Сделал

echo 0 > /proc/sys/net/ipv4/conf/tun0_vpn/rp_filte
и все заработало.
В таком случае непонятно, почему раньше все было ок. Первое, что приходит в голову: после очередного обновления моего арчика в ядре решили поменять значение этого параметра по умолчанию (конечно, если раньше оно было равно 0).
Также неясно, почему пропускание _всего_ трафика через vpn работало.

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

Откуда у вас включился rp_filter я не знаю, может обновление задело /etc/sysctl.conf, может изменилось дефолтное значение в ядре.

А по поводу «почему пропускание _всего_ трафика через vpn работало» там всё просто. rp_filter рубит входящие пакеты, если ответный пакет должен пойти через другой интерфейс. При этом, маршрут ответного пакета вычисляется независимо от conntrack, iptables, ip rule. Только на основании записей в main таблице маршрутизации.

Как только в main таблице появлялся маршут на 8.8.8.8 через tun0_vpn, rp_filter начинал пропускать пакеты, приходщие из интерфейса tun0_vpn с src-адресом 8.8.8.8. А иначе он их рубил, так как rp_filter не смотрит на маршруты в таблице openvpn.

Вобще, на мой взгляд, от rp_filter больше проблем, чем пользы. Поведение трудно диагностируется, так как уничтожаемые пакеты не логируются, при этом tcpdump их видит, приложение не получает, но в отличии от ″-j DROP″ в iptables, у rp_filter нет даже счётчика. А ещё, для динамических интерфейсов (ppp, tun) далеко не все скрипты инициализации применяют записи из /etc/sysctl.conf. В результате, допустим, если хочется включить rp_filter для всех интерфейсов, кроме ppp0, то приходится засовывать ″echo 0 > /proc/.../conf/ppp0/rp_filter″ в скрипт /etc/ppp/ip-up, а не строку в /etc/sysctl.conf. И это не совсем правильно, когда параметры sysctl (/proc/sys/... ) спрятаны в скрипты, а не лежат в одном месте.

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