☰

Linux iptable ポート転送のトラブルシューティング方法

tag-icon • tag-icon ssh iptables linux-networking ssh-tunnel
Linux iptable ポート転送のトラブルシューティング方法

これを実行する方法については、すでに多くのヘルプとガイドがあります。しかし、何らかの理由で動作させることができず、トラブルシューティング方法がわかりません。
プライベート IP を持つ RDS postgres インスタンスがあります10.0.122.220。また、(はい) プライベート IP を持つ要塞ホストもあります。要塞ホストのポートに接続できますが、RDS には接続できません。そのため、要塞ホストのポートをRDS インスタンスのポートに10.0.94.67転送しようとしています。 要塞ホストのステータスは次のとおりです。54325432

bastion$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 127.0.0.1/8 scope host lo
...
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000
    inet 10.0.94.67/19 brd 10.0.95.255 scope global dynamic eth0
...

bastion$ ip route show | grep default
default via 10.0.64.1 dev eth0

bastion$ cat /proc/sys/net/ipv4/ip_forward
1

次に、2 つの NAT ルールを追加しました。

bastion# iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 5432 -j DNAT --to-destination 10.0.122.220

bastion# iptables -t nat -A POSTROUTING -o eth0 -p tcp --dport 5432 -d 10.0.122.220 -j SNAT --to-source 10.0.94.67

bastion# iptables -v -t nat -L -n
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DNAT       tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:5432 to:10.0.122.220

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 443 packets, 32660 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain POSTROUTING (policy ACCEPT 443 packets, 32660 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 SNAT       tcp  --  *      eth0    0.0.0.0/0            10.0.122.220         tcp dpt:5432 to:10.0.94.67

しかし、SSH トンネリングを使用しても RDS インスタンスに接続することはできません。

my-machine$ ssh -v -NL 5432:10.0.94.67:5432 -i my-key [email protected]
debug1: Connection to port 5432 forwarding to 10.0.94.67 port 5432 requested.
debug1: channel 2: new [direct-tcpip]
channel 2: open failed: connect failed: Connection refused
debug1: channel 2: free: direct-tcpip: listening port 5432 for 10.0.94.67 port 5432, connect from 127.0.0.1 port 57447 to 127.0.0.1 port 5432, nchannels 3
debug1: Connection to port 5432 forwarding to 10.0.94.67 port 5432 requested.
debug1: channel 2: new [direct-tcpip]
channel 2: open failed: connect failed: Connection refused
debug1: channel 2: free: direct-tcpip: listening port 5432 for 10.0.94.67 port 5432, connect from 127.0.0.1 port 57448 to 127.0.0.1 port 5432, nchannels 3
... keeps repeating the above

私が確認できたのは、RDS が起動し、実行され、応答しており、要塞ホストがそれにアクセスできることです。次の SSH トンネルを使用してデータベースに接続できます。

my-machine$ ssh -v -NL 5432:10.0.122.220:5432 -i my-key [email protected]

何を見逃したのでしょうか? どうすればトラブルシューティングできるでしょうか? ありがとうございます。

答え1

物事を複雑にしすぎている気がします。SSH を使用してデータベースへの接続を転送しているので、iptables と NAT を忘れて、SSH を使用してデータベース サーバーに直接転送するだけです。

使用：

my-machine$ ssh -v -NL 5432:10.0.122.220:5432 -i my-key [email protected]

の代わりに：

my-machine$ ssh -v -NL 5432:10.0.94.67:5432 -i my-key [email protected]

ソリューションが機能しない理由の説明: ローカルで生成されたトラフィックは NAT テーブルの PREROUTING チェーンを通過しないため、DNAT されません。ローカルで生成されたトラフィックを DNAT するには、OUTPUT テーブルを使用します。

bastion# iptables -t nat -A OUTPUT -p tcp --dport 5432 -j DNAT --to-destination 10.0.122.220

しかし、前述したように、これは物事を複雑にしすぎています。また、上記のルールを使用する場合は、宛先アドレスを一致させることもできます。

関連情報