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

10

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

Eu tenho a instalação do AWS VPC como abaixo.

insira a descrição da imagem aqui

META / PROBLEMA : SSH para o servidor A da Internet. E não está funcionando.

O servidor A está em uma sub-rede privada e, portanto, desejo habilitar o iptables NAT na minha instância NAT para que eu possa ssh para o SErver A diretamente da Internet

Eu estou seguindo isso e isso

Corri abaixo do comando 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 NAT:

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

MASQUERADE está sendo executado na instância 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 estão configurados corretamente para permitir vários acessos necessários para este caso de teste.

Solução de problemas:

Posso telnet do NAT para o servidor A na porta 22. Portanto, o acesso é bom.

Quando executo telnet 54.213.116.251 2222no 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

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

Mas quando executo o tcpdump no servidor A, não vejo nada proveniente do 10.0.0.54qual seja o endereço IP interno / privado do NAT ( e 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 telnetar da instância NAT para o servidor A, vejo coisas boas no tcpdump no servidor A ( isso significa que minha PREROUTINGregra geral não está funcionando como o 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 corretamente.

do dump TCP no servidor A, tenho boa conectividade do NAT ao servidor A.

Mas, de ponta a ponta, não consigo conectar ao servidor A do meu laptop.

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

slayedbylucifer
fonte
2
Desabilitou a verificação de origem / destino na sua instância NAT?
Dusan Bajic
O que isso significa? Como verificar isso? Eu procurei toda a página homem Iptables, mas é não diz nada sobre a verificação de origem / destino (a menos que eu perdi alguma coisa óbvia.)
slayedbylucifer
Você precisa fazer isso no console da web da AWS (ou CLI). docs.aws.amazon.com/AmazonVPC/latest/UserGuide/…
Dusan Bajic
Obrigado. Acho que já é Disabledpara a instância NAT.
slayedbylucifer

Respostas:

8

Finalmente, eu quebrei !!!!

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

A partir 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 funcionou !!!!

Portanto, em breve criaremos uma nova pergunta no ServerFault, perguntando quais são as vantagens e desvantagens do uso dos dois comandos acima.

slayedbylucifer
fonte
Cara, obrigado em um milhão. Teve o mesmo problema, o mesmo .... Todos os passos estavam no lugar ... mas esse "-o eth0" estava lá também. Removido, funcionou como charme. Obrigado em milhões.
Neven
O motivo pelo qual ele funciona é porque o "-s 10.0.0.0/16" diz apenas para traduzir pacotes com o ip 10.xxx de origem . Acho que seu laptop doméstico estava na sua rede doméstica e vinha de algum IP externo, portanto o NAT estava ignorando as solicitações do seu laptop. Outros podem querer rodar "ip r" na linha de comando do linux para ver se eth0 é realmente o nome do dispositivo ethernet. Caso contrário, altere-o para o nome do seu dispositivo eth (ex. Ens192 ou o que for).
Ryan Shillington
Ah, também, eu aprendi o acima lendo a página de manual do iptables. É realmente bom e não é uma leitura longa. Eu recomendo. Execute "man iptables" no prompt de comando para vê-lo em toda a sua glória.
Ryan Shillington
7
  • Certifique-se de que você está permitindo a porta tcp 2222inboud 0.0.0.0/0no grupo de segurança para sua caixa nat
  • Verifique se a sua "Tabela de rota" da VPC está configurada corretamente.
  • Pelo menos duas tabelas separadas (uma associada à sub-rede privada, uma associada à sub-rede pública)
  • Sua 10.0.1.0sub-rede (privada) deve ter uma regra da tabela de rotas como: Destino 0.0.0.0/0:, Destino: "Caixa Nat"
  • Sua 10.0.0.0sub-rede (pública) deve ter uma regra da tabela de rotas como: Destino 0.0.0.0/0:, Destino: "Gateway da Internet"
  • Verifique se a verificação de origem / destino está desabilitada na placa de rede para sua caixa de NAT, sem diversão de NATting sem ela. (Eu sei que você já tem isso, mas é realmente importante, então incluí-lo para algum visualizador futuro)

  • 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 do inboud 2222sejam redirecionados corretamente:

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

c4urself
fonte
Todas as suas sugestões já estão em vigor. Obrigado.
precisa saber é o seguinte
1
Atualizei-o para mostrar todas as etapas
c4urself
Obrigado. +1 pelos seus esforços. Seu MASQUERADEcomando não é útil no meu caso. Pode estar faltando alguma coisa. O único MASQUERADEcomando que me faz voar é o que mencionei na minha resposta .
precisa saber é o seguinte
Esse é um ótimo conselho, exceto que isso não funcionará porque você está roteando apenas 10.xxx no seu primeiro comando iptables. Ele quer encaminhar qualquer coisa vinda da internet. Veja a resposta do próprio OP abaixo.
Ryan Shillington
2

Essas postagens me ajudaram bastante no entendimento do AWS NAT. Então comecei a investigar o que fez iptables -t nat -A POSTROUTING -j MASQUERADEfuncionar.

Bem, a resposta que encontrei na declaração acima é permitir que a caixa NAT forneça ao NAT o IP 'LAPTOP' para '10 .0.0.54 'enquanto executa o NAT de destino para 10.0.1.243. No momento, a caixa de sub-rede privada é uma solicitação ssh vinda apenas do dispositivo NAT. Na verdade, este comando está diminuindo a segurança do servidor de sub-rede privado. É recomendável usar o comando abaixo para ajustar o acesso à 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
Anirban Sinha
fonte
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
Alexandre MCS
fonte