*This message was transferred with a trial version of CommuniGate(tm) Pro* -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El Viernes, 17 de Septiembre de 2004 18:55, sistemas escribió:
{..................} Das informacion embrollada y nada relevante.
* Si tienes un servidor dns cache, el orden de resolucion correcto ha de ser dns, files , tanto en nsswitch.conf, quitando ademas nis, etc..., para evitar busquedas en servicios no existentes, asi como en resolv.conf la ip del servidor dns cache, dejar los forwaders para aquello que la cache local, no pueda resolver, pero deshabilita forwaders only, o el servidor dns cache no te sirve practicamente de nada recurrira siempre a los del isp, su principal funcion es ahorrar peticiones a los forwaders (utilizar la cache local para reducir el tiempo de resolucion lo que aumentara el rendimiento de tu conexion), asi como ahorrarte el tener que declarar las maquinas internas en todos los /etc/hosts incluidos los wilson, si quieres acceder por FQDN en vez de por ip numerica a los hosts internos. * Si tienes un servidor dns local named, deshabilita el servicio nscd , /etc/init.d/nscd stop (para pararlo) insserv -r nscd (para quitarlo del arranque) insserv named (para que bind se ejecute en el arranque) * Squid debe poder acceder al servidor dns, lo probable es que esten en la misma maquina, por defecto lee /etc/resolv.conf si no se le ha ordenado otra cosa en la directiva dnsservers . * Pero no alcanzo a "adivinar" la configuracion de la red y la gestion del dominio, ni la ubicacion del servidor web, si tienes un dominio valido en internet, es de suponer que lo estes utilizando, por tanto con lo apuntado del servidor dns cache, parece ser que los servidores dns autoritativos del dominio sean los de tu proveedor, con una redireccion a tu servidor web posiblemente situado en tu gateway, si este es el escenario, redireccion de tu proveedor a tu servidor web ubicado en el gateway (firewall, squid, etc) , el servidor es inalcanzable desde la red interna ya que no puede acceder a la ip externa del gateway, que es la direccion que le sirve el dns autoritativo (el de tu proveedor), en esta situacion o haces las modificaciones pertinentes en el orden de resolucion comentado en el primer punto y que las zonas del dns cache apunten a la ip interna del gateway (firewall y servidor web), o en su defecto sin cambiar el orden de resolucion que ahora tienes files, dns , quitar el dns cache (ahora no esta sirviendo de nada) y declarar en /etc/hosts de la maquinas , algo como 192.x.y.z www.dominio.com www ^^^^^^^^ <----- ip de la tarjeta de red interna del gateway, menos problemas tendras tambien si la anterior declaracion la haces sobre una eth0:1 asignandole una ip de la misma red. * A ver esto es bastante chapuza, lo correcto es que si tienes dominio y conexiones permanentes, tus maquinas e ip's alberguen el servidor primario y secundario o al menos alguno de los dos, mejor el primario por facilidad de manipulacion obvia, en este caso para resolver el acceso, sin chapuzas o apaños a www.dominio.com desde la red interna el servidor dns has de configurarlo con vistas, una para el exterior (lo que vera el resto del mundo) y otra interna lo que vera la red interna, de tal manera que cuando una peticion llegue del exterior se le indique la ip visible en internet y cuando la peticion llegue de la LAN, se le sirve la IP interna. * Por deduccion, aplica el cuento a tu configuracion real de red. * No me escribas a mi y a la lista que me llegan duplicados. * Procura recortar el texto citado a lo relevante. * Intenta concretar dando datos de la topologia de red y su configuracion. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFBTPj4AXFL65CppEIRAvcXAJ9NN33J8GRPt5qNW2LSPGtKDXmTyACePZqh zxZNelopePGbKVL4HQUleCs= =SFcc -----END PGP SIGNATURE-----