AWS VPC + IPtables + NAT: переадресация портов не работает

Вчера я отправил вопрос здесь , но я думаю , что не было достаточно ясно в моих словах. Кстати, этот вопрос не является дубликатом.

У меня есть AWS VPC Setup, как показано ниже.

ЦЕЛЬ / ПРОБЛЕМА : SSH к серверу A из Интернета. И это не работает.

Сервер A находится в частной подсети, и, следовательно, я хочу включить iptables NATing на моем экземпляре NAT, чтобы я мог подключиться к SSH к серверу A напрямую из Интернета.

Я слежу за этим и этим

Я побежал ниже команды на экземпляре NAT:

NAT# iptables -t nat -A PREROUTING  -p tcp --dport 2222 -j DNAT --to-destination 10.0.1.243:22

Переадресация IP включена на экземпляре NAT:

NAT# sysctl  -p
net.ipv4.ip_forward = 1

MASQUERADE работает на экземпляре NAT:

NAT# iptables -t nat -vnL POSTROUTING
Chain POSTROUTING (policy ACCEPT 6 packets, 312 bytes)
 pkts bytes target     prot opt in     out     source               destination
  199 16466 MASQUERADE  all  --  *      eth0    10.0.0.0/16          0.0.0.0/0

Группы безопасности AWS настроены так, чтобы разрешить различный доступ, необходимый для этого теста.

Исправление проблем:

Я могу telnet с NAT на сервер A на порту 22. Так что доступ хороший.

Когда я запускаю telnet 54.213.116.251 2222на своем ноутбуке, я вижу ниже запись в tcpdump на NAT:

NAT# tcpdump -n -i eth0 dst 10.0.1.243 and port 22
09:59:13.738316 IP xxx.xxx.xxx.xxx.51709 > 10.0.1.243.ssh: Flags [S], seq 1868541786, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
09:59:16.737009 IP xxx.xxx.xxx.xxx.51709 > 10.0.1.243.ssh: Flags [S], seq 1868541786, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
09:59:22.775567 IP xxx.xxx.xxx.xxx.51709 > 10.0.1.243.ssh: Flags [S], seq 1868541786, win 8192, options [mss 1460,nop,nop,sackOK], length 0

Таким образом, это означает, что iptables направляет пакеты 10.0.1.243. (Кстати, xxx.xxx.xxx.xxxэто публичный IP-адрес моего ноутбука)

Но когда я запускаю tcpdump на сервере A, я не вижу ничего, что исходит от 10.0.0.54внутреннего / частного IP-адреса NAT ( и я думаю, что это проблема ):

Server A# tcpdump  -n src 10.0.0.54
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 

Но если я telnet с экземпляра NAT на сервер A, я вижу хорошие вещи в tcpdump на сервере A ( это означает, что мое общее PREROUTINGправило не работает должным образом ):

Server A# tcpdump  -n src 10.0.0.54
05:01:47.500080 IP 10.0.0.54.44627 > 10.0.1.243.ssh: Flags [S], seq 2862522431, win 14600, options [mss 1460,sackOK,TS val 3013083 ecr 0,nop,wscale 7], length 0
05:01:47.501601 IP 10.0.0.54.44627 > 10.0.1.243.ssh: Flags [.], ack 760676524, win 115, options [nop,nop,TS val 3013083 ecr 12074896], length 0
05:01:47.535720 IP 10.0.0.54.44627 > 10.0.1.243.ssh: Flags [.], ack 22, win 115, options [nop,nop,TS val 3013092 ecr 12074928], length 0

Заключение:

Из вывода tcpdump по NAT, кажется, что Iptables нормально пересылает мои пакеты.

из дамп TCP на сервере A, у меня есть хорошее подключение от NAT к серверу A.

Но в сквозном режиме я не могу подключиться к серверу A с моего ноутбука.

( Кстати, я знаю SSH туннель и другие хорошие вещи. Но я хочу, чтобы только Iptables помог мне в этом. )

Наконец я взломал это !!!!

На экземпляре NAT мне пришлось изменить следующую команду:

От:

iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.0/16 -j MASQUERADE

Для того, чтобы:

iptables -t nat -A POSTROUTING -j MASQUERADE

И это РАБОТАЛО !!!!

Итак, я скоро создам новый вопрос о ServerFault, спрашивая, каковы преимущества и недостатки использования двух вышеуказанных команд.

• Убедитесь, что вы разрешаете tcp порт 2222inboud из 0.0.0.0/0группы безопасности для вашего поля nat
• Убедитесь, что ваш VPC «Route Table» настроен правильно.
• Как минимум две отдельные таблицы (одна связана с частной подсетью, другая связана с общедоступной подсетью)
• Ваша 10.0.1.0(частная) подсеть должна иметь правило таблицы маршрутов, например: Destination:, 0.0.0.0/0Target: "Nat box"
• Ваша 10.0.0.0(общедоступная) подсеть должна иметь правило таблицы маршрутов, такое как: Destination:, 0.0.0.0/0Target: "Internet gateway"

• Удостоверьтесь, что у вас отключена проверка источника / назначения на сетевой плате для вашего NAT-блока, без NAT-удовольствия без него. (Я знаю, что у вас уже есть это, но это действительно важно, так что в том числе для будущего зрителя)

• Убедитесь, что исходящие пакеты знают, куда идти:

  iptables --table nat --append POSTROUTING --source 10.0.0.0/16 --destination 0.0.0.0/0 --jump MASQUERADE

• Убедитесь, что пакеты inboud 2222правильно перенаправлены:

  iptables --table nat --append PREROUTING --protocol tcp --dport 2222 --jump DNAT --to-destination 10.0.1.243:22

Эти посты очень помогли мне понять AWS NAT. Поэтому я начал исследовать, что заставило iptables -t nat -A POSTROUTING -j MASQUERADEего работать.

Итак, ответ, который я нашел выше, заключается в том, что блок NAT позволяет источнику NAT «LAPTOP» IP «10 .0.0.54», в то же время выполняя назначение NAT до 10.0.1.243. В это время коробка частной подсети представляет собой ssh-запрос, поступающий только с устройства NAT. Эта команда фактически снижает безопасность сервера частной подсети. Рекомендуется использовать приведенную ниже команду для точной настройки доступа к частной подсети через ssh и NAT, как указано ниже;

iptables --table nat --append POSTROUTING --source "INTERNET IP of the Laptop" --destination 10.0.1.243 --jump MASQUERADE

Немного безопаснее:

iptables -t nat -I PREROUTING -d 52.213.216.251 -j DNAT --to-destination 10.0.1.243:22
iptables -t nat -I POSTROUTING -s 10.0.1.243 -j SNAT --to-source 52.213.216.251