[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Balance de carga para evitar red con proxy



Estimados:

Para hacer una buena pregunta, hay que conocer gran parte de la
respuesta. Y el tema es que no tengo ni idea de lo que voy a preguntar.
Paso a detallar mi inquietud.
En mi trabajo, tengo acceso a Internet a través de dos redes: una con 6
Mbs y otra de 512 Kbs. La primera, pasa por un contrafuegos que yo no
administro, y por ende, los bloqueos que tiene en algunos aspectos son
coherentes, en otros ridículos (por ejemplo, debido que en algunos blogs
hay pornografía, bloquean TODO el blog, lo que hace imposible acceder a
aquellos alojados en el respectivo servidor, aunque traten de otros
temas).
También bloquean los puertos SSL, por lo que los correos sólo son
accesibles mediante interfaz WEB.
La segunda conexión, la lenta, no está bloqueada.
La red está armada en esto momentos con mucha gente que accede a la
conexión rápida controlada, y poca a la lenta abierta.
La conexión controlada no indica que la página es inaccesible, o sea,
“error de conexión”, si no que me remite a una página del contrafuegos
que me explica que esa página está inaccesible.
Sé cómo hacer un balanceo de carga configurando un enrutador bajo
GNU/Linux.
El problema, y por ende la pregunta:
¿Alguno puede indicarme una guía de lectura para configurar un enrutador
(Brazil Firewall sería lo ideal) donde balancear la carga, y cuando la
red controlada me dé vínculo al mensaje de alerta, lo enrute a la libre?
Esto viene a cuento, porque en lo que yo he armado, el enrutado a otra
red salta cuando hay un ERROR DE ACCESO; por lo que explicaba
previamente, esa red no da este tipo de error que sé cómo manejar, si no
que me remite a otra página, por lo que para el sistema no hay error, y
cree que ha llegado a destino, pero no es donde yo quiero llegar.
Esto me permitiría manejar la mayoría del tráfico por la red controlada
rápida, y sólo desviar a la lenta abierta aquel que requiera saltearse
el contrafuegos.
Muchas gracias.

JAP






Reply to: