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.