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.
Error: Your Requested widget " ai_widget-6" is not in the widget list.
- [do_widget_area above-nav-left]
- [do_widget_area above-nav-right]
- [do_widget_area footer-1]
- [do_widget id="wpp-4"]
- [do_widget_area footer-2]
- [do_widget id="recent-posts-4"]
- [do_widget_area footer-3]
- [do_widget id="recent-comments-3"]
- [do_widget_area footer-4]
- [do_widget id="archives-4"]
- [do_widget_area logo-bar]
- [do_widget id="oxywidgetwpml-3"]
- [do_widget_area menu-bar]
- [do_widget id="search-3"]
- [do_widget_area sidebar]
- [do_widget id="search-4"]
- [do_widget id="ai_widget-2"]
- [do_widget id="categories-5"]
- [do_widget id="ai_widget-3"]
- [do_widget id="ai_widget-4"]
- [do_widget id="ai_widget-5"]
- [do_widget_area sub-footer-1]
- [do_widget id="text-4"]
- [do_widget_area sub-footer-2]
- [do_widget_area sub-footer-3]
- [do_widget_area sub-footer-4]
- [do_widget_area upper-footer-1]
- [do_widget id="search-2"]
- [do_widget id="recent-posts-2"]
- [do_widget id="recent-comments-2"]
- [do_widget id="archives-2"]
- [do_widget id="categories-2"]
- [do_widget id="meta-2"]
- [do_widget_area upper-footer-2]
- [do_widget_area upper-footer-3]
- [do_widget_area upper-footer-4]
- [do_widget_area widgets_for_shortcodes]
- [do_widget id="search-5"]
- [do_widget id="ai_widget-6"]
- [do_widget_area wp_inactive_widgets]
- [do_widget id="wpp-2"]
- [do_widget id="text-1"]
- [do_widget id="recent-posts-3"]
- [do_widget id="categories-3"]
- [do_widget id="archives-3"]
- [do_widget id="icl_lang_sel_widget-3"]
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)
Error: Your Requested widget " ai_widget-6" is not in the widget list.
- [do_widget_area above-nav-left]
- [do_widget_area above-nav-right]
- [do_widget_area footer-1]
- [do_widget id="wpp-4"]
- [do_widget_area footer-2]
- [do_widget id="recent-posts-4"]
- [do_widget_area footer-3]
- [do_widget id="recent-comments-3"]
- [do_widget_area footer-4]
- [do_widget id="archives-4"]
- [do_widget_area logo-bar]
- [do_widget id="oxywidgetwpml-3"]
- [do_widget_area menu-bar]
- [do_widget id="search-3"]
- [do_widget_area sidebar]
- [do_widget id="search-4"]
- [do_widget id="ai_widget-2"]
- [do_widget id="categories-5"]
- [do_widget id="ai_widget-3"]
- [do_widget id="ai_widget-4"]
- [do_widget id="ai_widget-5"]
- [do_widget_area sub-footer-1]
- [do_widget id="text-4"]
- [do_widget_area sub-footer-2]
- [do_widget_area sub-footer-3]
- [do_widget_area sub-footer-4]
- [do_widget_area upper-footer-1]
- [do_widget id="search-2"]
- [do_widget id="recent-posts-2"]
- [do_widget id="recent-comments-2"]
- [do_widget id="archives-2"]
- [do_widget id="categories-2"]
- [do_widget id="meta-2"]
- [do_widget_area upper-footer-2]
- [do_widget_area upper-footer-3]
- [do_widget_area upper-footer-4]
- [do_widget_area widgets_for_shortcodes]
- [do_widget id="search-5"]
- [do_widget id="ai_widget-6"]
- [do_widget_area wp_inactive_widgets]
- [do_widget id="wpp-2"]
- [do_widget id="text-1"]
- [do_widget id="recent-posts-3"]
- [do_widget id="categories-3"]
- [do_widget id="archives-3"]
- [do_widget id="icl_lang_sel_widget-3"]
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.
Deja una respuesta