Добавить маршрут в удаленную сеть

Question

Моя схема сети:

|localhost| tun1--> VPN <--tun0 |work station| wlan0--> |router| --> (10.128.0.0/16)

localhost: Arch Linux x86-64

рабочая станция: CentOS 6 x86-64

Я хочу подключиться напрямую с локального хоста к сети 10.128.0.0/16, без переадресации портов SSH и т.п. Рабочая станция имеет доступ к этой сети. Также рабочая станция имеет статический IP 10.255.255.252 в VPN.

путь трассировки от рабочей станции к хосту в 10.128.0.0/16:

$ tracepath 10.128.29.59
 1?: [LOCALHOST]     pmtu 1500
 1:  192.168.225.1 (192.168.225.1)                         15.293ms 
 1:  192.168.225.1 (192.168.225.1)                          2.119ms 
 2:  192.168.225.1 (192.168.225.1)                          2.085ms pmtu 1409
 2:  no reply
 3:  10.128.29.59 (10.128.29.59)                           15.655ms reached
     Resume: pmtu 1409 hops 3 back 3

192.168.255.1 является шлюзом по умолчанию для рабочей станции:

$ ip route | grep default
default via 192.168.225.1 dev wlan0

Я попытался просто добавить маршрут на моем локальном хосте, но это не удалось:

# ip route add 10.128.0.0/16 via 10.255.255.252
RTNETLINK answers: Network is unreachable

Полагаю, довольно наивно добавлять маршрут к удаленной сети таким образом. Как я могу сделать это правильно? Может быть, я должен как-то поделиться таблицей маршрутов на 10.255.255.252?

РЕДАКТИРОВАТЬ 1:

Я попробовал предложение Мариуса

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

Но это ничего не изменило. Таблицы iptables NAT теперь показывают это на рабочей станции:

# iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
MASQUERADE  all  --  anywhere             anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

РЕДАКТИРОВАТЬ 2:

Я могу подключиться к портам в сети 10.128.0.0/16 через SSH порт

ssh -L 5432:10.128.29.59:5432 user@10.255.255.252

После этой пересылки я могу подключиться к 10.128.29.59:5432 через localhost:5432. Итак, что я действительно хочу, так это вариант прямого подключения к 10.128.29.59:5432.

РЕДАКТИРОВАТЬ 3:

Я использую openvpn для подключения к VPN.

IP-маршрут на локальном хосте:

$ ip route
default via 192.168.1.1 dev wlp2s0 src 192.168.1.253 metric 302 
10.0.0.0/16 via 192.168.193.29 dev tun1 
10.255.0.0/16 via 192.168.193.29 dev tun1 
192.168.1.0/24 dev wlp2s0 proto kernel scope link src 192.168.1.253 metric 302 
192.168.193.0/24 via 192.168.193.29 dev tun1 
192.168.193.29 dev tun1 proto kernel scope link src 192.168.193.30 
193.26.135.101 via 192.168.193.29 dev tun1 
213.24.160.78 via 192.168.193.29 dev tun1

IP-маршрут на рабочей станции:

$ ip route
193.26.135.101 via 10.255.255.251 dev tun0 
213.24.160.78 via 10.255.255.251 dev tun0 
10.255.255.251 dev tun0  proto kernel  scope link  src 10.255.255.252 
192.168.193.0/24 via 10.255.255.251 dev tun0 
192.168.225.0/24 dev wlan0  proto kernel  scope link  src 192.168.225.165 
10.0.0.0/16 via 10.255.255.251 dev tun0 
10.255.0.0/16 via 10.255.255.251 dev tun0 
default via 192.168.225.1 dev wlan0

Nmap к одному из заинтересованных портов в 10.128.0.0/16 от localhost:

$ nmap -p5432 10.128.29.59/32

Starting Nmap 7.31 ( https://nmap.org ) at 2016-11-02 11:40 MSK
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 3.11 seconds

с рабочей станции:

$ nmap -p5432 10.128.29.59/32

Starting Nmap 5.51 ( http://nmap.org ) at 2016-11-02 11:42 MSK
Nmap scan report for 10.128.29.59
Host is up (0.034s latency).
PORT     STATE SERVICE
5432/tcp open  postgresql

Nmap done: 1 IP address (1 host up) scanned in 0.16 seconds

Answer 1

Прямое подключение означает, что вы хотите использовать layer3 маршрутизацию. Маршрутизация работает довольно просто: пакеты поступают в маршрутизатор и выходят в направлении, определенном по адресу назначения (по крайней мере, в обычной маршрутизации). Затем введите следующий маршрутизатор, и тот же процесс повторяется до тех пор, пока пакет не достигнет пункта назначения (или не попадет в стену, не имея возможности достичь).

Это требует, чтобы в прямом направлении все маршрутизаторы в направлении 10.128/16 должны были иметь маршрут 10.128/16 в какое-то место (предпочтительно к следующему маршрутизатору в цепочке). Также необходимо, чтобы все маршрутизаторы в заднем пути имели маршрут для 192.168.1.0/24 (предпочтительно в обратном направлении), чтобы ответ мог достигнуть вашей машины.

Если вы не сделаете это правильно на всех маршрутизаторах в пути (vpn и router), это не будет работать.

(В случае, когда вы не управляете промежуточными переходами, вы можете использовать простой туннель GRE между localhost и целевыми объектами: он использует ~ 42 байта служебной информации для каждого пакета, но относительно прост в настройке, если у вас есть "интеллектуальные" хосты на обоих концах .)