LINUX.ORG.RU
Форум — Admin  

openvpn client, iproute2, iptables: dest port based routing

 , , , ,


0

1

ЛОР, Здравствуйте!

Уже несколько часов подряд не могу побороть маршруты на клиенте OpenVPN. Поиск работающего решения не дал и потому встречайте простыню:

Дано:

OpenVPN сервер - мной не контролируется

OpenVPN клиент ubuntu

wlan0 192.168.1.111 - интерфейс с инетом

Маршруты которые применяются на клиенте после соединения с сервером: 

/sbin/route add -net 207.126.92.3 netmask 255.255.255.255 gw 192.168.1.1

/sbin/route add -net 0.0.0.0 netmask 128.0.0.0 gw 5.5.0.1

/sbin/route add -net 128.0.0.0 netmask 128.0.0.0 gw 5.5.0.1
Мне нужно роутить пакеты наружу в зависимости от порта назначения

80,443 в vpn

все остальные мимо впна на 192.168.1.1 == роутер

Как размечать пакеты я в курсе: 

iptables -A OUTPUT -t mangle -p tcp -m multiport ! --dports 80,443  -j MARK --set-xmark 0x1/0xffffffff
как натравливать ip route на метки тоже:

ip rule add fwmark 0x1 table 100
ip route add default via 192.168.1.1 table 100

Не привожу конфиги целиком так как они все равно не работают как надо и много букв.

Были безуспешные попытки применить новые правила роутинга заюзав up/down директивы openvpn клиента.

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

Пакеты заруленные мимо впна, в том числе с подменой исходящего адреса 

iptables -A POSTROUTING -t nat -o $IF -p tcp -m multiport --dports 80,443 -j SNAT --to $IF_IP
бьются в син-аках 0 0,1 0,1 
"70","192.168.1.111","X.X.X.X","TCP","34314 > 81 [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=18664016 TSER=0 WS=7"
"71","X.X.X.X","192.168.1.111","TCP","81 > 34314 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1428 TSV=531584430 TSER=18654692 WS=5"
"72","X.X.X.X","192.168.1.111","TCP","81 > 34314 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1428 TSV=531584779 TSER=18654692 WS=5"
"73","192.168.1.111","X.X.X.X","TCP","34343 > 81 [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=18673732 TSER=0 WS=7"

Чувствую, что прогулял какой то урок в школе, да и дзена пока не достиг. И не могу допереть какая в данном случае конфигурация будет работоспособна.

Красноглазые, и не очень, выручайте любезно, пожалуйста!

/sbin/route add -net 207.126.92.3 netmask 255.255.255.255 gw 192.168.1.1

это не правильно, либо без -net (по умолчанию -host), либо явно указывай -host

попробуй

echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter

там по всем интерфейсам есть такой фильтр.

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

Сия радость приезжает с впн сервера, я его не контролирую. Копипаста была из лога клиента.

Так или иначе, с этими маршрутами всё здорово, они применяются и работают: 

207.126.92.3 via 192.168.1.1 dev wlan0 
192.168.1.0/24 dev wlan0  proto kernel  scope link  src 192.168.1.111 
5.5.0.0/20 dev tun0  proto kernel  scope link  src 5.5.2.0 
0.0.0.0/1 via 5.5.0.1 dev tun0

rp_filter уже пробовал, спасибо, не помогло

на момент времени проблема локализовалась до выбора ядром src addr при создании исходящего пакета. Если явно не задаётся приложением берется из основной (main) таблицы маршрутизации.

То есть куда кажет 0.0.0.0/1 туда и едем с src addr 5.5.2.0, если его SNATить то пакеты потом не возращаются на базу, син аки выше

Если прибить маршрут в тунель по 0.0.0.0/1, и исходным адресом по умолчанию будет локальный интерфес 192.168.1.1, пакеты в туннель идут, а обратно на локальный сокет не приходят нет.

Кто то их должен распознать и переписать обратно, SNAT с этой задачей очевидно не справляется.

Другими словами ситуация становится симметричной, работает только 1 из путей доставки, что печально.

Если у кого есть, соображения как красиво провернуть эту махинацию, буду искренне рад, услышать соображения по этому поводу.

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

ну как быстрый проверенный вариант, могу посоветовать тебе:
1. установить и настроить squid3
2. опция tcp_outgoing_address указывает на адрес твоей подсети (добавь новый ip адрес)
3. сделай
ip rule add from <новый ip address> table vpn
ip route add default via чего_там_для_впн table vpn
4. настрой браузер на 80 и 443 порт через прокси

так хотя бы должно работать. а дальше будешь еще думать над более прозрачным вариантом.

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

Пока это лучшее из попавших в моё поле зрения решений, и это рабочий вариант что не мало важно.

Спасибо, за свежий и здравый взгляд на проблему со стороны.

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