Tengo dos ISP diferentes. Quiero establecer algún tipo de configuración de equilibrio de carga que distribuya paquetes a esos proveedores. Sé que esto se puede hacer usando diferentes tablas de enrutamiento, pero quería usar algo llamado "puerta de enlace multiruta".
He configurado ambas interfaces en el /etc/network/interfacesarchivo. Ambas conexiones funcionan por separado. Reemplacé las puertas de enlace predeterminadas con la siguiente:
# ip route add default \
nexthop via 192.168.1.1 dev bond0 weight 1 \
nexthop via 10.143.105.17 dev wwan0 weight 1
Agregué objetivos enmascarados en iptablesambas interfaces:
iptables -t nat -A POSTROUTING -o wwan0 -j MASQUERADE
iptables -t nat -A POSTROUTING -o bond0 -j MASQUERADE
También habilité (parcialmente) el filtrado de ruta inversa a través de sysctl:
net.ipv4.conf.all.rp_filter = 2
net.ipv4.conf.default.rp_filter = 2
Esta configuración funciona. Los paquetes (conexiones) se envían a través de ambas interfaces. Sólo hay un problema que no entiendo.
Cuando quiero verificar mi dirección IP usando los siguientes comandos:
$ curl text.whatisyourip.org
$ curl eko.one.pl/host.php
La dirección IP es diferente en ambos casos, lo que significa que el mecanismo funciona bien. También puedo verlo funcionando en wireshark. Pero cuando intento enviar, por ejemplo, varias solicitudes al primero de los dominios anteriores, siempre obtengo la misma dirección IP como respuesta. Entonces parece que los paquetes destinados a la dirección IP específica siempre pasan por la misma interfaz. Sólo me pregunto por qué. ¿Existe algún mecanismo que recuerde las direcciones IP de destino de las solicitudes anteriores y realice las siguientes solicitudes a las mismas direcciones para pasar por la misma interfaz?
Respuesta1
He logrado solucionar el problema. Eneste enlacepuedes leer lo siguiente:
IPv4: enrutamiento multiruta basado en hash. Cuando se eliminó el caché de enrutamiento en 3.6, el algoritmo de rutas múltiples IPv4 pasó de estar más o menos basado en el destino a ser una programación casi aleatoria por paquete. Esto aumentó el riesgo de paquetes desordenados e hizo imposible el uso de rutas múltiples junto con servicios anycast. En esta versión, la implementación del enrutamiento multiruta se reemplaza con un equilibrio de carga basado en flujo basado en un hash sobre la confirmación de fusión de las direcciones de origen y destino.
Entonces, aunque el caché se eliminó en el kernel 3.6, las solicitudes aún se almacenan en caché. Ahora importan las direcciones de origen y de destino. Por eso los paquetes pasan siempre por la misma interfaz.