Проброс из инета вовнутрь VPN сохранив внешний IP-источник

Кажется я вычилил: затык происходит именно на OpenVPN. Похоже она, действительно, не пропускает пакеты от внешних IP.

Тогда остаётся только 3й вопрос: как заставить OpenVPN пропускать все пакеты?

Какой-то намёк на решение есть здесь, но у меня не работает.

DNAT не изменяет адрес источника пакета. Поэтому пакеты через VPN приходят к нам с IP-адресом отправителя и, соответственно, на домашнем сервере маршрутизируются не через VPN, а через внешний интерфейс и отбрасываются отправителем (то есть соединение установить не получается). Решается проблема так: Добавляем в /etc/iproute2/rt_tables таблицу маршрутизации, например, 128 VPN. Добавляем в конфиг клиента openvpn up /etc/openvpn/up Пишем скрипт /etc/openvpn/up:

#!/bin/bash
ip route add 0/0 dev tun0 src 10.8.0.6 table VPN
ip route prepend default via 10.8.0.6 table VPN
ip rule add from 10.8.0.6 table VPN

После перезапуска openvpn всё должно работать.

Подозрение, всё-таки, было верным: проблема в том, что VPN-HOST отвечает на wan0, а не на tun0.

Проблему отчасти решает добавление строки в /etc/openvpn/ccd/client:

push "redirect-gateway def1"

Тогда на клиенте в таблице маршрутизации, основной маршрут заменяется с wan0 на tun0:

0.0.0.0         10.8.0.5        128.0.0.0       UG    0      0        0 tun0
0.0.0.0         222.2.2.2       0.0.0.0         UG    0      0        0 wlan0
10.8.0.1        10.8.0.5        255.255.255.255 UGH   0      0        0 tun0
10.8.0.5        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
128.0.0.0       10.8.0.5        128.0.0.0       UG    0      0        0 tun0
111.1.1.1       222.2.2.2       255.255.255.255 UGH   0      0        0 wlan0
222.2.2.0       0.0.0.0         255.255.255.0   U     2      0        0 wlan0

Соединения с внешними ip начинают проходить, но при этом весь интернет-трафик VPN-HOST поворачивается в tun0. Это тоже не совсем то, что мне надо...

Я почти решил проблему!

Чтобы ответ возвращался на tun0, а не на wan0, на VPN-HOST нужно добавить строчку в файл /etc/iproute2/rt_tables:

128    VPN

ip route add 0/0 dev tun0 src 10.8.0.6 table VPN
ip route prepend default via 10.8.0.6 table VPN
ip rule add from 10.8.0.6 table VPN

После чего ответы уходят в tun0! Теперь осталось заставить OpenVPN делать это самостоятельно.

Всё! Разобрался!

Как выше было написано:
1) создаём запускаемый скрипт /etc/openvpn/up.sh с командами, которые перечислены
2) добавляем строчку в /etc/openvpn/client на VPN-HOST (моя ошибка была, что я добавлял на сервере):

up /etc/openvpn/up.sh

Вот и всё, при подключении openvpn добавляет хитро-в-банный маршрут в таблицу route на клиенте, и трафик начинает бегать!

Ох уж мне этот ваш линукс!

Склепал более простую версию скрипта /etc/openvpn/up.sh:

#!/bin/sh

VPNINT=tun0
VPNIP=10.8.0.6

#ip route add 0/0 dev $VPNINT src $VPNIP table VPN
#ip route prepend default via $VPNIP table VPN
#ip rule add from $VPNIP table VPN

ip rule add from $VPNIP lookup VPN
ip route add default dev $VPNINT table VPN

2 команды вместо 3х.

Вот самый правильный скрипт:

#!/bin/sh

VPNINT=tun0
VPNIP=10.8.0.6

ip rule del from $VPNIP
ip route add default dev $VPNINT table VPN
ip rule add from $VPNIP lookup VPN

Иначе маршруты не подчищаются.
Проверять такими командами:

ip rule show
ip route show
ip route show table VPN
ip route show table all

Надеюсь, теперь всё...

Тоже не очень верно. Подсказываю, у rule есть priority куда можно цифирку приписать и по ней удалять. Например

ip rule add priority 30000 from $VPNIP lookup VPN 
ip rule del priority 30000 

while ip rule del priority 30000 2>/dev/null; do :; done; 

Хорошие замечания. Но можно «дешевле» сделать :)

Например, строку удаления удвоить, чтоб подчищалось с лихвой :)

ip rule del from $VPNIP
ip rule del from $VPNIP
ip route add default dev $VPNINT table VPN
ip rule add from $VPNIP lookup VPN

Ну а повисшие rule между vpn-соединениями вроде не мешают.

P.S. Кстати, только rule остаются висеть, а route каким-то образом сами подчищаются, когда vpn-соединение разрывается - весьма странное поведение.

Хорошие замечания. Но можно «дешевле» сделать :)

В конкретно вашем случае да, но вы же не знаете как через год, два у вас что-то поменяется. Плюс я описывал вариант при динамическом IP, и сорри забыл указать на то что VPNIP VPNINT надо не статикой прописывать а брать из переменных. Да и вообще лишние правила не кошерно.

Кстати, только rule остаются висеть, а route каким-то образом сами подчищаются, когда vpn-соединение разрывается - весьма странное поведение.

Это как раз правильно, а не «странно», интерфейс же упал, странно если бы было наоборот.

Да, и насчет priority вы кажется так и не поняли.

Насчет priority понял.

Самое кошерное было б, если бы проброс порта прописывать только на сервере, не лазая на клиента. А то iptables на сервере крутим, а route на клиенте - это зашквар.

сорри забыл указать на то что VPNIP VPNINT надо не статикой прописывать а брать из переменных

По этой части поясню, в зависимости от настроек как сервера так и клиента, «можно» запустить н-цать копий клиента, пускай и случайно, т.е. по факту получить несколько IP и несколько tun интерфейсов.

Самое кошерное было б, если бы проброс порта прописывать только на сервере, не лазая на клиента.

Если я правильно понял вашу задачу, то без вариантов.

route на клиенте - это зашквар.

Почему? Один фиг настройки, как уж они выглядят имхо неважно.