☰

Configuração de NIC da AWS

tag-icon • tag-icon linux ubuntu networking amazon-web-services amazon-ec2
Configuração de NIC da AWS

Estou tentando configurar uma instância EC2 para um caso de uso específico. Para isso precisarei de 2 ENI com endereço IP exposto publicamente. (Ambos devem ser pingáveis)

Eu fiz os seguintes passos até agora:

  • 2 interfaces de rede anexadas de uma mesma sub-rede
  • Executar instância
  • Criados 2 endereços Elastic IP, anexados a cada placa ENI da instância.

Posso ver o seguinte resultado na seção de interfaces de rede da instância EC2.

IP Público

Mas não consegui fazer ping 3.104.193.180.

Também o meu ip addressdá o seguinte resultado. . .

ubuntu@ip-172-31-37-139:~$ ip address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc fq_codel state UP group default qlen 1000
    link/ether 06:ce:dd:28:5b:b8 brd ff:ff:ff:ff:ff:ff
    inet 172.31.37.139/20 brd 172.31.47.255 scope global dynamic eth0
       valid_lft 3460sec preferred_lft 3460sec
    inet6 fe80::4ce:ddff:fe28:5bb8/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc fq_codel state UP group default qlen 1000
    link/ether 06:a6:9a:4a:98:c6 brd ff:ff:ff:ff:ff:ff
    inet 172.31.41.29/20 brd 172.31.47.255 scope global dynamic eth1
       valid_lft 3460sec preferred_lft 3460sec
    inet6 fe80::4a6:9aff:fe4a:98c6/64 scope link
       valid_lft forever preferred_lft forever

Então minhas perguntas são. . .

  • O que devo fazer para obter outro IP exposto/pingável?
  • Como devo saber meu IP elástico de dentro do servidor?

Responder1

Para obter o endereço IP público associado a uma determinada interface, primeiro obtenha o endereço MAC da interface e, em seguida, recupere as informações que você está procurando no Instance Metadata Service (IMDS). Portanto, no seu exemplo acima, eth1 possui endereço MAC 06:a6:9a:4a:98:c6, então você pode obter o endereço IPv4 público com:

curl http://169.254.169.254/latest/meta-data/network/interfaces/macs/02:1d:90:af:65:a3/public-ipv4s

Há mais informações ema documentação da AWS

Em relação ao seu problema de conectividade, como primeira etapa, verifique novamente o roteamento de VPC, a ACL e a configuração do grupo de segurança associado a cada uma de suas ENIs. Esses detalhes são fáceis de configurar incorretamente e podem resultar em queda de tráfego se você perder alguma coisa. Verifique esses detalhes primeiro e depois volte e leia o restante desta postagem. Há outro problema mais sutil que surge especificamente quando você tem vários ENIs associados a uma instância e pode ser o seu problema.

AWS VPC implementa proteções rigorosas contra falsificação. Isso é bom, pois protege a AWS e seus clientes contra a participação em diversas formas de ataque à rede, caso uma instância seja comprometida por algum motivo. No entanto, é algo que você precisa levar em consideração ao anexar múltiplas ENIs às instâncias.

A questão é que o comportamento básico do roteamento é orientado apenas pelodestinode um pacote de saída. Isto significa que a resposta a um pacote de entrada pode não ser transmitida através da mesma interface na qual o pacote original foi recebido. Mas para uma VPC, isso é considerado um pacote “falsificado”, pois o endereço de origem no pacote de resposta não corresponde a nenhum dos endereços IP privados associados ao ENI.

Considere a seguinte configuração de interface e tabela de roteamento:

admin@ip-10-0-0-115:~$ ip -4 addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000
    altname enp0s5
    inet 10.0.0.115/24 brd 10.0.0.255 scope global dynamic ens5
       valid_lft 2801sec preferred_lft 2801sec
3: ens6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000
    altname enp0s6
    inet 10.0.0.8/24 brd 10.0.0.255 scope global dynamic ens6
       valid_lft 2889sec preferred_lft 2889sec


admin@ip-10-0-0-115:~$ ip ro
default via 10.0.0.1 dev ens5
10.0.0.0/24 dev ens5 proto kernel scope link src 10.0.0.115
10.0.0.0/24 dev ens6 proto kernel scope link src 10.0.0.8

Neste caso, 10.0.0.8 é um endereço atribuído a ens6. Um pacote de entrada para este endereço IP será recebido via ens6 e processado conforme esperado. Mas uma resposta de saída para esse pacote será roteada de acordo com a tabela de roteamento acima e sairá via ens5 e será descartada pelo VPC.

Você pode testar isso assim:

admin@ip-10-0-0-115:~$ ip ro get 8.8.8.8 from 10.0.0.8
8.8.8.8 from 10.0.0.8 via 10.0.0.1 dev ens5 uid 1000
    cache

Observe que o dispositivo é ens5, embora 10.0.0.8 esteja atribuído a ens6! A VPC eliminaria esse tráfego!

Para garantir que seus pacotes sejam entregues pela VPC, você precisa implementarroteamento de política. Em termos gerais, o roteamento de política refere-se à situação em que o seu sistema utiliza informações adicionais além do destino para tomar decisões de roteamento. Neste caso, você também precisa levar em consideração o endereço IP de origem. O que precisamos fazer aqui é garantir que qualquer pacote de saída com endereço de origem 10.0.0.8 saia via ens6.

O roteamento de política no Linux normalmente é configurado usando o ip(8)comando. Para fazer a instância com a tabela de roteamento acima funcionar, você desejará criar uma tabela de roteamento secundária específica para ens6. A manipulação de tabelas secundárias funciona exatamente como a manipulação da tabela 'principal', exceto que você especifica um ID de tabela. Então, neste caso podemos adicionar uma rota para a rede local e uma rota padrão através do gateway para a tabela 10000 assim:

admin@ip-10-0-0-115:~$ sudo ip ro add 10.0.0.0/24 dev ens6 table 10000
admin@ip-10-0-0-115:~$ sudo ip ro add default via 10.0.0.1 table 10000
admin@ip-10-0-0-115:~$ ip ro show table 10000
default via 10.0.0.1 dev ens6
10.0.0.0/24 dev ens6 scope link

E crie uma regra para rotear o tráfego de saída de 10.0.0.8 de acordo com esta tabela:

admin@ip-10-0-0-115:~$ sudo ip rule add from 10.0.0.8/32 table 10000 pref 10000
admin@ip-10-0-0-115:~$ ip rule
0:      from all lookup local
10000:  from 10.0.0.8 lookup 10000
32766:  from all lookup main
32767:  from all lookup default

Observe a presença da regra 10000 mostrando que o tráfego da versão 10.0.0.8 será roteado através da tabela 10000.

Podemos confirmar isso ip ro getnovamente:

admin@ip-10-0-0-115:~$ ip ro get 8.8.8.8 from 10.0.0.8
8.8.8.8 from 10.0.0.8 via 10.0.0.1 dev ens6 table 10000 uid 1000
    cache

Observe que ele está sendo roteado de acordo com a tabela 10000, mas o mais importante é que será enviado via dispositivo ens6!

O Amazon Linux configura regras de roteamento de políticas como essa automaticamente quando você tem várias ENIs anexadas à sua instância. Não sei se o Ubuntu faz isso, então talvez você precise fazer um pouco de pesquisa sobre esse assunto e possivelmente implementar sua própria automação para sua situação específica.

informação relacionada