AWS VPC + IPtables + NAT: el reenvío de puertos no funciona

Ayer, publiqué una pregunta aquí, pero creo que no fue lo suficientemente clara en mis palabras. Por cierto, esta pregunta no es un duplicado.

Tengo la configuración de AWS VPC como se muestra a continuación.

OBJETIVO / PROBLEMA : SSH al servidor A desde internet. Y no está funcionando.

El servidor A se encuentra en una subred privada y, por lo tanto, quiero habilitar el NAT de iptables en mi instancia de NAT para poder enviar ssh al servidor A directamente desde internet

Estoy siguiendo esto y esto

Ejecuté debajo del comando en la instancia NAT:

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

El reenvío de IP está habilitado en la instancia NAT:

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

MASQUERADE se ejecuta en la instancia 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

Los grupos de seguridad de AWS están configurados correctamente para permitir diversos accesos necesarios para este caso de prueba.

Solución de problemas:

Puedo hacer telnet desde NAT al servidor A en el puerto 22. Entonces el acceso es bueno.

Cuando ejecuto telnet 54.213.116.251 2222en mi computadora portátil, veo la entrada a continuación en tcpdump en 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

Entonces significa que iptables está enrutando los paquetes 10.0.1.243. (Por cierto, xxx.xxx.xxx.xxxes la dirección IP pública de mi computadora portátil)

Pero cuando ejecuto tcpdump en el Servidor A, no veo nada proveniente de 10.0.0.54la dirección IP interna / privada de NAT ( y creo que este es el problema ):

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 

Pero si hago telnet desde la instancia NAT al Servidor A, veo cosas buenas en tcpdump en el Servidor A ( Esto significa que Mi PREROUTINGregla general no funciona como se esperaba ):

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

Conclusión:

Desde la salida de tcpdump en NAT, parece que Iptables reenvía mis paquetes bien.

del volcado TCP en el servidor A, tengo buena conectividad de NAT al servidor A.

Pero en extremo a extremo, no puedo conectarme al servidor A desde mi computadora portátil.

( Por cierto, conozco el túnel SSH y otras cosas buenas. Pero solo quiero que Iptables me ayude con esto ) .

¡Finalmente, lo descifré!

En la instancia de NAT, tuve que cambiar el siguiente comando:

De:

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

A:

iptables -t nat -A POSTROUTING -j MASQUERADE

¡¡¡¡Y funcionó!!!!

Por lo tanto, pronto crearé una nueva pregunta en ServerFault preguntando cuáles son las ventajas y desventajas de usar los dos comandos anteriores.

• Asegúrese de permitir el puerto tcp 2222inboud desde 0.0.0.0/0el grupo de seguridad para su caja nat
• Asegúrese de tener su VPC "Tabla de ruta" configurada correctamente.
• Al menos dos tablas separadas (una asociada con la subred privada, otra asociada con la subred pública)
• Su 10.0.1.0subred (privada) debe tener una regla de tabla de ruta como: Destino:, 0.0.0.0/0Destino: "Cuadro nacional"
• Su 10.0.0.0subred (pública) debe tener una regla de tabla de rutas como: Destino:, 0.0.0.0/0Destino: "Puerta de enlace de Internet"

• Asegúrese de que la comprobación de origen / destino esté deshabilitada en la NIC para su casilla NAT, sin diversión de NATting sin ella. (Sé que ya tienes esto, pero es realmente importante, así que incluirlo para algún espectador futuro)

• Asegúrese de que los paquetes salientes sepan a dónde ir:

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

• Asegúrese de que los paquetes inboud se redirijan 2222correctamente:

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

Estas publicaciones me ayudaron mucho a comprender AWS NAT. Entonces comencé a investigar qué hizo iptables -t nat -A POSTROUTING -j MASQUERADEque funcionara.

Bueno, la respuesta que encontré en la declaración anterior es permitir que el cuadro NAT origine NAT la IP 'LAPTOP' a '10 .0.0.54 'mientras realiza el NAT de destino a 10.0.1.243. En este momento, el cuadro de subred privada es una solicitud ssh que proviene únicamente del dispositivo NAT. Este comando en realidad está disminuyendo la seguridad del servidor de subred privado. Se recomienda utilizar el siguiente comando para ajustar el acceso a la subred privada a través del cuadro ssh y NAT como se menciona a continuación;

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

Un poco más seguro

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