[eside-ghost] alta disponibilidad en routing basico
Ender
eduvedder en terra.es
Jue Jul 21 14:52:42 CEST 2005
Aupa Topo!
Este email responde a uno de Topo de hace bastante tiempo donde explicaba una
serie de técnicas para conseguir alta disponibilidad de servicios utilizando
2 conexiones a internet. Como es de hace un webo no he querido "responderlo".
La idea era conectar las 2 lineas de inernet a un router linux y que este
router haga doble nat a cada servidor; habría 2 dnss y bla, bla bla...
(nota: pego el mail de Topo al final de este mail).
Hablabas del mecanismo inherente del servicio DNS. Se supone que cuando hay
que hacer una resolución DNS sólo se pregunta al DNS primario, sólo si éste
está caido se pregunta al DNS secundario (que tendría la otra ip de la
máquina). Pero.....
¿que pasa si la red está saturada durante un momento y el servidor primario no
responde o tarda mucho en responder? supongo que se le haría la pregunta al
servidor secundario, que devolvería la ip de backup que teníamos.... hasta
aquí no habría problema, porque por esa ip tambien se puede acceder al
servidor final, pero.... ¿EL PAQUETE DE VUELTA?
el servidor final responde el paquete que va al router linux, y éste, como
tiene las 2 líneas bien manda a internet el paquete por su ruta por defecto
(que sería la primera y le pondría al paquete direccion origen la principal),
por lo que al cliente inicial le llegaría un paquete desde una direccion ip
distinta a la dirección ip que quería atacar..... ¿no?
Esto se solucionaría consiguiendo que el router linux pudiera devolver las
respuestas de los paquetes por el gateway del interfaz de red por el que
recibio el paquete original.... ¿ES POSIBLE ESTO?
¿se me entiende?
Es que el otro dia se nos fue abajo una frame relay y consegui montar lo que
Topo comentaba (con 2 firewalls en lugar uno) de esta forma:
INET1 -- FW1 ------|----DNS1
|
MAQUINA
|
INET2 -- FW2 ------|----DNS2
Se nos cayó la línea 1 y puse a funcionar la línea 2.... pero cuando levantó
la línea 1 algunos paquetes nos llegaban por ahi y otros por la 2, y
"MAQUINA" devolvía todos evidentemente por su gateway por defecto (que es lo
que creo que haría el router linux).
Como "MAQUINA" era una solaris, probé a meter 2 gateways a pelo y cual fue mi
sorpresa al comprobar que los paquetes que entraban por la línea uno los
mandaba a FW1 y los que entraban por la linea 2 los mandaba a FW2.... (ni
idea de por qué)
la tabla de rutas ha quedado asi....
root en v240:~# netstat -nrv
Destination Mask Gateway
------------------------------------------------------------------
192.168.1.0 255.255.255.0 192.168.1.32 bge0
192.168.3.0 255.255.255.0 192.168.3.11 bge2
default 0.0.0.0 192.168.1.1
default 0.0.0.0 192.168.3.1
¿funcionaria esto tambien en linux? ¿por que funciona en solaris? (tengo
snifadas de los 2 interfaces para demostrarlo, si quereis las mando)
Me parece muy interesante e importante conseguir este comportamiento.... tanto
a nivel de un firewall como una máquina que tenga 2 tarjetas de red y pueda
salir a internet por cualquiera de las 2... (la idea es que lo que recibe por
un lado lo devuelva por el mismo, ya que tiene 2 ips de nat distintas).
Saludos y siento la chapa,
Ender
> Aupa zgor!
>
> Casualmente durante este ultimo año me he rayado mucho con ese tema pq
> tenemos un proyecto entre manos para hacer una redundancia total a nivel de
> red y aplicacion.
>
> Primero, tienes que decidir si quieres el "fail-over" para conexiones
> entrantes (es decir, servicios que ofreces al exterior), o para conexiones
> salientes (navegar).
>
> [lo que te cuento no requiere ningun hardware especial, con lo que el coste
> es 0, pq imagino tendras ya un router linux que hace de firewall]
>
> En el primer caso la mejor solucion mas barata (sin contratar BGP entre los
> ISP) e inteligente pasa por jugar con el NAT y usar el "fail-over"
> inherente al servicio DNS. La movida, tal y como la pense, sería asi:
>
> 1) Conectas ambas lineas de los proveedores de internet que tienes, a un
> router/firewall linux tuyo. Cada proveedor te dara un rango de direcciones
> IP distinto.
>
> 2) A los servidores de tu DMZ, les pones direcciones IP INTERNAS. Con el
> router linux haces un NAT para traducir cada una de esas direcciones IP
> interna hacia 2 direcciones ip reales, una de CADA PROVEEDOR.
>
> 3) Tus servidores DNS por tanto, como todos los demas, tendran 2
> direcciones reales, una de cada servidor. Lo que hay que hacer es DELEGAR
> tu dominio en un DNS primario que sera la IP-1 real de tu server DNS, y
> secundario la IP-2 de tu DNS. De tal manera que ambos son el mismo server
> pero distintas IPs.
>
> 4) Aqui viene el meollo de la cuestion. En cada servidor DNS resuelves los
> registros A a distintas IPs. En el servidor DNS_A con IP real de telefonica
> (imaginemos), resolvera www.zgor.com a IP-1. Mientras que el DNS_B con IP
> real de otro proveedor (imaginemos), resolvera www.zgor.com a IP-2 (este
> DNS, no replica al primario!).
> Tus clientes cuando quieran ver tu web, usaran el DNS_A y resolveran a
> IP-1. PERO, si la conexion con telefonica cae, tus clientes fallaran al
> acceder a DNS_A, y accederan al secundario DNS_B que resolvera www.zgor.com
> a IP-2 con lo que de forma automatica entraran por la otra conexion activa.
> La historia es poner un TTL bajo, para que cuando tu conexion principal se
> levante, los clientes entren por ella.
>
> Lo wapo de este asunto es que el mecanismo inherente al servicio DNS hace
> el failover sin necesidad de ningun hardware especial. Incluso si en vez de
> un router linux, pones 2 con VRRP, y en vez de un servidor web, pones 2 por
> VRRP y roundrobin DNS, tienes un failover total con balanceo de carga
> parcial y ni un solo "single point of failure". Genial.
>
> Esto funciona que te cagas para ofrecer servicios al exteior. Para lo otro,
> conexiones salientes para que los usuarios de tu empresa naveguen, tienes
> que usar otra cosa.
> Lo que has comentado de SNMP no vale por la sencilla razon de que el fallo
> puede estar en un router de zona de tu ISP, y ni tus routers ni los
> inmediatamente conectados a ti, se darian cuenta y lo reportarian (a no ser
> que haya algun protocolo de enrutado dinamico llegando hasta ti).
> Lo mejor, mas sencillo pero efectivo es lo que has comentado del script que
> pingee. En vez de pingar quizas es mejor lanzar SYN a puertos 80 de
> servidores web de internet y esperar SYN-ACK respuesta. Si lo haces con 10
> servidores y ninguno responde es claro que tu linea ha caido, entonces
> peudes cambiar los pesos en las rutas por defecto del router.
>
> Yo tengo ese script implementado, si te interesa te lo rulo.
>
> Espero que esto te sirva.
>
> Un saludo!
>
> Topo[LB]
>
> > -----Original Message-----
> > From: eside-ghost-bounces en deusto.es
> > [mailto:eside-ghost-bounces en deusto.es]On Behalf Of zgor
> > Sent: jueves, 10 de febrero de 2005 13:07
> > To: Lista de eside-ghost
> > Subject: [eside-ghost] alta disponibilidad en routing basico
> >
> >
> > Aupi,
> > Tengo una pequeña duda ....
> > Si por ejemplo tenemos un router gnu linux con dos posibles accesos a
> > internet (no balanceados pero si disponibles ambos) directamente
> > conectados a su/sus ifaces (dos adsls, cable modems, ...
> > cualquier cosa
> > ethernet vamos), como hariais para detectar un fallo en un acceso y
> > actuar en base a ello (cambiar la default route basicamente)?
> >
> > He estado mirando historias de LVS y tal pero en principio
> > creo que no
> > me sirven, son más bien para redundar hosts con servicios o incluso
> > routers, pero el caso es que no es el router gnu linux el que
> > puede fallar.
> > Lo que tengo pensado es un un mini script que envia un ping a
> > un host de
> > internet con garantia muy alta de estar vivo (kernel.org,
> > google ....,
> > una ip de paso de un router de nuestro isp ...) y si no hay respuesta
> > tras X intentos en Y tiempo maximo, se cambia la default route, de
> > mientras sigue en background comprobando si ha vuelto el
> > acceso original
> > para dejar la ruta por defecto como estaba antes (para ello enviar un
> > ping pero con ruta especifica).
> > El caso es que me parece un poco chapucero, quizas seria
> > mejor mirar por
> > snmp si esta el iface levantado/caido, pero eso tampoco es
> > una garantia
> > de que nuestro isp nos esté encaminando.... Tambien se podria hacer
> > quizas con nagios, lo que no se es si el check_ping que trae
> > se le puede
> > pasar por parametro una ruta especifica.
> >
> > Aunque pensandolo bien, tambien se podria configurar el routing para
> > encaminar por ejemplo un hostA (que no se suela acceder mucho) por el
> > acceso secundario y viceversa con un HostB y bastaria con
> > pingar a esos
> > dos hosts sin preocuparse por donde vaya porque se supone que ya esta
> > configurada la ruta ... ummm
> >
> > Luego tambien se plantea la historia de los servicios que
> > estén detrás
> > de esa maquina, mail, web, etc .... el caso es que abría que
> > modificar
> > nuestros dns para que apunten a la nueva ip (la del otro
> > acceso), eso se
> > podria hacer si por ejemplo tenemos el dns fuera y ejecutar
> > un comando
> > automatico que intercambie las configuraciones del dns ... no
> > se, como
> > lo veis ? Mucho cristo? Quizas sea mejor confiar en que el ISP no nos
> > dejará tirados?
> >
> > Justo antes de enviar este mail he encontrado:
> > http://www.ssi.bg/~ja/nano.txt, que parece interesante, quizas sea la
> > solucion....aunque la problematica de los servicios por dns seguira
> > existiendo
> >
> > no se, como lo veis?
> >
Más información sobre la lista de distribución eside-ghost