web-dev-qa-db-ja.com

リモートネットワークへのルートを追加します

私のネットワークスキーム：

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

ローカルホスト：Arch Linux x86-64

ワークステーション：CentOS 6 x86-64

SSHポート転送などを使用せずに、ローカルホストから10.128.0.0/16ネットワークに直接接続したい。ワークステーションはこのネットワークにアクセスできます。また、ワークステーションのVPNには静的IP10.255.255.252があります。

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：

SSHポートを使用して10.128.0.0/16ネットワークのポートに接続できます

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

この転送の後、localhost：5432を介して10.128.29.59: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

ローカルホストから10.128.0.0/16の対象ポートの1つにnmapします。

$ 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
linuxnetworkingvpnrouting
2
Evgeny Veretennikov

直接接続するということは、layer3ルーティングを使用することを意味します。ルーティングは非常に簡単に機能します。パケットはルーターに入り、宛先アドレスから決定された方向に出ます（少なくとも通常のルーティングでは）。次に、次のルーターに入り、パケットが宛先に到達するまで（または到達できないために壁にぶつかるまで）、同じプロセスが繰り返されます。

これには、forward方向all 10.128/16に向かうルーターは、どこかへの10.128/16のルートを持つ必要があります（できればチェーン内の次のルーター）。また、backpath内のallルーターには、192.168.1.0/24（できれば逆方向）のルートが必要です。返信があなたのマシンに届く可能性があります。

パス内のallルーター（vpnandrouter）で適切に行わない限り、機能しません。

（ミドルホップを管理していない場合は、ローカルホストとターゲット間で単純なGREトンネルを使用できます。すべてのパッケージで最大42バイトのオーバーヘッドを使用しますが、両端に「インテリジェント」ホストがある場合、セットアップは比較的簡単です。 。）

2
grin