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 ★★★★★
()
Вы не можете добавлять комментарии в эту тему: топик перемещен в архив.