Es gibt bereits jede Menge Hilfe und Anleitungen dazu. Aber aus irgendeinem Grund bekomme ich es nicht zum Laufen und bin mir nicht sicher, wie ich das Problem beheben kann.
Ich habe eine RDS-Postgres-Instanz mit der privaten IP 10.0.122.220. Ich habe auch einen Bastion-Host mit einer (ja) privaten IP 10.0.94.67. Ich kann eine Verbindung zu den Ports des Bastion-Hosts herstellen, aber nicht zum RDS. Also versuche ich, den Port 5432des Bastion-Hosts an den Port 5432der RDS-Instanz weiterzuleiten.
Dies ist der Status des Bastion-Hosts:
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
Dann habe ich zwei NAT-Regeln hinzugefügt:
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
Aber ich kann mithilfe von SSH-Tunneling immer noch keine Verbindung zur RDS-Instanz herstellen:
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
Was ich bestätigen kann, ist, dass RDS aktiv ist, läuft und reagiert und dass der Bastion-Host Zugriff darauf hat, da ich mit dem folgenden SSH-Tunnel eine Verbindung zur Datenbank herstellen kann:
my-machine$ ssh -v -NL 5432:10.0.122.220:5432 -i my-key [email protected]
Was habe ich übersehen? Wie kann ich das Problem beheben? Danke.
Antwort1
Ich habe das Gefühl, dass Sie die Dinge zu kompliziert machen. Da Sie SSH verwenden, um die Verbindung zur Datenbank weiterzuleiten, vergessen Sie iptables und NAT und verwenden Sie einfach SSH, um DIREKT an den Datenbankserver weiterzuleiten:
Verwenden:
my-machine$ ssh -v -NL 5432:10.0.122.220:5432 -i my-key [email protected]
anstatt:
my-machine$ ssh -v -NL 5432:10.0.94.67:5432 -i my-key [email protected]
Erklärung, warum Ihre Lösung NICHT funktioniert: Der lokal generierte Datenverkehr durchläuft NICHT die PREROUTING-Kette der NAT-Tabelle und wird daher NICHT DNAT-geprüft. Verwenden Sie die OUTPUT-Tabelle, um lokal generierten Datenverkehr DNAT-geprüft zu erhalten:
bastion# iptables -t nat -A OUTPUT -p tcp --dport 5432 -j DNAT --to-destination 10.0.122.220
Aber wie gesagt – das macht die Sache unnötig kompliziert. Und Sie möchten vielleicht auch die Zieladresse in der obigen Regel abgleichen, wenn Sie diese verwenden möchten.