[Сети] VPN доступ в сеть не через роутер

Захотел я получить доступ к сети снаружи... хотеть не вредно ^_^

Имеем:
ADSL -> Spliter -> Zyxel (ADSL) -> ZYXEL (WiFi Router - он же шлюз) -> Local Area (192.168.0.0/24)

Как видно из строчки выше, проблему решить не так просто.
Благо ip статический.

В сети есть файлопомойка на Ubuntu, тачка вечно включена, ее мы и задействуем.

На машинке поднимаем OpenVPN server (у меня 10.88.88.0/24)
Пробрасываем порты на роутерах (ну здесь все просто)
Устанавливаем клиентскую часть на машинке за пределами сети.
Подключились?, славно, а вот теперь проблема.
Имеем доступ на сервер, и никуда больше. Надо объяснить серверу, что он является шлюзом между VPN сетью и локальной, где локальная выступает в роли интернета.

Для этого включаем форвардинг:

sysctl -w net.ipv4.ip_forward="1"

применить без перезагрузки  sysctl -p

чтобы сохранить при перезагрузке, в файле  /etc/sysctl.conf добавить или раскомментировать строку net.ipv4.ip_forward=1 

И добавляем правило, будто все мы в VPN это один сервер.

iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

eth1 - это интерфейс смотрящий в локальную сеть, за подробностями сюда
В принципе кажется все, ан нет, клиент не понимает, что 192.168.0.ХХХ это там, за интерфейсом с ip 10.88.88.ХХХ

Для того, чтобы он образумился, нужно создать правило роутинга:

route add -p 192.168.0.0 MASK 255.255.255.0 10.88.88.5 METRIC 1

Прошу обратить внимание, что в свойствах tap интерфейса на Windows шлюз не указан, я долго думал пока не обратил внимание на:

 C:\>route print

 Сетевой адрес           Маска сети      Адрес шлюза       Интерфейс  Метрика

 10.88.88.1  255.255.255.255       10.88.88.5       10.88.88.6     20 

Как видно, в качестве шлюза выступает 10.88.88.5, его то мы и указываем в правиле, у Вас он может отличаться. Итог, мы получили необходимое, трассировка показывает правильный маршрут.

Адрес шлюза указывается не всегда, иногда помогает метод тыка

Грубо, но это выглядит как-то так:

А теперь посмеемся, если вздумаете попасть в сеть 192.168.0.0/24 через такой туннель, находясь в сети 192.168.0.0/24, то ничего не получится. Удачи, ХХД...

Update 13/08/2015
Также оказалось полезным для для форвардинга в VPN сеть снаружи.
Ни для кого не секрет что форвард из внешней сети во внутреннюю решается  одним правилом:

-A PREROUTING -d ХХХ.ххх.ХХХ.ххх/32 -p tcp -m tcp --dport 12221 -j DNAT --to-destination ZZZ.zzz.ZZZ.zzz:3389

Ну иногда требуется добавить построутинг:

-A POSTROUTING -d ZZZ.zzz.ZZZ.zzz/32 -p tcp -m tcp --dport 12221 -j SNAT --to-source ХХХ.ххх.ХХХ.ххх

И в очень редких случаях маскардинг на порт:

-A POSTROUTING -p tcp -m tcp --dport 12221 -j MASQUERADE 

Но это все работает на шлюзе, т.е. при попытке получить доступ к сети VPN с внешнего IP VPN сервера, мы получим отлуп даже при FORWARD -j ACCEPT.

Именно здесь и пригодилось правило описанное выше

iptables -t nat -A POSTROUTING -o tap1 -j MASQUERADE

 Единственная проблема - после такого правила, для многоконфигурационных серверов VPN придется явно задавать интерфейс в конфиге.

Также друг сказал что-то за:

iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT