encaminhamento de porta por meio do AWS VPC NAT

3

Sim, eu já vasculhei a internet e li a maioria dos guias / páginas / postagens populares do IPTables / DNAT.

Meu problema

Resumo Eu tenho um VPC com várias sub-redes. Uma sub-rede, em particular, requer um EIP para conectividade à Internet. Eu tenho um servidor web que vive nesta sub-rede. Eu preciso acessá-lo de por trás de um nat (também na mesma sub-rede, tem um EIP). Eu estou tentando configurar o meu NAT para que entrada pacotes destinados a uma determinada porta são enviados para um host diferente (essencialmente eu preciso DNAT)

Parte 1: NO VPC:

Eu tenho o SSH em minha instância do NAT por meio do meu proxy SSH acessível pela WAN. Aqui está o IPTables padrão com o qual a instância amazon NAT vem. Nada de especial, apenas uma regra POSTROUTE conforme o esperado. A instância NAT possui apenas uma uma interface; eth0 (e eis, mas vamos fingir que não existe)

[root@IP_NAT ec2-user]# iptables -t nat -L --line-numbers
Chain PREROUTING (policy ACCEPT)
num  target     prot opt source               destination         

Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
num  target     prot opt source               destination     

Ok. Agora vamos adicionar dois encaminhamentos de porta, assim meu servidor web pode ser acessado atrás do NAT

[root@IP_NAT ec2-user]# iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to-destination IP_WEBSERVER:80
[root@IP_NAT ec2-user]# iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -j DNAT --to-destination IP_WEBSERVER:443

certo! Hora de checar meu trabalho:

[root@IP_NAT ec2-user]# iptables -t nat -L --line-numbers
Chain PREROUTING (policy ACCEPT)
num  target     prot opt source               destination         
1    DNAT       tcp  --  anywhere             anywhere             tcp dpt:http to:IP_WEBSERVER:80
2    DNAT       tcp  --  anywhere             anywhere             tcp dpt:https to:IP_WEBSERVER:443

Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
num  target     prot opt source               destination         
1    MASQUERADE  all  --  ip-10-0-0-0.us-west-1.compute.internal/16  anywhere  

Então, parece que as coisas funcionam bem. Exceto, eles não fazem. :(. Eu posso wget / telnet / ping / ssh meu conteúdo do meu coração entre o nat eo servidor web. Eu posso fazer telnet em algumas portas para o meu NAT, mas outros apenas o tempo limite. O triple verificou se o grupo de segurança da AWS que governa a instância do NAT permite a entrada e saída corretas das portas. Apenas para testes, permiti tráfego all em todas as portas in / out. ainda tem o mesmo problema.

O servidor da Web não mostra atividade em nenhum de seus registros.

Aqui está uma pequena saída da minha máquina local mostrando o que tem me incomodado o dia todo:

LOCAL_USER@LOCAL_HOST:~$ telnet AWS_EIP 443
Trying AWS_EIP...
^C                (time out, here)
LOCAL_USER@LOCAL_HOST:~$ telnet AWS_EIP 80
Trying AWS_EIP...
^C                (time out, here)
LOCAL_USER@LOCAL_HOST:~$ telnet AWS_EIP 22
Trying AWS_EIP...
Connected to AWS_EIP.
Escape character is '^]'.
SSH-2.0-OpenSSH_6.2
asd
Protocol mismatch.
Connection closed by foreign host.

Então, quando tento abrir uma conexão TCP na porta 22, as coisas funcionam instantaneamente. Por que meu nat não está "escutando" na porta 443 ou 80, apesar de o iptables explicitamente permitir o tráfego nessas portas?

Como última informação útil, aqui está o arquivo sysctl.conf:

[root@IP_NAT ec2-user]# cat /etc/sysctl.conf 

# Controls IP packet forwarding
net.ipv4.ip_forward = 1

# Controls source route verification
net.ipv4.conf.default.rp_filter = 0

# Do not accept source routing
net.ipv4.conf.default.accept_source_route = 1

# Controls the System Request debugging functionality of the kernel
kernel.sysrq = 0

# Controls whether core dumps will append the PID to the core filename.
# Useful for debugging multi-threaded applications.
kernel.core_uses_pid = 1

# Controls the use of TCP syncookies
net.ipv4.tcp_syncookies = 1

Alguma idéia de por que os pacotes nem chegam ao meu servidor?

    
por user1521764 03.10.2013 / 01:12

2 respostas

3

A partir das informações da sua pergunta, presumo que você tenha 2 EIPs em uso. Um para o servidor NAT e outro para o servidor da Web. Se for esse o caso, o servidor NAT e todos no mundo devem poder se conectar ao servidor Web por meio de seu EIP fine, assumindo que todos os grupos de firewall / segurança estejam corretos.

Agora, estou confuso sobre o que é realmente o servidor NAT. Eu suponho que você quer um grupo de hosts por trás deste NAT para poder acessar o servidor Web e você não quer que todos esses hosts tenham seu próprio EIP? Se for esse o caso, você precisará de duas sub-redes VPC e o servidor NAT precisará fazer o SNAT (o que parece ser o que você está fazendo com a regra MASQUERADE). Para esta configuração, está documentado no link

Os requisitos básicos são (e eu fiz isso antes em um trabalho anterior):

  • É necessário um servidor NAT Gateway. O encaminhamento de IP deve ser ativado junto com uma regra de MASQUERADE no iptables (como o que você tem acima, sem as regras DNAT).
  • Pelo menos duas sub-redes são necessárias:
    • Uma sub-rede "pública" na qual a rota padrão dessa sub-rede na tabela de rotas VPC aponta para o Gateway da Internet. Todos os hosts nessa sub-rede exigem um EIP para acessar a Internet. O servidor NAT Gateway deve estar nesta sub-rede.
    • Uma sub-rede "privada" em que sua rota padrão aponta para o servidor NAT Gateway. Essa é a rede escondida pelo NAT, muito parecido com um roteador DSL em uma rede doméstica. Todos os hosts nessa sub-rede acessarão a Internet (ou os hosts na sub-rede pública se endereços EIP públicos forem usados em vez de seus endereços privados RFC1918) via NAT e seu EIP.
Finalmente, se você quiser evitar dar ao EIP um EIP, então uma coisa que eu tentaria (embora eu não tenha testado pessoalmente) é mover o servidor web para a sub-rede privada e mudar suas regras DNAT para apontar para o seu endereço interno. Obviamente, as sub-redes, rotas, etc. do VPC precisam ser configuradas de acordo com o documento da AWS acima.

    
por 03.10.2013 / 02:41
0
[root@IP_NAT ec2-user]# iptables -t nat -L --line-numbers
Chain PREROUTING (policy ACCEPT)
num  target     prot opt source               destination         
1    DNAT       tcp  --  anywhere             anywhere             tcp dpt:http to:IP_WEBSERVER:80
2    DNAT       tcp  --  anywhere             anywhere             tcp dpt:https to:IP_WEBSERVER:443

Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
num  target     prot opt source               destination         
1    MASQUERADE  all  --  ip-10-0-0-0.us-west-1.compute.internal/16  anywhere  

RESPOSTA

Para pessoas futuras que se deparam com este problema: garanta que seu grupo de segurança permita que você retorne ao IP público correto. Eu entrei no intervalo CIDR dos IPs de entrada e isso funcionou para mim usando a mesma configuração acima. Nota: o IP público do seu aplicativo da web ou nat instância não será o mesmo que o ip voltando em achei através de um nestat.

    
por 01.03.2017 / 18:16