Início / server / Perguntas / 669652
Accepted
Garreth McDaid
Asked: 2015-02-19 10:12:07 +0800 CST

Problemas de roteamento de instância Amazon VPC NAT

  • 772

Estou com um problema de roteamento.

Eu tenho 2 sub-redes públicas: 172.31.1.0/24 e 172.31.100.0/24

Em cada um deles, tenho uma instância NAT. Cada instância NAT é um peer OpenSwan VPN para um local remoto. Isso permite a seguinte conectividade VPN:

172.31.1.0/24 -> 192.168.1.0/24
172.31.100.0/24 -> 192.168.100.0/24

Eu configurei uma única tabela de rotas associada a ambas as minhas sub-redes públicas. isso inclui entradas de rota como segue:

192.168.1.0/24 Target = NAT instance 1
192.168.100.0/24 Target = NAT instance 2

Tudo funciona bem para o primeiro, mas não importa o que eu faça, a entrada da tabela de rotas para o último não funciona.

Nenhuma rota que configurei para NAT Instance 2 funciona. Quando eu traceroute para qualquer endereço em 192.168.100.0/24, os pacotes são enviados diretamente para 192.168.100.0/24 (e, portanto, falham) em vez de rotear via NAT Instance 2.

Eu pensei que talvez houvesse um limite para o número de instâncias NAT simultâneas em uma Tabela de Rotas, mas mesmo quando eu excluo a rota para 192.168.1.0, de modo que a única rota que existe é a rota via instância NAT 2, ainda não t trabalho.

Eu verifiquei todas as coisas usuais (verificação Src/Dst, etc.), mas nada parece estar fora do lugar. Tudo isso foi criado com o CloudFormation, portanto, não é provável que ocorra um erro manual.

amazon-web-services

1 respostas

  1. Best Answer

    A solução para isso foi bastante direta, mas levanta uma observação interessante. o uso de traceroute para depurar problemas de roteamento.

    A origem do problema era que eu não habilitei o encaminhamento de IP em nenhum host que não fosse Nat Instance 1.

    ou seja

    echo 1 > /proc/sys/net/ipv4/ip_forward

    Quando eu estava depurando, eu estava usando o comando traceroute, por exemplo

    traceroute 192.168.100.1

    Quando o encaminhamento de ip não estava habilitado na instância Nat 2, isso estava produzindo a seguinte resposta:

    [server1]$ traceroute 192.168.100.1
traceroute to 192.168.100.1 (192.168.100.1), 30 hops max, 60 byte packets

    Quando habilitei o encaminhamento de IP na instância Nat 2, a resposta mudou:

    [server1]$ traceroute 192.168.100.1
traceroute to 192.168.100.1 (192.168.100.1), 30 hops max, 60 byte packets
1  ip-172-31-100-102.ap-southeast-1.compute.internal (172.31.100.102)  0.528 ms  0.505 ms  0.491 ms

    (172.31.100.102 = Nat Instance 2)

    Isso sugere que, embora o traceroute possa estar ciente de uma rota específica para uma rede específica, ele relatará apenas uma tentativa de seguir essa rota se o roteamento for permitido no gateway padrão para essa rota.

    Caso contrário, ele tentará seguir a rota padrão e relatar sucesso ou falha apenas para a rota padrão. Tenho certeza de que isso é consistente com o design do traceroute, mas provavelmente indica que o traceroute pode não ser a melhor ferramenta para depurar problemas de roteamento (é mais uma ferramenta para depurar problemas de rede).

    • 0

relate perguntas