Tengo dos ISP (el principal es un cable de 100Mi en 24.xxx [rápido pero poco confiable] y mi respaldo es 1.5Mi DSL en 70.xxx) para lograr redundancia y confiabilidad. Tengo firewalls de enrutador Red Hat Linux dedicados conectados a cada servicio, y estos funcionan a través de UPS. El lado LAN de cada firewall/enrutador se conecta a un conmutador de 24 puertos con el resto de los dispositivos de mi red doméstica, incluidos dos puntos de acceso wifi con el mismo SSID en diferentes canales en cada extremo de la casa.
Mi pregunta tiene dos partes;
1) ¿Cómo configuro los clientes Windows/iOS/android/linux/solaris para que conmuten por error al segundo enrutador si el servicio falla en el principal (lo que parece suceder varias veces al mes, casi siempre los sábados por la mañana)?
2) ¿Cómo les indico a los clientes que vuelvan a utilizar el enrutador principal cuando se restablezca el servicio?
¿Es posible simplemente enumerar ambos enrutadores cuando se sirve DHCP y luego dejar que el cliente resuelva lo que necesita? Esto parece que podría funcionar para la parte 1), pero no hace nada para la parte 2) a menos que falle manualmente/falso la conexión de respaldo cuando la conexión principal vuelva a estar en línea.
En última instancia, mi objetivo es mantener el servicio de Internet para todos mis dispositivos con no más de dos minutos de interrupción por cualquier interrupción del servicio, y hacerlo sin tocar ni reconfigurar ninguno de los clientes o enrutadores (manualmente) cada vez que esto suceda.
Estaría feliz de RTFM si supiera el nombre de ese manual. Gracias de antemano por cualquier consejo.
Respuesta1
Hay muchas formas de despellejar a este gato, pero keepalivedpodría ser unaopción.
keepalived es unVRRPimplementación, lo que significa que puede definir una IP "virtual" que pertenezca a uno u otro de sus enrutadores. Normalmente, se designa uno como maestro y otro como secundario. Si el maestro deja de estar disponible, el secundario toma posesión de la dirección IP.
En su escenario, esta sería la IP de la puerta de enlace de su cliente. De esa manera, siempre están hablando con la misma dirección IP, y esta va al primer o segundo enrutador dependiendo de cuál sea el maestro.
Si el enrutador maestro no funciona, esto automáticamente hace que el secundario tome el control: el maestro y el secundario intercambian paquetes de "hola" y tan pronto como el secundario ya no recibe noticias del maestro, toma el control de la IP.
Sin embargo, necesitaría más para monitorear el enlace y dejar que el maestro se ponga en modo no disponible; puede hacerlo usando "scripts de seguimiento".
Por ejemplo, aquí está la configuración del maestro:
vrrp_instance RouterVRRP {
state MASTER
interface eth0
virtual_router_id 50
priority 200
advert_int 1
virtual_ipaddress {
10.10.10.100/32 dev eth0
}
track_script {
check_google
}
}
Luego la definición del script de pista:
vrrp_script check_google {
script "/scripts/pinggoogle.sh"
interval 3 # check every 3 seconds
fall 3 # require 3 fails for down
rise 2 # require 2 successes back up
}
El script haría ping a Google y devolvería un 0 si todo está bien y un 1 si falla.