Да, я уже рыскал в Интернете и читал большинство популярных руководств / страниц / сообщений IPTables / DNAT.

Моя проблема

Резюме У меня VPC с несколькими подсетями. В частности, для одной подсети требуется EIP для подключения к Интернету. У меня есть веб-сервер, живущий в этой подсети. Мне нужно получить к нему доступ из позади нат (тоже в той же подсети, имеет EIP). Я пытаюсь настроить NAT так, чтобы входящий пакеты, предназначенные для определенного порта, отправляются на другой хост (по сути, мне нужен DNAT)

Часть 1: В VPC:

Я подключился по SSH к моему экземпляру NAT через мой SSH-прокси, доступный через WAN. Вот IPTables по умолчанию, которые поставляются с экземпляром amazon NAT. Ничего особенного, просто правило POSTROUTE, как и ожидалось. Экземпляр NAT имеет только один интерфейс; eth0 (и вот, но давайте сделаем вид, что этого не существует)

[root@IP_NAT ec2-user]# iptables -t nat -L --line-numbers
Chain PREROUTING (policy ACCEPT)
num  target     prot opt source               destination         

Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
num  target     prot opt source               destination     

Хорошо. Теперь давайте добавим два переадресованных порта, чтобы мой веб-сервер был доступен через NAT.

[root@IP_NAT ec2-user]# iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to-destination IP_WEBSERVER:80
[root@IP_NAT ec2-user]# iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -j DNAT --to-destination IP_WEBSERVER:443

Правильно! Пора проверить мою работу:

[root@IP_NAT ec2-user]# iptables -t nat -L --line-numbers
Chain PREROUTING (policy ACCEPT)
num  target     prot opt source               destination         
1    DNAT       tcp  --  anywhere             anywhere             tcp dpt:http to:IP_WEBSERVER:80
2    DNAT       tcp  --  anywhere             anywhere             tcp dpt:https to:IP_WEBSERVER:443

Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
num  target     prot opt source               destination         
1    MASQUERADE  all  --  ip-10-0-0-0.us-west-1.compute.internal/16  anywhere  

Итак, все выглядит так, будто должно работать нормально. Но они этого не делают. :(. Я могу использовать wget / telnet / ping / ssh, сколько душе угодно, между nat и веб-сервером. Я могу использовать telnet на некоторые порты на мой NAT, а у других просто тайм-аут. у меня есть тройной проверил, что группа безопасности AWS, управляющая экземпляром NAT, разрешает вход и выход правильных портов. Просто для тестирования я разрешил все трафик на всех портах как вход / выход. У меня все еще та же проблема.

Веб-сервер не показывает активности ни в одном из своих журналов.

Вот небольшой результат моего местный машина показывает, что меня беспокоит весь день:

LOCAL_USER@LOCAL_HOST:~$ telnet AWS_EIP 443
Trying AWS_EIP...
^C                (time out, here)
LOCAL_USER@LOCAL_HOST:~$ telnet AWS_EIP 80
Trying AWS_EIP...
^C                (time out, here)
LOCAL_USER@LOCAL_HOST:~$ telnet AWS_EIP 22
Trying AWS_EIP...
Connected to AWS_EIP.
Escape character is '^]'.
SSH-2.0-OpenSSH_6.2
asd
Protocol mismatch.
Connection closed by foreign host.

Поэтому, когда я пытаюсь открыть TCP-соединение через порт 22, все работает мгновенно. Почему мой nat не «прослушивает» порт 443 или 80, несмотря на то, что iptables явно разрешает трафик на этих портах?

В качестве последней полезной информации приведем файл sysctl.conf:

[root@IP_NAT ec2-user]# cat /etc/sysctl.conf 

# Controls IP packet forwarding
net.ipv4.ip_forward = 1

# Controls source route verification
net.ipv4.conf.default.rp_filter = 0

# Do not accept source routing
net.ipv4.conf.default.accept_source_route = 1

# Controls the System Request debugging functionality of the kernel
kernel.sysrq = 0

# Controls whether core dumps will append the PID to the core filename.
# Useful for debugging multi-threaded applications.
kernel.core_uses_pid = 1

# Controls the use of TCP syncookies
net.ipv4.tcp_syncookies = 1

Есть мысли относительно того, почему пакеты даже не доходят до моего веб-сервера?