☰

Configuración de la tarjeta de red de AWS

tag-icon • tag-icon linux ubuntu networking amazon-web-services amazon-ec2
Configuración de la tarjeta de red de AWS

Estoy intentando configurar una instancia EC2 para un caso de uso específico. En eso necesitaré 2 ENI con una dirección IP expuesta públicamente. (Se debe poder hacer ping a ambos)

He realizado los siguientes pasos hasta ahora:

  • Se adjuntan 2 interfaces de red de una misma subred
  • Ejecutar instancia
  • Se crearon 2 direcciones IP elásticas, adjuntas con cada tarjeta ENI de la instancia.

Puedo ver el siguiente resultado en la sección de interfaces de red de instancias EC2.

IP pública

Pero no pude hacer ping 3.104.193.180.

También mi ip addressda el siguiente 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

Entonces mis preguntas son. . .

  • ¿Qué debo hacer para exponer/hacer ping a otra IP?
  • ¿Cómo debo saber mi IP elástica desde dentro del servidor?

Respuesta1

Para obtener la dirección IP pública asociada con una interfaz determinada, primero obtenga la dirección MAC de la interfaz y luego recupere la información que está buscando del Servicio de metadatos de instancia (IMDS). Entonces, en el ejemplo anterior, eth1 tiene una dirección MAC 06:a6:9a:4a:98:c6, por lo que puede obtener la dirección IPv4 pública con:

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

Hay más información enla documentación de AWS

Con respecto a su problema de conectividad, como primer paso, verifique nuevamente el enrutamiento de VPC, la ACL y la configuración del grupo de seguridad asociados con cada uno de sus ENI. Estos detalles son fáciles de configurar mal y pueden provocar una caída del tráfico si se pierde algo. Primero verifique esos detalles y luego regrese y lea el resto de esta publicación. Hay otro problema más sutil que surge específicamente cuando tienes múltiples ENI asociados con una instancia, y podría ser tu problema.

AWS VPC implementa estrictas protecciones contra la suplantación de identidad. Esto es bueno, ya que protege a AWS y a sus clientes contra la participación en diversas formas de ataques a la red en caso de que una instancia se vea comprometida por algún motivo. Sin embargo, es algo que debe tener en cuenta al adjuntar varios ENI a las instancias.

El problema es que el comportamiento de enrutamiento básico está impulsado únicamente por ladestinode un paquete saliente. Esto significa que es posible que la respuesta a un paquete entrante no se transmita a través de la misma interfaz en la que se recibió el paquete original. Pero para una VPC, esto se considera un paquete "falsificado", ya que la dirección de origen en el paquete de respuesta no coincide con ninguna de las direcciones IP privadas asociadas con ENI.

Considere la siguiente tabla de enrutamiento y configuración de interfaz:

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

En este caso, 10.0.0.8 es una dirección asignada a ens6. Un paquete entrante a esta dirección IP se recibirá a través de ens6 y se procesará como se esperaba. Pero una respuesta saliente a ese paquete se enrutará de acuerdo con la tabla de enrutamiento anterior, saldrá a través de ens5 y la VPC la descartará.

Puedes probar esto así:

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

Tenga en cuenta que el dispositivo es ens5, ¡aunque 10.0.0.8 esté asignado a ens6! ¡La VPC reduciría este tráfico!

Para garantizar que la VPC entregue sus paquetes, debe implementarenrutamiento de políticas. En términos generales, el enrutamiento de políticas se refiere a la situación en la que su sistema utiliza información adicional más allá del destino para tomar decisiones de enrutamiento. En este caso, también deberá tener en cuenta la dirección IP de origen. Lo que debemos hacer aquí es asegurarnos de que cualquier paquete saliente con una dirección de origen 10.0.0.8 salga a través de ens6.

El enrutamiento de políticas en Linux generalmente se configura mediante el ip(8)comando. Para que la instancia con la tabla de enrutamiento anterior funcione, querrá crear una tabla de enrutamiento secundaria específica para ens6. La manipulación de tablas secundarias funciona igual que la manipulación de la tabla 'principal', excepto que especifica una ID de tabla. Entonces, en este caso podemos agregar una ruta a la red local y una ruta predeterminada a través de la puerta de enlace a la tabla 10000 como esta:

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

Y cree una regla para enrutar el tráfico saliente desde 10.0.0.8 según esta tabla:

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 la presencia de la regla 10000 que muestra que el tráfico de 10.0.0.8 se enrutará a través de la tabla 10000.

Podemos confirmar esto ip ro getnuevamente con:

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 se enruta según la tabla 10000, pero lo más importante es que se enviará a través del dispositivo ens6.

Amazon Linux configura reglas de enrutamiento de políticas como esta automáticamente cuando tiene varios ENI adjuntos a su instancia. No sé si Ubuntu lo hace, por lo que es posible que deba investigar un poco en ese frente y posiblemente implementar su propia automatización para su situación particular.

información relacionada