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

10

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.

ingrese la descripción de la imagen aquí

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 ) .

slayedbylucifer
fuente
2
¿Deshabilitó la verificación de origen / destino en su instancia NAT?
Dusan Bajic
Qué significa eso? ¿Cómo verificar eso? Busqué en toda la página de manual de Iptables, pero no dice nada sobre la verificación de origen / destino (a menos que me haya perdido algo obvio).
slayedbylucifer
Debe hacerlo en la consola web de AWS (o CLI). docs.aws.amazon.com/AmazonVPC/latest/UserGuide/…
Dusan Bajic
Gracias. Encuentro que ya es Disabledpara la instancia NAT.
slayedbylucifer

Respuestas:

8

¡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.

slayedbylucifer
fuente
Hombre gracias en un millón. Tuve el mismo problema, el mismo ... Cada paso estaba en su lugar ... pero este "-o eth0" también estaba allí. Quitado, funcionó como encanto. Gracias en millones.
Neven
La razón por la que funciona es porque el "-s 10.0.0.0/16" dice que solo traduzca los paquetes con la fuente de origen 10.xxx Supongo que su computadora portátil doméstica estaba en su red doméstica y provenía de una IP externa, por lo que el NAT estaba ignorando las solicitudes de su computadora portátil. Otros pueden querer ejecutar "ip r" en la línea de comando de Linux para ver si eth0 es realmente el nombre de su dispositivo ethernet. De lo contrario, cámbielo por el nombre de su dispositivo eth (ej. Ens192 o lo que sea).
Ryan Shillington
Ah, también, aprendí lo anterior leyendo la página de manual de iptables. Es realmente bueno y no es una lectura larga. Lo recomiendo altamente. Ejecute "man iptables" desde el símbolo del sistema para verlo en todo su esplendor.
Ryan Shillington
7
  • 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

c4urself
fuente
Todas sus sugerencias ya están en su lugar. Gracias.
slayedbylucifer
1
Lo actualicé para mostrar todos los pasos
c4urself
Gracias. +1 por tus esfuerzos. Su MASQUERADEcomando no es útil en mi caso. Puede ser que me falta algo. El único MASQUERADEcomando que me hace volar es el que he mencionado en mi respuesta .
slayedbylucifer
Este es un gran consejo, excepto que no funcionará porque solo está enrutando 10.xxx en su primer comando iptables. Quiere enrutar cualquier cosa que provenga de internet. Ver la propia respuesta de OP a continuación.
Ryan Shillington
2

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
Anirban Sinha
fuente
0

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
Alexandre MCS
fuente