☰

Как устранить неполадки переадресации портов iptable в Linux

tag-icon • tag-icon ssh iptables linux-networking ssh-tunnel
Как устранить неполадки переадресации портов iptable в Linux

Уже есть тонны помощи и руководств о том, как это сделать. Но по какой-то причине я не могу заставить это работать и не уверен, как устранить неполадки.
У меня есть экземпляр RDS postgres с частным IP 10.0.122.220. У меня также есть хост-бастион с (да) частным IP 10.0.94.67. Я могу подключиться к портам на хосте-бастионе, но не к RDS. Поэтому я пытаюсь перенаправить порт 5432хоста-бастиона на порт 5432экземпляра RDS.
Вот статус хоста-бастиона:

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

Затем я добавил два правила 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

Но я все еще не могу подключиться к экземпляру RDS с помощью SSH-туннелирования:

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]

Объяснение, почему ваше решение НЕ работает: Локально сгенерированный трафик НЕ проходит через цепочку PREROUTING таблицы NAT, поэтому он НЕ DNAT. Используйте таблицу OUTPUT для DNAT локально сгенерированного трафика:

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

Но как я уже сказал - это слишком усложняет вещи. И вы также можете захотеть сопоставить адрес назначения в правиле выше, если вы решите его использовать.

Связанный контент