On Tue, Mar 27, 2001 at 07:57:40PM +0200, Francisco Callejo wrote: > El nsswitch.conf es correcto, con esa línea incluida; el host.conf > incluye también "order hosts, bind", y en /etc/hosts están los nombres > de los dos ordenadores de la red. A pesar de todo, sigue dando > problemas a la hora de pedir un servicio de un ordenador al otro. > Resumo la situación: > > - Ordenador A: conectado a la línea RDSI, y con ipchains activado en > un kernel 2.4.1. (con el módulo ipchains.o, no con iptables). > - Ordenador B: conectado por tarjeta de red al ordenador A. > - El ordenador A puede hacer peticiones al B tanto por nombre como por > dirección IP (192.168.1.1). > - El ordenador B puede hacer peticiones al A que no sean tcp (ping, > traceroute) por nombre y por ip (192.168.1.2). > - El ordenador B tiene en su tabla de rutas al A como gateway. > - Si A está conectado a Internet, B puede hacer peticiones a A de > servicios tcp por su nombre. > - Si A _no_ está conectado a Internet, B sólo puede hacer peticiones > tcp a A por ip. (También por nombre, pero tarda muchísimo en > responder). > > Esta situación me ocurre desde hace unos días (anteriormente todo iba > bien) y supongo que tendrá relación con algún .deb que haya instalado > últimamente, pero no sé cuál. Los ficheros de configuración no los he > tocado desde hace tiempo. > > Si a alguien se le ocurre algo, que me lo diga. >
Desde ya, para evitar falsas esperanzas, NO tengo la solución, pero... Te cuento. Mi situación es practicamente idéntica a la tuya (conexión RDSI, ordenador con linux haciendo de router y red interna 10/100, en mi caso con 6 máquinas) y exactamente el mismo problema con la resolución de nombres. Primera consideración: el problema no está relacionado con /etc/hosts, ni con /etc/nsswitch.conf, ni con la versión del núcleo. Tu ejecutas kernels 2.4.x, yo tengo todas las máquinas con kerlnels 2.2.14 y 2.2.18 (bueno, menos una que tiene un minix, pero para el caso no cuenta) Yo detecté el problema al instalar la ver. 0.17.x de los paquetes telnet y telnetd en la máquina en la que trabajo habitualmente. En esta primera actualización, si el router no estaba operativo, telnet no conectaba ni proporcionando un nombre canónico ni proporcionando una dirección ip y telnetd no admitía una conexión al no poder realizar una resolución inversa de la dirección ip del cliente. Si el router estaba operativo, el cliente solicitaba la resolución del nombre a los nameservers de mi ISP y al obtener contestación negativa de estos por fin se dignaba mirar en /etc/nsswitch.conf. El servidor (telnetd) realizaba su resolución inversa por el mismo procedimiento. En una versión de telnet que bajé unos días después este había modificado su comportamiento y permitía la conexión sin intentar resolución de nombres cuando le proporcionaba directamente una dirección ip. El comportamiento del telnetd seguía siendo el mismo. Cansado de esto, decidí downgradear a la ver. 0.16.x de estos paquetes y todo volvió a funcionar normalmente. Investigando algo el tema en los archivos de listas de correo de debian, en el bug tracking y en las news, lo único que pude obtener es un aviso de un problema de seguridad referido al paquete libc6 que literalmente dice "If a stuid program does not drop privileges before calling resolver functions, arbitrary file on the system can be read by setting the RESOLV_HOST_CONF environment variables", que es contestato por el mantenedor del paquete informando que soluciona el problema (no se si provisionalmente) haciendo que las funciones de la librería para resolución de nombres "try absolute lookups first". No se si esto tiene que ver con el problema que tenemos, pero si fuera así debería afectar a todos los programas que utilicen las funciones de resolución de la libc6 2.2 posteriores a este "arreglo" (01-2001). Saludos. rlp
