AWS VPC + IPtables + NAT: la redirection de port ne fonctionne pas

Hier, j'ai posté une question ici, mais je pense que ce n'était pas assez clair dans mes mots. BTW, Cette question n'est pas un doublon.

J'ai la configuration AWS VPC comme ci-dessous.

OBJECTIF / PROBLÈME : SSH vers le serveur A depuis Internet. Et ça ne marche pas.

Le serveur A est dans un sous-réseau privé et je souhaite donc activer le NAT iptables sur mon instance NAT afin que je puisse ssh vers SErver A directement depuis Internet

Je suis ceci et cela

J'ai exécuté la commande ci-dessous sur l'instance NAT:

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

Le transfert IP est activé sur l'instance NAT:

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

MASQUERADE s'exécute sur une instance 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

Les groupes de sécurité AWS sont correctement configurés pour permettre divers accès nécessaires à ce scénario de test.

Dépannage:

Je peux telnet du NAT au serveur A sur le port 22. Ainsi l'accès est bon.

Lorsque je cours telnet 54.213.116.251 2222sur mon ordinateur portable, je vois l'entrée ci-dessous dans tcpdump sur 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

Cela signifie donc que iptables achemine les paquets vers 10.0.1.243. (BTW, xxx.xxx.xxx.xxxest l'adresse IP publique de mon ordinateur portable)

Mais lorsque j'exécute tcpdump sur le serveur A, je ne vois rien provenant de 10.0.0.54l'adresse IP interne / privée de NAT ( et je pense que c'est le problème ):

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 

Mais si je telnet de l'instance NAT au serveur A, je vois de bonnes choses dans tcpdump sur le serveur A ( cela signifie que ma PREROUTINGrègle générale ne fonctionne pas comme prévu ):

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

Conclusion:

De la sortie de tcpdump sur NAT, il semble que Iptables transmette bien mes paquets.

du TCP dump sur le serveur A, j'ai une bonne connectivité du NAT au serveur A.

Mais de bout en bout, je ne peux pas me connecter au serveur A depuis mon ordinateur portable.

( BTW, je connais le tunnel SSH et d'autres bonnes choses. Mais je ne veux que des Iptables pour m'aider. )

Enfin, je l'ai craqué !!!!

Sur l'instance NAT, j'ai dû changer la commande ci-dessous:

De:

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

À:

iptables -t nat -A POSTROUTING -j MASQUERADE

Et cela a fonctionné !!!!

Donc, je vais bientôt créer une nouvelle question sur ServerFault demandant quels sont les avantages et les inconvénients de l'utilisation des deux commandes ci-dessus.

• Assurez-vous que vous autorisez le port 2222TCP à partir 0.0.0.0/0du groupe de sécurité pour votre boîte nat
• Assurez-vous que votre VPC "Route Table" est correctement configuré.
• Au moins deux tables distinctes (une associée au sous-réseau privé, une associée au sous-réseau public)
• Votre 10.0.1.0sous-réseau (privé) doit avoir une règle de table de routage comme: Destination 0.0.0.0/0:, Cible: "Nat box"
• Votre 10.0.0.0sous-réseau (public) doit avoir une règle de table de routage comme: Destination 0.0.0.0/0:, Cible: "Passerelle Internet"

• Assurez-vous que la vérification de la source / destination est désactivée sur la carte réseau pour votre boîte NAT, pas de plaisir NATting sans. (Je sais que vous l'avez déjà, mais c'est vraiment important, donc l'inclure pour un futur spectateur)

• Assurez-vous que les paquets sortants savent où aller:

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

• Assurez-vous que les paquets inboud 2222sont correctement redirigés:

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

Ces articles m'ont beaucoup aidé à comprendre AWS NAT. J'ai donc commencé à enquêter sur ce qui a fait que iptables -t nat -A POSTROUTING -j MASQUERADEcela fonctionnait.

Eh bien, la réponse que j'ai trouvée est de permettre à la boîte NAT de source NAT l'IP 'LAPTOP' à '10 .0.0.54 'tout en effectuant le NAT de destination à 10.0.1.243. Pour le moment, la boîte de sous-réseau privé est une demande ssh provenant uniquement du périphérique NAT. Cette commande diminue en fait la sécurité du serveur de sous-réseau privé. Il est recommandé d'utiliser la commande ci-dessous pour affiner l'accès au sous-réseau privé via ssh et NAT comme indiqué ci-dessous;

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

Un peu plus sûr:

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