9.2.2.4 Testeando Conexiones con ping

Ahora, haz un ping al servidor por su nombre (en vez de por su dirección IP), una vez desde el servidor y otra desde el cliente. Este es el test general de funcionamiento del hardware de red:

server% ping server
PING server.example.com: 56 data bytes 64 bytes from server.example.com (192.168.236.86): 
icmp-seq=0. time=1. ms 64 bytes from server.example.com (192.168.236.86):
icmp-seq=1. time=0. ms 64 bytes from server.example.com (192.168.236.86):
icmp-seq=2. time=1. ms ^C
----server.example.com PING Statistics----
3 packets transmitted, 3 packets received, 0% packet loss round-trip (ms)
min/avg/max = 0/0/1

Sobre Microsoft Windows, un ping del servidor debería aparecer como en la Figura 9.1.

Figure: Ping al Servidor Samba desde un cliente Windows.

Si tiene éxito, este test nos dice cinco cosas:

1. El nombre de máquina o hostname (p.e., "server") ha sido encontrado por tu servidor de nombres local.
2. El nombre de máquina ha sido expandido al nombre completo
   (p.e., server.example.com).
3. Su dirección ha sido retornada (192.168.236.86).
4. El cliente ha enviado al servidor Samba cuatro paquetes de 56 bytes UDP/IP.
5. El servidor Samba ha respondido a los cuatro paquetes.

Si este test no tiene éxito, pueden existir una serie de cosas mal en la red:

• Primero, si obtienes 'ping: no answer' (ping: no hay respuesta) o '100% packet loss' (el 100% de los paquetes perdidos) no estás conectado a la red, la otra máquina no está conectada, o una de las direcciones es incorrecta. Comprueba las direcciones que el comando ping reporta en cada máquina, y asegúrate de que coinciden con los que establecistes inicialmente.
  Si no, hay al menos una dirección equivocada entre las dos máquinas. Intenta introduciendo el comando arp -a, y mira si hay una entrada para la otra máquina. El nombre del comando arp viene de 'Address Resolution Protocol' (Protocolo de Resolución de Direcciones). El comando arp -a lista todas las direcciones conocidas en la máquina local. Aquí tienes algunas cosas para intentar:
  • Si recibes un mensaje del tipo '192.168.236.86 at (incomplete)', la dirección Ethernet de 192.168.236.86 es desconocida. Esto indica un fallo completo de conectividad, y que estás teniendo un problema a bajo nivel de la pila del protocolo de administración de red TCP/IP, en la capa de la interaz Ethernet. Esto se discute en los Capítulos 5 y 6 del libro TCP/IP Network Administration (O'Reilly).
  • Si recibes una respuesta similar a 'server (192.168.236.86) at 8:0:20:12:7c:94', entonces el servidor ha sido rechazado en algún momento, o bien otra máquina está respondiendo en su lugar. Sin embargo, esto significa que el ping debería funcionar: tienes un problema de red intermitente o de ARP.
  • Si la dirección IP desde ARP no coincide con la dirección que esperas, investiga y corrige la dirección manualmente.
  • Si cada máquina puede hacerse un ping la una a la otra, algo está mal en la red que hay entre ellas.
  • Si obtienes un 'ping: network unreachable' (ping: red inalcanzable) o 'ICMP Host Unreachable' (ICMP de máquina inalcanzable), entonces no estás recibiendo respuesta y hay posiblemente más de una red envuelta.

En principio, no deberías intentar buscar problemas en clientes SMB y servidores en diferentes redes. Intenta testear un servidor y cliente en la misma red. Los tres tests que siguen asumen que podrías estar testeando entre dos redes:

• Primero, realiza los tests para ninguna respuesta descritos anteriormente en ésta sección. Si esto no identifica el problema, las posibilidades son las siguientes: una dirección está equivocada, tu máscara de red está mal, una de las redes está caída, o simplemente estás siendo parado por un cortafuegos.
• Comprueba tanto las direcciones y máscaras de red en las máquinas origen y destino para ver si algo está obviamente mal. Asumiendo que ambas máquinas están realmente sobre la misma red, ambas deberían tener las mismas máscaras de red, y un ping debería reportar las direcciones correctas. Si las direcciones están mal, necesitarás corregirlas. Si están bien, los programas pueden estar confundidos por una máscara de red incorrecta. Mira la sección 9.2.9.1, 'Máscaras de Red', más adelante en este capítulo.
• Si los comandos todavía están reportando que la red es inalcanzable y ninguna de las dos condiciones anteriores tenían el error, una red puede ser realmente inalcanzable desde la otra. Esto, también, es una tarea del administrador de la red.
• Si obtienes un 'ICMP Administratively Prohibited' (ICMP Administrativo Prohibido), has chocado con un cortafuegos o un router mal configurado. Necesitarás hablar con el administrador de tu red.
• Si obtienes 'ICMP Host redirect' (ICMP de máquina redirigido), y el ping reporta paquetes saliendo, esto es generalmente inofensivo: simplemente estás siendo re-enrutado por la red.
• Si obtienes un redireccionamiento de máquina y un ping no responde, estás siendo redirigido, pero nadie está respondiendo. Trata esto como una respuesta del tipo 'Network unreachable' (Red Inaccesible), y comprueba tus direcciones y máscaras de red.
• Si obtienes un 'ICMP Host Unreachable from gateway gateway_name' (ICMP de máquina inaccesible desde la puerta de enlace nombre_de_puerta_de_enlace), los apquetes del ping están siendo enrutados a otra red, pero la otra máquina no está respondiendo y el router está reportando el problema. De nuevo, trata esto como una respuesta 'Network unreachable' (Red Inaccesible) y empieza por comprobar direcciones y máscaras de red.
• Si obtienes un 'ping: unknown host hostname' (ping: máquina nombre_máquina desconocida), el nombre de tu máquina es desconocido. Esto suele indicar un problema de servicio de nombres, el cual no afecta al nombre local o localhost. Echa un vistazo a la sección 9.2.8, más adelante en éste capítulo.
• Si obtienes un éxito parcial, con algunos pings fallando pero otros respondiendo, o bien tienes un problema intermitente entre las máquinas, o bien tienes una red sobrecargada. Haz más pings, y mira si más de un 3 por ciento de los paquetes falla. Si es así, compruébalo con el administrador de tu red: puede que un problema esté empezando a nacer. Sin embargo, si sólo fallan unos pocos, o si sabes que otros programas de red masivos están funcionando en ese momento, no te preocupes demasiado. Los ICMP de los ping (y UDP) están diseñados para eliminar paquetes ocasionales.
• Si obtienes una respuesta del tipo 'smtsvr.antares.net is alive' (smtsvr.antares.net está vivo) cuando hace un ping a client.example.com, o bien lo está usando alguien más, o bien la máquina tiene múltiples nombres y direcciones. Si la dirección está equivocada, el servicio de nombres es claramente el culpable; necesitarás cambiar la dirección en la base de datos del servicio de nombres para referirte e al máquina correcta. Esto se discute en la sección 9.2.8, más adelante en este capítulo.
  Las máquinas servidoras son frecuentemente multi-nombres: connectadas a más de una red, con diferentes nombres en cada red. Si estás obteniendo respuesta desde un nombre inesperado en un servidor multi-nombre, mira la dirección a ver si está o no en tu red (mira la sección 9.2.9.1, más adelante en este capítulo). Si es así, deberías usar esa dirección, en vez de una en una red diferente, por razones de rendimiento y seguridad.
  Los servidores pueden tener también múltiples nombres para una misma dirección Ethernet, especialmente si son servidores web. Probablemente querrás usar el nombre oficial (y permanente), en vez de un alias, que puede cambiar.
• Si todo funciona, pero la dirección IP reportada es 127.0.0.1, tienes un error de servicio de nombres. Esto normalmente ocurre cuando un programa de instalación de sistema operativo genera en /etc/hosts una línea similar a 127.0.0.1 localhost nombremáquinaydominio. La línea localhost debería decir 127.0.0.1 localhost o 127.0.0.1 localhost loghost. Corrígela, puede causar fallos a la hora de negociar quién es el mantenedor de la lista maestra de navegación y quién es el navegador maestro. También puede causar errores (ambiguos) en posteriores tests.

Si esto funciona desde el servidor, repítelo desde el cliente.