Моя схема сети:
|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