Adicionar rota à rede remota

Question

Meu esquema de rede:

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

localhost: Arch Linux x86-64

estação de trabalho: CentOS 6 x86-64

Eu quero me conectar diretamente do localhost à rede 10.128.0.0/16, sem redirecionamentos de porta SSH e tal. Estação de trabalho tem acesso a esta rede. Além disso, a estação de trabalho tem IP estático 10.255.255.252 na VPN.

tracepath da estação de trabalho para o host em 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 é o gateway padrão para a estação de trabalho:

$ ip route | grep default
default via 192.168.225.1 dev wlan0

Eu tentei apenas adicionar rota no meu host local, mas ele falhou:

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

Eu acho que é bastante ingênuo adicionar rota à rede remota dessa maneira. Como posso fazer isso corretamente? Talvez, eu deveria compartilhar a tabela de rotas em 10.255.255.252 de alguma forma?

EDIT 1:

Eu tentei a sugestão de Marius

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

Mas isso não mudou nada. iptables tabelas NAT agora mostram isso na estação de trabalho:

# 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

EDIT 2:

Consigo me conectar a portas na rede 10.128.0.0/16 usando a porta SSH

ssh -L 5432:10.128.29.59:5432 [email protected]

Após esse encaminhamento, posso conectar-me a 10.128.29.59:5432 via localhost: 5432. Então, o que eu realmente quero é apenas a opção de se conectar diretamente a 10.128.29.59:5432.

EDIT 3:

Eu uso o openvpn para me conectar à VPN.

rota ip no host local:

$ 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

rota ip na estação de trabalho:

$ 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 para uma das portas interessadas em 10.128.0.0/16 do 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

da estação de trabalho:

$ 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

Conectar diretamente significa que você deseja usar o roteamento layer3. O roteamento funciona bem simples: os pacotes entram no roteador e saem na direção determinada a partir do endereço de destino (no roteamento normal, pelo menos). Em seguida, insira o próximo roteador e o mesmo processo repetido até que o pacote chegue ao destino (ou atinja a parede por não conseguir alcançá-lo).

Isso requer que na direção encaminhamento todos em direção a 10.128 / 16 devam ter uma rota de 10.128 / 16 em algum lugar (de preferência para o próximo roteador na cadeia). Também requer que os roteadores all no backpath possuam uma rota para 192.168.1.0/24 (de preferência para trás) para possibilitar que a resposta chegue à sua máquina. / p>

A menos que você faça isso corretamente em roteadores all no caminho (roteador vpn e ), ele não funcionará.

(No caso em que você não está administrando os saltos intermediários, você pode usar um túnel GRE simples entre localhost e destinos: ele usa ~ 42 bytes de sobrecarga em cada pacote, mas relativamente simples de configurar, desde que você tenha hosts "inteligentes" nas duas extremidades.)