Daniel López Azaña

Tema

Social Media

Blog

GNU/Linux, Open Source, Cloud Computing, DevOps y más...

Cómo conectar en Linux 2 interfaces de red a la misma subred de AWS

Diagrama de una instancia EC2 con múltiples interfaces de red compartiendo la misma subred dentro de la misma zona de disponibilidad en AWS

El siguiente procedimiento describe cómo permitir en Linux el uso simultáneo de 2 interfaces de red conectadas a la misma subred de AWS y que la comunicación funcione tanto a nivel interno (máquinas en la misma subred) como externo (ambas interfaces visibles desde Internet). Esto puede ser útil por ejemplo cuando queremos que una misma instancia aloje un servidor web que sirva peticiones http ó https y al mismo tiempo disponga de un servidor de websockets ws:// o wss:// que escuche en el mismo puerto 80 ó 443 respectivamente. Aunque hay otras formas de conseguirlo como configurar Nginx para que sea capaz de discriminar el tráfico web (http) del tráfico de websockets (ws) y actuar como proxy para redirigir las peticiones correspondientes al servidor de websockets, esta otra solución que planteo me parece más sencilla y en cierta medida más eficiente porque no es necesario redirigir el tráfico, lo cual siempre introducirá una pequeña latencia , y permite mantener ambos servidores totalmente independientes dentro de la misma máquina. La única pega es que necesitaremos asignar 2 direcciones IP elásticas (Elastic IP) a la misma máquina en lugar de 1, pero al mismo tiempo esto nos aportará mayor flexibilidad a la hora de establecer reglas en los grupos de seguridad o en las reglas NAT de la subred.

El siguiente ejemplo muestra cómo utilizar en una instancia EC2 con sistema operativo Ubuntu 16.04.2 LTS dos interfaces de red distintas dentro de la subred 172.31.0.0/20 que corresponde por defecto a la zona de disponibilidad eu-west-1a de Amazon Web Services. No obstante, hay que tener en cuenta que el procedimiento es perfectamente aplicable a cualquier otro direccionamiento de red y que puede usarse también en cualquier otro servidor Linux fuera de AWS.

1.- Crear nueva interfaz de red y asignarla a nuestra instancia

Desde la consola de administración de AWS crearemos una nueva interfaz de red (EC2 -> Network Interfaces -> Create Network Interface). Nos aseguraremos de que la nueva interfaz se encuentre en la misma zona de disponibilidad que la instancia o de lo contrario no podremos asignársela. En principio es indiferente usar direccionamiento IP dinámico (Private IP: auto assign) o estático especificando nuestra propia dirección IP.

Una vez creada asignaremos (Attach) la nueva interfaz a la instancia EC2 desde la misma pantalla donde la hemos creado. Cuando termine el proceso de asignación y la interfaz pase a estar disponible (estado in-use) accederemos a la instancia y levantaremos esta segunda interfaz de red:

root@ip-172-31-2-11:~# ifconfig eth1 up 
root@ip-172-31-2-11:~# ifconfig 
eth0      Link encap:Ethernet  HWaddr 06:c3:15:26:eb:ac   
          inet addr:172.31.2.11  Bcast:172.31.15.255  Mask:255.255.240.0 
          inet6 addr: fe80::4c3:15ff:fe26:ebac/64 Scope:Link 
          UP BROADCAST RUNNING MULTICAST  MTU:9001  Metric:1 
          RX packets:4983 errors:0 dropped:0 overruns:0 frame:0 
          TX packets:1344 errors:0 dropped:0 overruns:0 carrier:0 
          collisions:0 txqueuelen:1000  
          RX bytes:6716291 (6.7 MB)  TX bytes:128785 (128.7 KB) 
 
eth1      Link encap:Ethernet  HWaddr 06:b4:56:4c:9d:e2   
          inet6 addr: fe80::4b4:56ff:fe4c:9de2/64 Scope:Link 
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1 
          RX packets:8 errors:0 dropped:0 overruns:0 frame:0 
          TX packets:7 errors:0 dropped:0 overruns:0 carrier:0 
          collisions:0 txqueuelen:1000  
          RX bytes:448 (448.0 B)  TX bytes:578 (578.0 B) 
 
lo        Link encap:Local Loopback   
          inet addr:127.0.0.1  Mask:255.0.0.0 
          inet6 addr: ::1/128 Scope:Host 
          UP LOOPBACK RUNNING  MTU:65536  Metric:1 
          RX packets:160 errors:0 dropped:0 overruns:0 frame:0 
          TX packets:160 errors:0 dropped:0 overruns:0 carrier:0 
          collisions:0 txqueuelen:1  
          RX bytes:11840 (11.8 KB)  TX bytes:11840 (11.8 KB)

2.- Configurar la interfaz eth1 para que modifique la tabla de rutas cuando se active

Como se puede observar en la salida del comando ifconfig anterior, la interfaz eth1 no tiene ninguna dirección IP asignada porque no hay ninguna configuración disponible para ella. La configuración de las interfaces de red en Ubuntu/Debian se encuentra en el directorio /etc/network/interfaces.d/. Ahí encontraremos un fichero eth0.cfg correspondiente a la primera interfaz de red, así que ahí crearemos también un segundo fichero eth1.cfg con la siguiente configuración:

# The secondary network interface
auto eth1
iface eth1 inet dhcp

# Las reglas siguientes tienen el objetivo de permitir el funcionamiento de esta segunda interfaz de
# red en la misma subred que la eth0, algo que por defecto no es posible al existir en la tabla de
# rutas una ruta por defecto que siempre obliga a los paquetes a salir por la misma interfaz de red
# aunque su IP indique que proceden de la otra.

# En caso de que estas reglas no funcionen, activar filtro arp:
# sysctl -w net.ipv4.conf.all.arp_filter=1
# Si el resultado es satisfactorio, hacer el cambio permanente:
# echo "net.ipv4.conf.all.arp_filter = 1" >> /etc/sysctl.conf

# Crear tablas de enrutamiento separadas para cada interfaz de red
# Estas tablas deben estar definidas en el fichero /etc/iproute2/rt_tables:
# 10 eth0
# 20 eth1
post-up ip route add 172.31.0.0/20 dev eth0 src 172.31.2.11 table eth0
post-up ip route add 172.31.0.0/20 dev eth1 src 172.31.2.51 table eth1

# Obligar a los paquetes a salir por la interfaz de red adecuada en función de su IP de origen o destino.
post-up ip rule add from 172.31.2.11 table eth0
post-up ip rule add from 172.31.2.51 table eth1

# Indicar el mismo gateway por defecto para ambas interfaces de red.
post-up ip route add default via 172.31.0.1 dev eth1 table eth1
post-up ip route add default via 172.31.0.1 dev eth0 table eth0

# Los cambios con ip route no tienen efecto en la tabla clásica de enrutamiento (netstat -rn).
# Las siguientes reglas fuerzan a que los paquetes que se originan en la propia máquina
# siempre salgan por la eth0 por defecto.
post-up route del default
post-up route add default gw 172.31.0.1 eth0

3.- Crear tablas de enrutamiento separadas para cada interfaz de red

Editaremos el fichero /etc/iproute2/rt_tables y añadiremos al final las siguientes líneas:

10 eth0
20 eth1

4.- Reiniciar servicio de red

Una vez hechos los cambios anteriores reiniciaremos el servicio de red:

$ sudo service networking restart

Si todo ha ido bien la salida del comando ifconfig debería mostrar la interfaz eth1 con su dirección IP asignada y deberíamos poder acceder a la instancia por SSH a través de cualquiera de sus direcciones IP internas desde otras instancias de la misma subred. Sin embargo por defecto AWS no asignará ninguna IP pública a la segunda interfaz de red, por lo que si queremos poder acceder a ella desde Internet tendremos que asociarle una dirección IP elástica (elastic IP) y a partir de ese momento ya sí podremos acceder a la máquina usando cualquiera de sus IP’s públicas.

Daniel López Azaña

Sobre el autor

Daniel López Azaña

Emprendedor tecnológico y arquitecto cloud con más de 20 años de experiencia transformando infraestructuras y automatizando procesos.

Especialista en integración de IA/LLM, desarrollo con Rust y Python, y arquitectura AWS & GCP. Mente inquieta, generador de ideas y apasionado por la innovación tecnológica y la IA.

Artículos relacionados

Logo AWS EBS

Cómo ampliar el tamaño de un volumen EBS y de una partición ext4 en AWS

Cuando se nos llena completamente el sistema de ficheros de una partición ext4 alojada en un volumen EBS de Amazon Web Services y no podemos hacer nada por liberar espacio al no querer perder ninguno de los datos almacenados, el único remedio que nos queda es ampliar el volumen y hacer crecer la partición asociada hasta el 100% de su capacidad para disponer nuevamente de espacio libre de almacenamiento.Partimos en nuestro ejemplo de un volumen de 50 GB lleno al 100% que queremos ampliar a uno nuevo del doble de tamaño, 100 GB:

23 de mayo de 2017
terraform-and-route53-logos

Cómo importar rápidamente todos los registros de una zona DNS de Route53 en Terraform

El comando terraform import nos permite importar en HashiCorp Terraform recursos que ya existían previamente en el proveedor con el que estemos trabajando, es este caso AWS. Sin embargo, sólo permite importar dichos registros uno por uno, con una ejecución de terraform import cada vez. Esto, aparte de ser tremendamente tedioso, en algunas situaciones se vuelve directamente impracticable. Este es el caso de los registros de una zona DNS de Route53. La tarea puede resultar inabarcable si tenemos varias zonas DNS, y cada una tiene decenas o cientos de registros. En este artículo te ofrezco un script en bash que te permitirá importar en Terraform todos los registros de una zona DNS de Route53 en cuestión de segundos o de pocos minutos.

8 de febrero de 2022
Script para cambiar automáticamente todos los volúmenes gp2 a gp3 con aws-cli

Script para cambiar automáticamente todos los volúmenes gp2 a gp3 con aws-cli

El pasado diciembre Amazon anunció sus nuevos volúmenes EBS gp3, los cuales ofrecen mejores prestaciones y un ahorro en el coste del 20% respecto a los que se venían utilizando hasta ahora, los gp2. Pues bien, tras probar satisfactoriamente estos nuevos volúmenes en varios clientes, no puedo hacer otra cosa más que recomendar su utilización, pues son todo ventajas y en estos 2 meses y medio que han transcurrido desde el anuncio no he apreciado ningún problema ni efecto secundario.

16 de febrero de 2021

Comentarios

Sé el primero en comentar

Enviar comentario