AWS VPC + IPtables + NAT: Пересилання портів не працює

Вчора я розмістив запитання тут, але, думаю, недостатньо чіткий у своїх словах. До речі, це запитання не є дублікатом.

У мене налаштування AWS VPC, як показано нижче.

МЕТА / ПРОБЛЕМА : SSH на сервер A з Інтернету. І це не працює.

Сервер A знаходиться в приватній підмережі, і тому я хочу ввімкнути iptables NATING на моєму екземплярі NAT, щоб я міг ssh на SErver 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 налаштовані штрафом, щоб забезпечити різний доступ, необхідний для цього тестового випадку.

Вирішення проблем:

Я можу телефонувати з 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. (BTW, 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 до сервера А.

Але в кінцевому підсумку я не в змозі підключитися до сервера А зі свого ноутбука.

( До речі, я знаю тунель 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-порту 2222входити з 0.0.0.0/0групи безпеки для вашого nat box
• Переконайтесь, що у вас VPC "Таблиця маршрутів" встановлена ​​належним чином.
• Щонайменше дві окремі таблиці (одна пов'язана з приватною підмережею, а друга пов’язана із загальнодоступною підмережею)
• У вашій 10.0.1.0(приватній) підмережі повинно бути правило таблиці маршрутів на кшталт: Місце призначення:, 0.0.0.0/0Мета: "Поле Nat"
• У вашій 10.0.0.0(загальнодоступній) підмережі повинно бути правило таблиці маршрутів на кшталт: Місце призначення:, 0.0.0.0/0Мета: "Інтернет-шлюз"

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

• Переконайтеся, що вихідні пакети знають, куди йти:

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

• Переконайтесь, що пакети, що надходять, для 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