El Jueves, 3 de Mayo de 2007 04:05, Juan Manuel R. escribió:

Saludos

Tengo recien instalado un sles 10 en un servidor dell con tres tarjetas de red broadcom netxtreme. ademas tendo dos canales de internet uno con adsl y otro con xdsl( inalambrico)

se me pide implementar un proxy squid + firewall y balanceo de enlaces .

* El proxy http es una complicacion seria a mayores yo te recomendaria que de momento te centres en el balanceo saliente por routing.

me surgen dos inquietudes :

1.- En el tutorial de francisco javier crespo nos dice que por lo menos debemos activar IP avanced router -> IP: equal cost multipath En sles 10 no hay una variable en sysconfig o en /proc/sys/net que podamos encender ( colocar en 1 o yes etc ) y no haya necesidad de compilar kernel o sles 10 ya trae activa esta opcion. habra algun tutorial suse para balanceo de enlaces ?

* Esa es una opcion de compilacion del kernel. * Ni en 10.1 y 10.2 es preciso activar nada asi que dudo que lo necesites en SLES 10 que no la tengo, en la 9 si que habia que parchear para la cache de rutas con los parches de anastasov.

2.- Como puedo implementar una regla de SNAT con suse firewall2. Es posible que con el susefirewall2 se pueda ejecutar scripts externos y retorne el control nuevamente al susefirewall2.

* No veo la necesidad si es para insertar rules de routing ten en cuenta el fichero /etc/sysconfig/network/config los parametros GLOBAL_POST_UP_EXEC="yes o no" GLOBAL_PRE_DOWN_EXEC="yes o no" a colocar en /etc/sysconfig/network/if-down.d y if-up.d * En cualquier caso salvo que SuSEfirewall2, en esa version, tenga caracteristicas para manejar varias wan te dara mas problemas que Beneficios y no es lo apropiado para SNAT, esta basado como casi todos los front-ends en DNAT.

Como podria insertar, en el susefirewall2 una linea como : ip route add default equalize scope global nexthop via $P2 dev $IF2 weight 1 nexthop via $P1 dev $IF1 weight 2

* Yo lo meteria mejor en /etc/sysconfig/routes * Echale un ojo a la documentacion de iproute2 en particular al fichero /etc/iproute2/rt_tables y rt_scopes * Yo seguiria el orden siguiente dar un nombre unico a cada interfaz, wan0 wan1, lan0 lan1, lan2, crear a mano las tablas, rules, y rutas para todas las redes, interfaces y localhost para las diferentes vias, activar el balanceo con la linea que propones, que esta configurada para usar desde un script de cortafuegos con variables definidas en el y que deberas ajustar a las interfaces (yo no mezclaria en suse el levantamiento de interfaces y rutas desde el script de cortafuegos), hacer traceroutes por las dos vias para ver que las rutas funcionan, lanzar peticiones y ver que el balanceo funciona y que la cache de rutas se refresca en tiempo razonable, si ok darle un ip route show y copy&paste a /etc/sysconfig/routes, un reinicio para ver que la jugada se mantiene y entonces aplicar el script de cortafuegos, que seria una llamada desde el punto de inicio que mas te convenga y empezar con el asunto del proxy.

quiero saber que tan flexible es el susefirewall2 , pues normalmente uso scripts de iptables o fwbuilder.

* Pues bastante menos flexible que un script logicamente, para este caso yo no lo usaria, que yo recuerde el unico front-end de iptables instalable que contempla el balanceo de carga (por ip/rutas) para varias wan es shorewall. * De todas maneras embocar el servidor a internet para que haga de gateway no lo veo practico ya que precisas SuSE, si me apuras que sea el proxy, yo instalaria una maquina con PfSense o ClarkConnect (version pagoware) para estos menesteres, Collax tambien parece una opcion potable. * Al final iras al balanceo por marcado, origen, destino, pesos, QoS, etc...., el balanceo por rutas es bastante menos eficiente.

El Jueves, 3 de Mayo de 2007 18:20, Juan Manuel R. escribió:

# activo el forward para la entrada iptables -A FORWARD -i $LAN_IN -j ACCEPT ahi esta la duda , pues al hacer balanceo de enlaces como hago para natear los de el otro proveedor. puedo hacer esto : iptables -t nat -A POSTROUTING -o $INTERNET -j SNAT w.x.y.z - a.b.c.d donde a.b.c.d es la ip privada fija de mi 2do proveedor. o el - solo se usa para rangos ?. Lo debo hacer con masquerade ? . No lo necesito

* Para el trafico que no maneje squid, yo solo lo pondria para http, nada de ftp o https, ten en cuenta a delegate, perdition, etc ..... iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -j MASQUERADE iptables -t nat -A POSTROUTING -o ethX -j SNAT --to-source ip_externa iptables -t nat -A POSTROUTING -o ethX1 -j SNAT --to-source la_otra_ip_externa * 0 marcar con mangle y encaminas segun las marcas por las vias, por rangos o por ip. * El parche connmark te solucionaria algun probrema de seguimiento de conexiones para deshacer el dnat de vuelta.

me acaba de surgir otra duda , para el squid normalmente yo configuro los dns colocando en la linea forwarders, del archivo named.conf, los que me da mi proveedor. pero en este caso tengo 2 proovedores entonces colocaria las 4 ips de los dns de mi proveedor1 y 2 intercaladas ?

* Ponlas intercaladas, los dns suelen ser de acceso publico aunque algun proveedor solo permite consultas desde sus redes, en un par de dias al tener tu propio dns, los forwaders tendran un uso esporadico.

De primera vista lo que veo es que podria dejar la salidas fijas . es decir los puertos 25,110 etc enlace 1 y el puerto 80 enlace 2 , y me pregunto para que me servirian entonces mis reglas de balanceo de rutas ?

* Me alegro de que veas el fondo de la cuestion, y disculpa por el rollo yo las multiwan me interesan por disponibilidad del exterior, que seguramente no tenga que ver con lo que te interesa ....... ¿por que se necesita un balanceo saliente, si en realidad dividir el trafico (sabiendo cual es el trafico y peso despues de auditado) por lo general es muy eficiente y facil de mantener por cualquiera ante caida de lineas?. * Muy pocas veces uso balanceo saliente, si no es dirigido por un demonio descubridor de rutas caidas, es decir, para proveer HA, que ademas hay varias formulas que son sistematicamente desechadas por simple snobismo de sysadmins nacidos con los exitos de las espaisgerls. * En estas historias hay que partir de un par de situaciones analizando los objetivos (reales no imaginarios) y el mantenimiento (propio o tiene que poder hacerlo otro). * Premisas: 1.- ¿la consulta http es a vida o muerte? y digo http, por que si se tienen varias lineas hay varios supuestos implicitos, servicios como correo (que NO es un servicio de mensajeria instantanea), servidor de documentacion, dns, web propia, etc, estan en la intranet, ya sea como principal/respaldo y el otro principal/respaldo esta en otro lado para el mundo, resolviendo la "disponibilidad". 1-a.- generalmente la respuesta es que no es a vida o muerte. 1-b.- que las caidas de lineas son muy esporadicas (lo contrario exige cambio del proveedor afectado) teniendo presente que un simple script de wondershaper protege con bastante eficiencia el colapso de routers y lineas, la caida de todas las lineas (muy habitual cuando se produce caida), es producto de la inconsciencia en la contratacion. * Soluciones con balanceo y administracion facil: - Routers multiwan y port tracking, a partir de unos 200 euros puedes encontrarlos con 2-3 niveles de balanceo (preconfigurados) (linksys por ejemplo tiene varios modelos interesantes), desconozco los combinados adsl/xdsl. - A mi no me va, por que no quiero los routers accesibles desde internet ni en pintura, si quieres muchas capacidades entra en juego el precio y yo por aqui no paso en la relacion hierro contra linux/bsd, la agregacion es a nivel de broadcast y se pierden capacidades de red es decir te limita a lo que hay en el hierro, SI lo uso (por ser solucion de facil administracion y no hacer de pringao) por ejemplo en redes ltsp implementadas a entidades sin animo de lucro, sin administrador o con grandes limitaciones, es decir los terminales/usuarios ya estan controlados por un servidor linux al que estan embocados el/los routers. - Una distribucion dedicada a estos fines (Clarkconnect por ejemplo) unos 150 con todos los modulos de auditoria grafica y log (graficos, tartas, pasteles, etc...), la que a mi me va, usas los routers del proveedor, administrable en condiciones de carencias de adminstracion con una explicacion razonable y visualmente le produce al responsable interno, reacio a linux por ignorancia, sensacion de poderio, todas las capacidades estan al alcance. * No sigo por no salirnos de la pregunta. * Al decirte lo de no mezclar el asunto de las rutas y cortafuegos, me referia a que o dejas que suse cargue network y rutas (configuradas por ti) + script de cortafuegos (no SuSEfirewall2) o te ocupas tu en script de cortafuegos de network-rutas y cortafuegos en el propio script (aunque sea con llamadas a varios scripts externos), desgraciadamente las grandes facilidades monowan (scripts de SuSE), dificultan enormemente la integracion multiwan "a la suse". * Tengo algun script que podrias adaptar y he visto algunos por internet, en linuxguruz ha de haber algo, QoS incluido.