AWS VPC + IPtables + NAT: o encaminhamento de porta não está funcionando

10

Ontem, postei uma pergunta aqui mas acho que não foi claro o suficiente em minhas palavras. BTW, esta questão não é uma duplicata.

Eu tenho o AWS VPC Setup como abaixo.

OBJETIVO/PROBLEMA:SSHparaoServidorAdaInternet.Enãoestáfuncionando.

OservidorAestánasub-redeprivadae,portanto,euqueroativaroNATdoiptablesnaminhainstânciadoNATparaqueeupossausarosshparacriarumdiretamentedaInternet

Estouseguindo este e isso

Eu corri o comando abaixo na instância do NAT:

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

O encaminhamento de IP é ativado na instância do NAT:

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

MASQUERADE está sendo executado na instância do 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

Os grupos de segurança da AWS são bem configurados para permitir vários acessos necessários para este caso de teste.

Solução de problemas:

Eu posso fazer telnet do NAT para o servidor A na porta 22. Então, o Access é bom.

Quando executo telnet 54.213.116.251 2222 no meu laptop, vejo a entrada abaixo no tcpdump no 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

Isso significa que o iptables está roteando os pacotes para 10.0.1.243 . (BTW, xxx.xxx.xxx.xxx é o endereço IP público do meu laptop)

Mas quando eu executo o tcpdump no Servidor A, eu não vejo nada vindo de 10.0.0.54 , que é o endereço IP Interno / Privado do NAT ( E eu acho que esse é o 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 

Mas se eu der telnet da instância NAT para o Servidor A, vejo coisas boas no tcpdump no Servidor A ( Isso significa que Minha regra geral PREROUTING não está funcionando como esperado ):

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

Conclusão:

Da saída do tcpdump no NAT, parece que o Iptables está encaminhando meus pacotes bem.

do TCP dump no Servidor A, tenho boa conectividade do NAT para o Servidor A.

Mas no End-to-end, não consigo me conectar ao servidor A do meu laptop.

( BTW, eu conheço o túnel SSH e outras coisas boas. Mas eu quero que apenas o Iptables me ajude com isso. )

    
por slayedbylucifer 28.01.2014 / 11:15

4 respostas

8

Finalmente, eu decifrei !!!!

Na instância do NAT, tive que alterar o comando abaixo:

De:

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

Para:

iptables -t nat -A POSTROUTING -j MASQUERADE

E isso funcionou !!!!

Então, eu vou criar uma nova pergunta em breve no ServerFault, perguntando quais são as vantagens e desvantagens de usar os dois comandos acima.

    
por 29.01.2014 / 08:03
7
  • Verifique se você está permitindo a porta tcp 2222 inboud de 0.0.0.0/0 no grupo de segurança de sua caixa nat
  • Verifique se você tem a configuração "Tabela de rotas" do VPC corretamente.
  • Pelo menos duas tabelas separadas (uma associada à sub-rede privada, uma associada à sub-rede pública)
  • Sua sub-rede 10.0.1.0 (privada) deve ter uma regra da tabela de rotas como: Destino: 0.0.0.0/0 , Destino: "caixa Nat"
  • Sua sub-rede 10.0.0.0 (pública) deve ter uma regra da tabela de rotas como: Destino: 0.0.0.0/0 , Destino: "gateway da Internet"
  • Certifique-se de que a opção Origem / Destino esteja desativada na NIC para sua caixa NAT, sem a NAT se divertir sem ela. (Eu sei que você já tem isso, mas é realmente importante, então incluí-lo para algum futuro espectador)

  • Verifique se os pacotes de saída sabem para onde ir:

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

  • Certifique-se de que os pacotes inboud para 2222 sejam reencaminhados corretamente:

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

por 29.01.2014 / 06:03
2

Essas postagens me ajudaram muito a entender o NAT da AWS. Então eu comecei a investigar o que fez iptables -t nat -A POSTROUTING -j MASQUERADE funcionar.

Bem, a resposta que encontrei na declaração acima é permitir que a caixa NAT forneça o NAT 'LAPTOP' IP para '10 .0.0.54 'enquanto realiza o NAT de destino para 10.0.1.243. No momento, a caixa da sub-rede privada é a solicitação ssh proveniente apenas do dispositivo NAT. Este comando está realmente diminuindo a segurança do servidor de sub-rede privada. Recomenda-se usar o comando abaixo para ajustar o acesso da sub-rede privada através da caixa ssh e NAT, conforme mencionado abaixo;

iptables --table nat --append POSTROUTING --source "INTERNET IP of the Laptop" --destination 10.0.1.243 --jump MASQUERADE
    
por 30.11.2015 / 15:06
0

Um pouco mais 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
    
por 25.08.2016 / 23:44