AWS VPC + IPtables + NAT: Port Forwarding non funziona

Ieri ho pubblicato una domanda qui, ma penso che non sia stato abbastanza chiaro nelle mie parole. A proposito, questa domanda non è un duplicato.

Ho l'installazione di AWS VPC come di seguito.

OBIETTIVO / PROBLEMA : SSH sul server A da Internet. E non funziona.

Il server A è in sottorete privata e quindi voglio abilitare il NATing iptables sulla mia istanza NAT in modo che io possa ssh a SErver A direttamente da internet

Sto seguendo questo e questo

Ho eseguito sotto il comando sull'istanza NAT:

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

L'inoltro IP è abilitato sull'istanza NAT:

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

MASQUERADE è in esecuzione su istanza 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

I gruppi di sicurezza AWS sono configurati correttamente per consentire vari accessi necessari per questo caso di test.

Risoluzione dei problemi:

Posso telnet da NAT al server A sulla porta 22. Quindi l'accesso è buono.

Quando corro telnet 54.213.116.251 2222sul mio laptop, vedo di seguito la voce in tcpdump su 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

Quindi significa che iptables sta instradando i pacchetti 10.0.1.243. (A proposito, xxx.xxx.xxx.xxxè l'indirizzo IP pubblico del mio laptop)

Ma quando eseguo tcpdump sul Server A, non vedo nulla proveniente da 10.0.0.54quale sia l'indirizzo IP interno / privato di NAT ( e penso che questo sia il 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 

Ma se telnet dall'istanza NAT al server A, vedo cose buone in tcpdump sul server A ( Ciò significa che la mia PREROUTINGregola generale non funziona come previsto ):

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

Conclusione:

Dall'output di tcpdump su NAT, sembra che Iptables stia inoltrando bene i miei pacchetti.

dal dump TCP sul server A, ho una buona connettività dal NAT al server A.

Ma in End-to-end, non riesco a collegarmi al server A dal mio laptop.

(A proposito, conosco il tunnel SSH e altre cose buone. Ma voglio solo Iptables che mi aiuti in questo. )

Finalmente l'ho rotto !!!!

Sull'istanza NAT, ho dovuto modificare il comando seguente:

A partire dal:

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

Per:

iptables -t nat -A POSTROUTING -j MASQUERADE

E ha funzionato !!!!

Quindi, creerò presto una nuova domanda su ServerFault che chiede quali sono i vantaggi e gli svantaggi nell'uso dei due comandi precedenti.

• Assicurati di consentire la porta tcp 2222inboud dal 0.0.0.0/0gruppo di sicurezza per la tua casella nat
• Assicurati di avere impostato correttamente la "Tabella rotte" di VPC.
• Almeno due tabelle separate (una associata alla sottorete privata, una associata alla sottorete pubblica)
• La tua 10.0.1.0sottorete (privata) dovrebbe avere una regola della tabella di instradamento come: Destinazione 0.0.0.0/0:, Destinazione: "Scatola nat"
• La tua 10.0.0.0sottorete (pubblica) dovrebbe avere una regola di tabella di route come: Destinazione 0.0.0.0/0:, Destinazione: "Gateway Internet"

• Assicurati di avere il controllo di origine / destinazione disabilitato sulla scheda NIC per la tua casella NAT, senza divertimento NATting senza di essa. (So ​​che hai già questo, ma è davvero importante, quindi includilo per qualche futuro spettatore)

• Assicurati che i pacchetti in uscita sappiano dove andare:

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

• Assicurati che i pacchetti inboud vengano 2222reindirizzati correttamente:

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

Questo post mi ha aiutato molto a comprendere AWS NAT. Quindi ho iniziato a indagare su cosa iptables -t nat -A POSTROUTING -j MASQUERADEha funzionato.

Bene, la risposta che ho trovato nell'affermazione di cui sopra sta consentendo alla scatola NAT di generare NAT dall'IP 'LAPTOP' a '10 .0.0.54 'mentre allo stesso tempo esegue il NAT di destinazione al 10.0.1.243. Al momento la sottorete privata è una richiesta SSH proveniente solo dal dispositivo NAT. Questo comando sta effettivamente diminuendo la sicurezza del server subnet privato. Si consiglia di utilizzare il comando seguente per ottimizzare l'accesso alla sottorete privata tramite ssh e NAT box, come indicato di seguito;

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

Un po 'più sicuro:

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