Windows Server Networking

Componentes de un servicio

2008-10-12T09:06:10Z

Ya he mencionado en repetidas ocasiones que los Servicios son aplicaciones Win32 que se ejecutan sin necesidad de un inicio de sesión interactivo. Son aplicaciones con código añadido para recibir comandos desde el SCM(Service Control Manager) y devolver el estado de las aplicaciones al propio SCM.

Si la clave de inicio del SCM contiene un tipo de valor de registro de: SERVICE_WIN32_OWN_PROCESS, SERVICE_WIN32_SHARE_PROCESS, o SERVICE_INTERACTIVE_PROCESS, la clave es un servicio y SCM lo arrancará. Si la subclave de una aplicación contiene el valor 16 (SERVICE_WIN32_OWN_PROCESS), 32(SERVICE_WIN32_SHARE_PROCESS), o 256 (SERVICE_INTERACTIVE_PROCESS) en la entrada, la aplicación es un servicio y lo arrancará el SCM.

La entrada tipo del registro para un servicio se ubica en la siguiente subclave:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\nombre_del_servicio (Donde nombre_del_servicio es un servicio).

Nota: Un servicio tipo SERVICE_INTERACTIVE_PROCESS no puede iniciar por sí mismo. Necesita incluirse en una de las constantes de SERVICE_WIN32_*_PROCESS. Un servicio representado por una subclave con el valor 256 (SERVICE_INTERACTIVE_PROCESS) tampoco puede iniciarse por sí mismo.

Entradas del registro de un servicio

Varios parámetros de un servicio están descritos mediante entradas del registro del servicio. El SCM almacena cada característica como una entrada del servicio en la correspondiente subclave. Las subclaves de servicios individuales se ubican en la sublclave: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\.

Tabla de todas las subclaves de las entradas del registro para un servicio y controlador(No todos los servicios tienen todos los tipos de entrada). Si un servició necesita entradas de información de configuración que le son únicas, se crea una subclave denominada 'parameters' en su propia subclave, y en ella se almacenan las entradas referentes a esa información de configuración. Los valores son recuperados por el SCM desde las entradas listadas en cada subclave del servicio.

Servicios del Sistema en Windows Server 2003

2008-10-12T09:05:30Z

Windows Server 2003 en todas sus ediciones, inician algunas aplicaciones durante el arranque del sistema no vinculados a ningún usuario. Estas aplicaciones se denominan Servicios, o servicios Win32 por su relación con las API Win32 para interactuar con el sistema operativo. Similar a los demonios de Unix, los servicios implementan frecuentemente la parte del servidor del modelo de aplicación cliente/servidor. Adquirir conocimiento sobre la funcionalidad, seguimiento, administración y resolución de problemas de los servicios, mejora nuestra habilitad de llevar a cabo procedimientos de diagnóstico para resolver problemas relacionados con los servicios.

Un servicio no es más ni menos que una aplicación basada en sofware que lleva a cabo una función específica del sistema y que frecuentemente proporciona una API para ser llamada por otros procesos. Los servicios son aplicación que se ejecutan en segundo plano en el equipo local. Muchos también proporcionan funcionalidad para otros equipos en la red.

En Windows Server 2003 y anteriores los servicios son llamadas a procedimiento remoto (RPC) hasta el punto de que pueden ser llamados desde equipos remotos de la red. La mayoría de servicios pueden añadirse/quitarse desde la opción Añadir/quitar Componentes de Windows en Añadir o quitar programas del panel de control, y pueden administrarse y configurarse mediante el complemento Services, que se encuentra en Herramientas administrativas o usando el comando Sc.exe.

Modelo aplicación cliente/servidor

Frente al paradigma informático cliente/servidor, uno o más clientes y uno o más servidores, junto al sistema operativo subyacente y la comunicacón interproceso (IPC), forma un modelo que permite la informática distribuida, análisis y presentación.

En este modelo, el cliente es el proceso que interactúa con el usuario y que tiene ciertas características:

Presenta el interfaz de usuario, que normalmente es un interfaz de usuario gráfico (GUI).
Solicitudes al servidor y formularios de consulta o comandos en una estructura predefinida hacia el servidor, basados en entradas del usuario.
Se comunica con el servidor mediante un método IPC como es RPC, y lo usa para la transmisión de solicitudes o comandos hacia el servidor.
Lleva a cabo análisis de datos sobre los resultados envíados por el servidor y muestra los resultados al usuario en un formato de aplicación definido.

El servidor por su parte es un proceso, o un conjunto de procesos, todos los que pueden existir en un equipo único que proporciona un servicio a uno o más clientes. El servidor tiene las siguientes características:

Generalmente trabaja para el cliente. La naturaleza y extensión de sus servicios están determinados por los objetivos empresariales del sistema cliente/servidor.
Responder a consultas o comandos desde los clientes. No inicia ninguna conversación con ningún cliente, aunque puede existir diálogo entre ambos después de un contacto iniciado por el cliente. Un servidor actúa principalmente como repositorio de datos o conocimientos, o como un proveedor de servicios.
Oculta la composición del sistema cliente/servidor para el cliente y el usuario (es transparente). La comunicación entre un cliente y un servidor puede ser totalmene ajeno a la plataforma de hardware/software del servidor y de la tecnología de comunicación empleada. Esencialmente los clientes necesitan conocer sólo el interfaz, no los detalles de implementación del servidor. Esto permite al servidor cambiar o escalar según crece la demanda, sin afectar al cliente.

En el modelo cliente/servidor , un servidor -o demonio- se activa y espera las solicitudes del cliente. Un demonio es un programa que se ejecuta indefinidamente y que tiene el propósito de manejar periódicamente solicitudes al servicio que un equipo espera recibir. El demonio reenvía la solicitud a otros programas (o procesos) correspondientes. Los servicios de W2k3 realizan una labor similar.

Arquitectura

Los principales componentes del núcleo de la arquitectura de servicios son Service Control Manager (SMC), service control programs y service applications.

Service control programs no comunica con los servicios directamente; todas las comunicaciones van a través de SCM. Esta arquitectura es precisamente lo que hace la administración remota transparente al servicio de control de programa y al servicio de aplicaciones.

SCM Es un proceso del sistema especial que ejecuta ruta_del_sistema\System32\Services.exe, que es el responsable del inicio, parada e interactuación con los servicios. Los servicios son aplicaciones Win32 que llaman a funciones Win32 especiales para interactuar con SCM para llevar a cabo acciones como registrar el inicio del sistema correcto, responder a solicitudes del estado, pausar o detener el servicio.

Service control programs Son aplicaciones Win32 estándar que usan las APIs SCM CreateSercice, OpenService, StartService, ControlService, QueryServiceStatus, y DeleteService para comunicarse con, o controlar servicios. Para el uso de estas funciones, un service control program debe primeramente abrir un canal de comunicación hacia SCM. Al mismo tiempo que llama, el servicio de control de programa debe especificar los tipos de acciones que quiere llevar a cabo.Durante su inicio, SCM crea un objeto interno que representa la base de datos SCM y usa funciones de seguridad de Windows para proteger el objeto con un descriptor de seguridad. El descriptor de seguridad especifica las cuentas que pueden abrir el objeto y los permisos de acceso a aquéllas cuentas que pueden usarlo.

SCM almacena el descriptor de seguridad en la subclave del registro del servicio como el valor de seguridad, y lo lee durante el inicio tanto de la configuración de seguridad como en el reinicio del equipo. (En caso de no existencia de una subclave especifica para un servicio SCM usara un descriptor de seguridad predeterminado seguro.)

De la misma forma que un service control program debe especificar los tipos de acceso que quiere a la base de SCM, debe también decir que acceso quiere para un servicio.

El Service control program que nos debe ser más familiar es el comando Sc.exe.

Service applications Un service application contiene la infraestructura necesaria para la comunicación con SCM, que envia comandos al servicio diciéndole que pare, se pause, continue o se apague. Un servicio llama también a funciones especiales que comunican su estado al SCM.

Los Service applications, como Servidores Web, consisten en al menos una aplicación que se ejecuta como un servicio. Un usuario que quiere iniciar, detener o configurar un servicio usa un Service control program. Aunque Windows Server 2003 proporciona programas de control de servicios integrados que proporcionan funcionalidades de inicio, parada, pausa y continuación , algunas service applications incluyen su propio programa de control de servicio que permite a los administradores especificar una configuración particular del servicio que administran.

Ya que la mayoría de servicios no tienen (y no deberían) un interfaz de usuario, se integran como programas de consola. En la figura anterior, los servicios 1, 2 y 3 representan service applications.

Cuando instalamos una aplicación que incluye un servicio, el instalador de la aplicación debe registrar el servicio con el SCM. Normalmente para hacerlo, el instalador llama a la función Win32 CreateService, una función relacionada con los servicios cuya parte de cliente está implementada en Advapi32.dll (que se encuentra dentro de la carpeta System32 de la ruta_del_sistema). Esta librería dinámina implementa la parte cliente de todas las APIs de SCM.

Clientes y servidores RPC Para service applications que usan las APIs como QueryServiceStatus y OpenService, el cliente RPC comunica directamente con SCM ya que éste es el servidor para éstas APIs.

Para las que usan APIs donde el servicio mismo es el servidor RPC, el cliente RPC se comunica con el servidor RPC directamente. De este modo, SCM no interfiere en las llamadas RPC a menos que las implemente.

Script Apagado equipos remotos

2008-10-12T00:06:00Z

'Este script sirve para apagar una lista de equipos remotos
'listados en un archivo de texto en grupos de dos lineas
'primera linea el nombre del equipo
'segunda linea la ip del equipo

'(c) Juansa 9-10-2008


Function fl_responde_al_ping (StrEquipo)

'aquí intentaremos comprobar que el equipo está conectado
'mediante un ping a su IP.

strComputer = "."
Set objWMIService = GetObject("winmgmts:" _
    & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
Set colPingedComputers = objWMIService.ExecQuery _
    ("Select * from Win32_PingStatus Where Address = '" & StrEquipo & "'")

For Each objComputer in colPingedComputers
    If objComputer.StatusCode = 0 Then
        
    fl_responde_al_ping = True
    Else
        
    fl_responde_al_ping = false
   End If
Next

End Function

'cuerpo del script

Const ForReading = 1, ForWriting = 2
Dim TabStop, NewLine
TabStop = Chr(9)
NewLine = Chr(10)


Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objFSO2 = CreateObject("Scripting.FileSystemObject")
Set objFile = objFSO.OpenTextFile("C:\scripts\juansa.txt", ForReading)
Set objFile2 = objFSO2.OpenTextFile("C:\scripts\LogApagados.txt", ForWriting, True)
Do Until objFile.AtEndOfStream
StrEquipo = objFile.ReadLine
StrIP = objFile.ReadLine

If fl_responde_al_ping(StrIP) then
    Wscript.Echo StrEquipo & " responde. Se intentará realizar el apagado."
    objFile2.WriteLine Date & TabStop & StrIP & TabStop & StrEquipo & TabStop & "APAGADO"

    'establecemos control de errores
    On Error Resume Next

     Set objWMIService = GetObject("winmgmts:" _
& "{impersonationLevel=impersonate,(Shutdown)}!\\" & StrEquipo & "\root\cimv2")
    Set colOperatingSystems = objWMIService.ExecQuery _
("Select * from Win32_OperatingSystem")
    For Each objOperatingSystem in colOperatingSystems
        ObjOperatingSystem.Win32Shutdown(1)
    Next
    if Err.Number <> 0 Then

    'mostramos el error o lo guardamos en el log
    WScript.Echo vbCrLf & vbCrLf & _
                     Err.Number & ": " & Err.Description
    objFile2.WriteLine Date & TabStop & StrIP & StrEquipo & TabStop & "Hay un Error!" & Err.Number & ": " & Err.Description

    'vacíamos el objeto Err
    Err.Clear


else
    Wscript.Echo StrEquipo & " NO responde. Se saltará éste equipo del apagado."
    objFile2.WriteLine Date & TabStop & StrIP & TabStop & StrEquipo & TabStop & " NO APAGADO"
end if
Loop
objFile2.Close
objFile.Close
Wscript.Echo "Puedes comprobar el Log en C:\scripts\LogApagados.txt"

----------------

Lo que tienen los archivos:

C:\scripts\juansa.txt

juansa
192.168.0.10
ONO
192.168.0.1
Noexiste
192.168.0.11

C:\scripts\LogApagados

09/10/2008    192.168.0.10    juansa        APAGADO
09/10/2008    192.168.0.1      ONO          APAGADO
09/10/2008    192.168.0.11    Noexiste     NO APAGADO

Este script funciona si el que lo lanza es administrador, de hecho está pensado para lanzarlo un administrador, pero mi amigo Fernando dice que puede usarse http://urpiano.wordpress.com/2007/04/26/vbscript-como-conectar-a-wmi-con-credenciales-alternativas/ para redondearlo.

Por supuesto es mejorable, pero lo publico por sí sirve de ejemplo y ayuda.

Solucionando errores TCP/IP. 9 final.

2008-10-10T11:06:22Z

Puertas de enlace

Si estamos recibiendo el mensaje "La puerta de enlace no pertenece a ninguno de los interfaces configurados..." durante la instalación y configuración del SO, hemos de ver si la puerta de enlace predeterminada está en la misma red lógica que el adaptador de red del equipo. La forma más fácil de hacerlo es comparando el ID de red de la IP de la puerta de enlace con el ID de red de los adaptadores del equipo. En otras palabras, comprobar las operaciones lógicas AND de ambas IP y máscaras y sean correctas.

Proxy ARP

Proxy ARP es el que responde a solicitudes ARP de parte de otro nodo. Como se describe en la RFC 925, se usa en situaciones en que una subred es dividida sin usar un enrutador. Un dispositivo proxy ARP se coloca entre nodos que no están en la misma subred lógica. El proxy ARP responde a solicitudes ARP y facilita el reenvío de paquetes IP unicast para la comunicación entre nodos en segmentos separados.

Ejemplos:

RRAs en equipos con W2k3, que usa proxy ARP para facilitar la comunicación entre clientes remotos y nodos en el segmento de red que está asignado al servidor de acceso remoto.
La característica de puente en XP y W2k3 estándar y la edición de 32 bits de W2k3 Enterprise, que actúan como un dispositivo proxy ARP cuando llevan a cabo la tarea de puente (capa 3) entre segmentos de red.

El tráfico de red falla en algunas ocasiones porque la solicitud de un enrutador a un proxy ARP devuelve una dirección errónea. Un enrutador hace la solicitud ARP de parte de una dirección IP dentro de sus subredes internas. El problema es que la respuesta devuelve una MAC incorrecta para enviar al equipo. Como resultado, el equipo envía su tráfico a una MAC incorrecta. En resumen, tenemos un problema de respuestas desde un proxy ARP.

Para esto necesitamos del Monitor de Red y capturar la traza. Si la misma revela que cuando el equipo envía una solicitud ARP para la MAC del destino y un dispositivo (normalmente un enrutador) la devuelve con una MAC incorrecta, es que la resolución IP-a-MAC no funciona.

Nota: Podemos ejecutar hh NETMNconcepts.chm desde Inicio->ejecutar para obtener información sobre Network Monitor.

Para determinar si este es el problema podemos comprobar la caché ARP del equipo origen para asegurarnos de que esté adquiriendo la dirección resuelta de IP-a-MAC correcta. También podemos capturar todo el tráfico con Network Monitor y luego filtrar el tráfico capturado para mostrar sólo los protocolos ARP y RARP (este convierte MAC-a-IP).

Puede que resolvamos el problema desactivando el prosy ARP en el dispositivo, dependiendo de la marca, modelo y configuración del mismo.

Enrutadores agujeros negros

Algunos enrutadores no envían el mensaje "ICMP Destination Unreacheable-Fragmentación Needed and DF set" cuando no pueden reenviar un datagrama IP. En su lugar, descartan el datagrama en silencio. Normalmente un datagrama IP no puede ser reenvíado si su tamaño máximo de segmento es demasiado grande para el servidor receptor, y está establecida la no fragmentación de bit en la cabecera del propio datagrama. Los enrutadores que ignoran estos datagramas y no envían el mensaje se denominan PMTU Black-Hole Routers.

Para responder eficazmente a estos enrutadores, debemos habilitar la característica de detección de PMTU black-hole de TCP/IP. Esta característica reconoce transmisiones desconocidas y repetidas y responde desactivando la no fragmentación de bit. Después de la transmisión de un datagrama con éxito, se reduce el tamaño máximo de segmento y se activa de nuevo la no fragmentación de bit.

La característica de detección comentada está deshabilitada de forma predeterminada, pero podemos habilitarla añadiendo la entrada EnablePMTUBHDetect con un valor a 1 en el registro. Esta entrada es opcional y no aparece en el registro a menos que la añadamos en la sub-clave pertienente, que es:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Podemos deshabilitarla borrando la entrada o estableciendo su valor a 0.

Una segunda entrada, EnablePMTUDiscovery, ayuda también a descubrir problemas de enrutador agujero negro. Esta clave está habilitada predeterminadamente. Habilita o deshabilita completamente el mecanismo de descubrimiento de PMTU. Si está deshabilitada, se utiliza un tamaño máximo de segmento de TCP (MSS) de 536 bytes en direcciones de destino no locales.

Descubrir PMTU con Ping

La PMTU entre dos equipos puede descubrirse manualmente mediante el comando ping -f:

ping -f -n numerodepings [-l tamaño] IP_destino

Un ejemplo de como el tamaño de los ping puede variarse hasta encontrar la MTU. El parámetro de tamaño del ping especifica exactamente el tamaño de un dato Echo ICMP a enviar, sin incluir las cabeceras IP y ICMP. La cabecera ICMP es 8 bits y la de IP es normalmente de 20 bits. En el caso de ethernet que vemos, la link layer MTU contiene el tamaño máximo de buffer plus 28 de ping, para un total de 1500 bytes del primer ping y 1501 en el segundo.

En el segundo ping, la capa IP devuelve un mensaje de error ICMP que ping interpreta. Si el enrutador es un agujero negro, ping no recibirá respuesta des que su tamaño ha excedido la mayor MTU que el enrutador puede manejar. Ping puede usarse así, para detectar el enrutador.

Servicios

Además de su función de proveedor de comunicaciones básicas de red, TCP/IP es la piedra angular de una serie de servicios de red como: RRAs, Impresión, IPSec y Examinador.

Si deseas más información sobre los protocolos TCP/IP, procesos y detalles de implementación en Windows:

Microsoft Windows Server 2003 Servicios y
Protocolos TCP/IP Referencia Técnica

ISBN: 0-7356-1291-9 (Inglés)
ISBN: 84-481-3809-7 (Español)

Solucionando errores TCP/IP. 8

2008-10-09T14:45:48Z

Enrutamiento IP

Winodws Server 2003 es compatible con enrutamiento IP tanto en equipos con una tarjeta-adaptador de red como con varias y con o sin el servicio de Enrutamiento y Acceso Remoto(RRAs). RRAs incluye el protocolo RIP (Protocolo de información de enrutamiento) y los protocolos de enrutamiento OSPF (Open Shortest Path First). Los enrutadores pueden usar RIP o OSPF para intercambiar información de enrutamiento dinámicamente.

No podemos conectar a un servidor específico

Si no logramos conectar a un servidor específico mediante conexiones NetBIOS, usaremos nbstat -n para determnar el nombre NetBIOS que ha usado el servidor para registrarse en la red.

La salida el comando lista varios nombres que el equipo ha registrado. Uno de ellos debe parecerse al que se muestra en el escritorio del equipo. Sino, intentaremos con uno de los nombres únicos mostrados por Nbstat.

NBstat también muestra en pantalla las entradas cacheadas desde las entradas PRE del archivo Lmhosts o nombres NetBIOS resueltos recientemente. Si el nombre NetBIOS que los equipos están usando para el servidor es el mismo, y los otros equipos están en una subred remota, hay que asegurarse que tienen en su Lmhosts o en servidores WINS el nombre mapeado.

Servidores de múltiples-usos

Servidores con otras tareas pueden proporcionar servicios de enrutamiento, especialmente en LANs. Has de poder acceder al servidor que piensas que puede estar causando el problema, especialmente si es intermitente, para poder verificar que ningún otro servicio o aplicación está interfiriendo en los recursos del servidor, o que alguno no carga archivos grandes al inicio o apagado del servidor. Esto se aplica al equipo cliente también. Un método para verificarlo sería abrir el Administrador de equipos (clic derecho en MI PC, Administrar), extendemos recursos/carpetas compartidas, y seleccionamos la carpeta Sesiones para mostrar quien tiene una sesión actual con el equipo. Desde la consola de administración de equipo, podemos también ver el Visor de sucesos, que puede mostrar quien ha accedido al servidor, como también cualesquiera otros problemas que estén ocurriendo en ciertas horas o con una frecuencia específica. Otro método sería abrir al Administrador de Tareas para comprobar que aplicaciones o procesos se están ejecutando y lo que afectan al uso de la CPU.

Conexión colgada a un equipo remoto

Para determinar porqué una conexión TCP/IP remota no trabaja adecuadamente, podemos usar netstat -a para ver el estado de toda la actividad en los puertos TCP y UDP del equipo local.

Una buena conexión normalmente muestra 0 bytes en las colas de envío y recepción. Si los datos están bloqueados en alguna cola, la conexión probablemente falla. Si no, puede que sea la red o algún retardo de la aplicación.

Examinar la tabla de rutas con Route

Para dos equipos que intercambian datagramas, ambos han de tener una ruta hacia cada uno de ellos o usar una puerta de enlace que conozca una ruta. Normalmente los enrutadores intercambian información entre ellos mediante RIP.

Habilitar Enrutamiento IP

De forma predeterminada el Enrutamiento IP está deshabilitado. Para habilitarlo, debemos permitir el reenvío de paquetes que se reciben. Si no estamos usamos RRAs para habilitarlo, entonces debemos modificar el registro.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

La entrada IPEnableRouter

A la que le cambiaremos el valor a 1 para habilitar el enrutamiento en todas las conexiones de red instaladas y utilizadas por el equipo.

Si Windows Server 2003 como enrutador no tiene una interfaz en una determinada subred, necesita una ruta para llegar a ella. Esto puede manejarse mediante una ruta predeterminada o añadiendo rutas estáticas. Para añadir una ruta estática podemos usar RRAs o con el comando Route Add. Por ejemplo:

Route add 172.16.33.0 mask 255.255.255.0 172.16.0.1 metric 2

Aquí añadimos 172.16.33.0/24 alcanzable usando la puerta de enlace 172,16.0.1 en dos saltos. Si queremos que la ruta sea persistente, esté presente incluso después de reiniciar, añadimos la opción -p al final del comando. Las rutas persistentes se guardan en el registro.

Examinar rutas con Tracert

Tracert usa incrementalmente valores altos en el TTL de la cabecera para determinar la ruta desde un equipo a otro a través de una red. Lo hace enviando mensajes Echo de ICMP y analizando los mensajes ICMP de retorno. Nos permite determinar la ruta de un paquete reenviado desde un enrutador a otro hasta 30 saltos. Si un enrutador ha fallado o el paquete es enrutado en un loop, Tracert nos indicará el problema. Después de hallarlo, su administrador debe restaurarlo a su estado de completa funcionalidad, contactando si es necesario con él si está fuera de nuestra administración.

Solucionando errores TCP/IP. 7

2008-10-08T11:57:33Z

Nombre NetBIOS o de Host inalcanzable

Ya dijimos que W2k3 permite la comunicación en red entre equipos usando tres tipos de destinos:

Dirección IP
Nombre de equipo (Host Name)
Nombre NetBIOS (NetBIOS Name)

Veamos como podemos intentar dar soluciones a problemas en las dos últimas.

El primer paso es ver que aplicaciones están produciendo errores. Normalmente, en estas aplicaciones se incluyen IExplorer, NET USE, TELNET y FTP. Una vez sabemos cuales fallan, el siguiente paso es determinar si el error se debe a un problema de resolución de nombre de equipo o nombre NetBIOS.

La forma más fácil de distinguir los problemas entre ambas resoluciones es comprobar si la aplicación usa NetBIOS o Sockets. Si usa sockets el problema está relacionado con resolución de nombre de equipo. Las aplicaciones NetBIOS son de largo, las más comunes, incluyendo diversos comandos NET, Windows Explorer, y la superconocida Mis Sitios de Red. Las aplicaciones sockets incluyen IExplorer, otros navegadores, TELNET y FTP.

Error 53

El síntoma más común de un problema de NetBIOS es cuando el comando ping devuelve un mensaje de error 53. Este error generalmente es devuelto cuando falla la resolución a un nombre de equipo particular. También puede ocurrir cuando hay un problema estableciendo una sesión NetBIOS. Para distinguir entre estos dos casos:

Desde la línea de comandos, escribimos

net view \\nombre_equipo

*nombre_equipo es un recurso de red que sabemos que está activo.

Si esto funciona, la resolución de nombres no es probablemente el origen del problema. Con un ping al nombre de equipo podemos confirmarlo, ya que algunas veces la resolución de nombres puede funcionar correctamente cuando net use devuelve un error 53 (como cuando un DNS o WINS tiene una entrada errónea). Si el ping muestra que la resolución falla (con un error de host desconocido), comprobaremos el estado de la sesión NetBIOS.

Para comprobarla:

Desde la línea de comandos, escribimos

net view \\dirección_IP

*La dirección IP del mismo recurso que usamos para identificar la causa del error 53.

Si esto también falla, el problema se encuentra en el establecimiento de una sesión.

Si el equipo está en una subred local, confirmad que el nombre se ha escrito correctamente y que el equipo está ejecutando TCP/IP. Si el equipo no está en una subred local, asegúrenomos de que su nombre y su IP están debidamente relacionados en un DNS, o en los archivos HOSTS o LmHOSTS, o en WINS.

Si todos los elementos TCP/IP parecen bien instalados, con ping comprobaremos que en el equipo remoto TCP/IP funciona.

No podemos conectar con sistemas remotos mediante nombre de equipo

Si el problema no es de NetBIOS, es de sockets, el problema está relacionado con alguna entrada del archivo Hosts o un error en DNS. Para comprobar que sólo funciona correctamente con IPs y no con nombres de equipo, remotamente, comprobaremos ambos: Hosts y DNS en cuanto al equipo que nos da problemas.

Comprobar archivos Hosts

Las entradas del archivo Hosts se usan para crear entradas en la caché de resolución de cliente de DNS, que podemos ver con el comando ipconfig /displaydns. Comprobad los contenidos de la caché de resolución de cliente DNS y las entradas del archivo Hosts.

Comprobar configuración DNS

Si usamos DNS, comprobaremos que las direcciones IP de los mismos están perfectamente configuradas en las propiedades de TCP/IP y en el orden correcto.

Panel de control -> doble-clic en Conexiones de red -> Clic derecho en la conexión, clic en propiedades -> Clic en Protocolo TCP/IP y clic en propiedades -> En las propiedades clic en Avanzadas -> Pestaña DNS -> Comprobamos los DNS.

Este procedimiento nos servirá en los equipos que están configurados estáticamente, ya que si son clientes DHCP no tendrán DNS en la lista.

Ping al equipo remoto mediante nombre de equipo y con su dirección IP para ver si la resolución es correcta. Si al nombre falla pero no a la IP, el problema es la resolución. Comprobad los DNS, un ping a sus IP para ver si están en marcha, o abrid una sesión Telnet al puerto 53: si la conexión se establece con éxito el DNS está funcionando. Después de ver que funciona el DNS, con NSlookup podemos enviar solicitudes al DNS y verificar el estado de los registros que estamos comprobando.

Si fallan ambos, el problema debe ser la conectividad de red, sea la conectividad básica o el enrutamiento.

Resolución de nombres mediante servidor DNS

DNS es una base de datos distribuida que relaciona nombres de dominio a datos. Un usuario puede consultar DNS usando nombres conocidos y jerárquicamente, para localizar equipos y otros recursos en una red IP. Esto ha supuesto el reemplazo de lo que una vez realizaba el archivo Hosts. DNS resuelve nombres conocidos a direcciones IP, de una forma transparente y como podemos observar, como ejemplo:

Un cliente contacta con el servidor DNS con una solicitud recursiva para www.juansa.net. El servidor debe devolver una respuesta o un mensaje de error.
El DNS comprueba sus archivos de zona y caché para la respuesta, pero no la encuentra. Entonces contacta con un servidor raíz para realizar una consulta iterativa respecto a la solicitud recibida.
El servidor raíz no conoce la respuesta, y responde con una referencia a un servidor autoritativo del dominio .net.
El servidor DNS contacta con un servidor en el dominio .net con una consulta iterativa respecto a la solicitud original.
El servidor DNS en el dominio .net no conoce la respuesta exacta, así que responde con una referencia a un servidor autoritativo en el dominio juansa.net.
El servidor DNS contacta con el servidor en juansa.net con una consulta iterativa de la solicitud original.
El servidor en juansa.net conoce la respuesta y responde con la IP correspondiente al nombre solicitado.
El servidor DNS responde a la solicitud del cliente con la dirección IP para www.juansa.net.

(Esto no es más que un ejemplo que podría darse en internet, hay más info sobre consultas recursivas e iterativas, podemos encontrarla por ejemplo en nuestro propio w2k3, ejecutando hh DNSconcepts.chm desde ejecutar)

Mensajes de error DNS

Los errores en la resolución de nombres pueden ocurrir si las entradas en un servidor o cliente DNS no están correctamente configuradas, sí el servidor no está activo, o si hay un problema con la conectividad de red. Para determinar la causa de cualquier problema de resolución podemos usar la herramienta Nslookup.

Las solicitudes falladas devolverán una variedad de mensajes, dependiendo de la naturaleza del fallo. Por ejemplo, si usamos el siguiente comando:

nslookup equipo_destino

y el servidor no puede resolver el nombre, se mostrará lo siguiente:

Server: Nombre cualificado completo de dominio
Address: Dirección IP del servidor
*** Nombre completo de dominio cualificado no puede encontrar equipo_destino: dominio no existe

En otros casos, las solicitudes sin respuesta:

nslookup equipo_válido
Servidor: IP Address: w.x.y.z
DNS request timed out.
timeout was 2 seconds.

Si el servidor falla en responder a la solicitud, Nslookup devuelve:

*** Can't find server name for address dirección_ip: No response from server
*** Default servers are not available.

Este mensaje indica que el servidor DNS es inalcanzable, aunque no indica el porqué. El servidor puede estar apagado, el equipo no tener el servicio DNS activo o existir un problema de hardware o enrutamiento.

Resolución de nombre de equipo mediante archivo Hosts

Un equipo que usa el archivo Hosts para llevar a cabo la resolución de nombres sigue unos pasos:

Equipo A introduce un comando usando el nombre de equipo de Equipo B.

Equipo A comprueba el contenido de la caché de resolución DNS, que contiene las entradas del archivo Hosts. Cuando el nombre de equipo de Equipo B se encuentra, se resuelve a una dirección IP. Entonces el paquete es envíado usando los procesos de resolución de dirección y determinación de ruta normales.

Los errores del archivo Hosts pueden causar errores de red, como:

No contenga un nombre de equipo concreto.

El nombre de equipo en el archivo o en el comando está mal escrito.

La dirección IP para el nombre de equipo es inválida o incorrecta.

Hay múltiples entradas para el mismo equipo en distintas líneas. El archivo se usa desde el inicio, así que la primera entrada es la que se propagará a la caché de resolución de cliente DNS.

El archivo Hosts no se actualiza dinámicamente; todas sus entradas son agregadas manualmente, y la IP y el nombre de equipo son siempre separados por uno o más espacios o tabulación. Un ejemplo:

Si estamos teniendo problemas conectando a un equipo remoto mediante su nombre de equipo y usamos el archivo Hosts para la resolución, el problema podría estar en el contenido del archivo. Busquemos el nombre del equipo remoto correctamente escrito en el archivo y por la aplicación que lo usa.

Comprobar el archivo LmHosts

El problema en la resolución de nombres podría estar en nuestro archivo LmHosts, que se comprueba para direcciones para nombres NetBIOS de forma secuencial de arriba a abajo. Si hay más de una dirección listada para el mismo nombre, se devuelve el primer valor encontrado, tanto si es bueno como si no.

El archivo podemos buscarlo en ruta_del_sistema\System32\Drivers\Etc. No existe de forma predeterminada; un ejemplo existe como LmHosts.SAM. Este archivo debe ser renombrado o copiado como LmHosts antes de usarlo.

Aunque el directorio mencionado es el predeterminado, su consulta dependerá del valor en la entrada DataBasePath de la sub-clave del registro HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters.

Esta entrada le dice al equipo local donde debe mirar para el archivo LmHosts.

Tiempo excesivo para conectar usando Lmhosts

Para comprobar la causa de un tiempo excesivo en conectar al añadir una entrada en el archivo, hay que ver el orden de las entradas.

Este problema puede ocurrir cuando un archivo grande tiene la entrada especificada al final del mismo. Para mejorar la resolución de la entrada, marcarla como una entrada precargada mediante el uso de la etiqueta #PRE. Entonces usaremos el comando nbstat -R para actualizar la caché de nombres NetBIOS local inmediatamente.

Alternativamente, podemos emplazarla más alto en el archivo. El archivo se lee desde arriba para la localización de entradas sin la etiqueta #PRE. Por lo tanto, las entradas que sabemos que son utilizadas más frecuentemente deben ir cerca del inicio del archivo y las que llevan la etiqueta al final del mismo archivo.

Comprobar la configuración WINS

Comprobar que la configuración WINS es correcta y en particular que la dirección del servidor WINS es la adecuada.

El procedimiento es el mismo que más arriba hemos utilizado para comprobar la configuración DNS, sólo que esta vez pulsaremos la pestaña WINS y comprobaremos la configuración:

- Añadir la ip del servidor WINS, si no lo está y existe.

- Verificar que Lmhosts lookup esta habilitado.

- También si NetBIOS sobre TCP/IP se asigna desde DHCP si está habilitado o deshabilitado. Sino, habilitar NetBIOS sobre TCP/IP.

Solucionando errores TCP/IP. 6

2008-10-07T11:35:08Z

Usemos Tracert y Pathping

Si la tabla de rutas es correcta, el problema puede halarse en algún enrutador o enlace en cualquier punto a lo largo de la ruta. Podemos rastrear la ruta hacia el destino con Tracert y Pathping para señalar el problema.

A menos que haya una sola ruta hacia el equipo destino, asegurarse de usar estas herramientas para trazar la ruta más de una vez, especialmente si notamos pérdidas intermitentes de paquetes. El datagrama puede enviarse por distintos caminos, y un enrutador defectuoso puede ser el problema.

Cuando no tenemos conectividad con un lugar concreto usaremos Tracert, ya que nos dice en qué lugar se detiene la comunicación. Pathping es más útil cuando sí hay conectividad a un lugar, pero se pierden paquetes o la espera es alta. En estos casos, pathping nos dice exactamente donde se están perdiendo los paquetes.

Comprobar los servicios de servidor en el equipo remoto

Algunas veces un sistema configurado como puerta de enlace remota o enrutador no está funcionando como debería. Para poder confirmar que el equipo remoto está reenviando los paquetes debemos usar alguna herramienta de administración remota (siempre que seamos administradores de dicha máquina) o contactar con el responsable y que lo compruebe.

Hay una serie de bases de datos en InterNIC que nos servirán en algunos casos para saber quien es el responsable. También nos puede servir la herramienta Whois desde : ARIN, AFRINIC, APNIC, LACNIC, RIPE, INTERNIC u otros.

Comprobar IPSec

IPSec puede incrementar la seguridad de una red, pero también cambia la configuración y hace más difícil resolver un problema. En algunos casos, IPSec se ejecuta donde tenemos al equipo problemático y ello puede crearle dificultades para conectar con otro equipo. Para ver si este es el origen del problema, temporalmente deshabilitaremos IPSec con el comando net stop policyagent, comprobando si el servicio o funcionalidad de red se ejecutan con normalidad.

Si el problema desaparece con IPSec detenido, puede que sea por su filtrado de paquetes, entonces es el responsable del problema. Volveremos a iniciar el servicio con net start policyagent y seguiremos el siguiente procedimiento:

netdiag /test:ipsec /debug > archivo.txt

Con lo que veremos los filtros activos.

Para asignar o desasignar una directiva IPSec para directivas Active Directory

Abrimos el complemento de Usuarios y equipos de AD: Inicio, herramientas administrativas, doble clic en el complemento.

En el árbol de la consola, expandimos el controlador de dominio, el dominio, y la OU u OU hija al que queremos aplicar la directiva.

Clic en propiedades y luego en la pestaña directiva de grupo.

Clic en Editar para abrir la directiva, o Nueva para crear una nueva y luego editarla.

En el árbol de la consola de directiva, expandimos la directiva para el equipo, Configuración de equipo, Configuración de Windows, Configuración de seguridad y clic en Directivas de seguridad IP en Active Directory (dominio)

En el panel detalles, clic en la directiva IPSec que queremos asignar o negar, y hacemos una de dos:

Para asignarla, en el menú Acción, clic en asignar.

Para desasignarla, en el menú Acción, clic en desasignar

Para asignar o desasignar una directiva IPSec para directivas de equipo local

Inicio, Ejecutar, escribimos MMC y pulsamos ENTER.

Clic en File, Add/Remove Snap-in, OK.

Clic en Editor de objetos de directivas de grupo, Add.

Finalizar, Cerrar, Aceptar.

En el árbol de la consola de directiva, expandimos la directiva para el equipo, Configuración de equipo, Configuración de Windows, Configuración de seguridad y clic en Directivas de seguridad IP en Equipo Local

En el panel detalles, clic en la directiva IPSec que queremos asignar o negar, y hacemos una de dos:

Para asignarla, en el menú Acción, clic en asignar.

Para desasignarla, en el menú Acción, clic en desasignar

IMPORTANTE: Una directiva IPSec puede permanecer activa incluso después de que la directiva IPSec o el objeto de Directiva de Grupo a la que se asignó ha sido borrada. Por lo tanto, debemos desasignar la directiva IPSec antes de eliminar la directiva o el objeto de directiva de grupo. En evitación de problemas, deasignamos la directiva IPSec en el objeto de Directiva de Grupo. Esperamos 24 horas para asegurarnos que el cambio se ha propagado, y entonces podemos eliminar la directiva o el objeto de directiva de grupo.

Comprobar el filtrado de paquetes

Cualquier error en el filtrado de paquetes en TCP/IP, enrutador, servidor proxy, Enrutamiento y acceso remoto, o a nivel de IPSec pueden provocar errores de resolución o de conectividad. Para averiguar si el origen del problema de red es el filtrado de paquetes, podemos deshabilitarlo.

Panel de control, conexiones de red.

Clic derecho en la conexión, seleccionamos propiedades.

Seleccionamos Protocolo Internet (TCP/IP) y pulsamos en la pestaña propiedades.

Clic en Avanzadas, y clic en la pestaña Opciones.

Bajo Configuración opcional, clic en Filtrado TCP/IP y luego en el botón propiedades.

Desmarcar la casilla de verificación Habilitar filtrado TCP/IP (en todos los adaptadores) y pulsar en Aceptar.

Intentar pings a una dirección mediante su nombre DNS, su nombre NetBIOS o su IP. Si el intento tiene éxito, las opciones del filtrado de paquetes puede estar configurada incorrectamente o ser demasiado restrictivas. Puede que esté permitiendo al equipo actuar como web server pero, en el proceso, estar deshabilitadas herramientas como el ping o administración remota. Restaurar el rango de filtrado permisivo, cambiando los puertos permitidos TCP, UDP e IP.

Si el intento falla, otra tipo de filtrado puede estar interfiriendo en la red.

Solucionando errores TCP/IP. 5

2008-10-06T13:31:01Z

Comprobando la resolución de IP a MAC con ARP

TCP/IP en Windows Server 2003 permite a las aplicaciones comunicarse en red con otros equipos mediante la IP, nombre de host o nombre NetBIOS. Sin embargo, a pesar de utilizarse una convención de nombres, la dirección de próximo salto para el destino debe al final resolverse a una dirección hardware -conocida como media access control, o sea la MAC address- para el acceso compartido a los medios como ethernet o token ring.

ARP permite a un equipo encontrar la dirección MAC del próximo salto de IP en la misma red física. Para un ARP eficiente, cada equipo guarda en su caché la dirección IP-a-MAC para eliminar solicitudes broadcast de ARP repetitivas.

La utilidad ARP permite al usuario ver y modificar las entradas de la tabla ARP en el equipo local. El comando arp es útil para ver la caché ARP y resolver problemas de resolución de direcciones.

Una entrada estática puede añadirse a un archivo ARP con arp -s dirección_IP dirección_MAC. Sin embargo, hay que tener cuidado cuando añadimos entradas estáticas ya que es fácil de equivocarse. (Que se lo digan al envenenamiento de ARP, :-))). Cuando se reinicia un equipo, todas las entradas estáticas son eliminadas.

Detección de direcciones IP duplicadas con ARP

Cuando iniciamos, Windows realiza un ARP de regalo para detectar cualquier duplicación de su propia IP. Consiste en una solicitud ARP para la IP propia del nodo, o sea para sí mismo. Si un equipo envía una solicitud ARP para sí mismo y no hay respuesta, el equipo determina que nadie está usando dicha IP. Aunque esto detecta en la mayoría de casos IPs duplicadas, en muy pocas situaciones dos equipos (sean MS o no MS) pueden estar configurados con la misma IP en la misma red.

La relación entre las direcciones MAC e IP se realiza por el módulo ARP, que utiliza la primera respuesta ARP que recibe. Por lo tanto, la respuesta desde un equipo impostor puede algunas veces enmascarar la respuesta del equipo previsto.

Usaremos arp -a para mostrar por la pantalla la relaciones MAC-IP de la caché de ARP. Si sabemos la MAC de un equipo remoto que deseamos usar, podemos determinar fácilmente si ambas coinciden. Si no lo hacen, usaremos arp -d para eliminar la entrada, realizaremos un ping a la dirección (forzar un ARP), y entonces comprobamos la MAC en la caché de nuevo con arp -a.

Sí ambos equipos están en la misma red, recibiremos eventualmente una respuesta desde el equipo impostor. Si no, podemos tener que capturar el tráfico desde el equipo impostor con Network monitor (descarga) para determinar el propietario o ubicación del sistema.

Detección entradas inválidas en la caché de ARP

La resolución de problemas de la caché de ARP puede ser una de las tareas de mayor dificultad en la administración de redes ya que los problemas asociados con ello son frecuentemente intermitentes. La excepción a esta regla es cuando nos encontramos que el equipo con problemas responde a una solicitud ARP, creando una entrada inválida en la caché de ARP. Los síntomas de las entradas inválidas en la caché de ARP son difíciles de reproducir y se componen de problemas intermitentes que afectan solamente a un grupo pequeño de equipos. El problema subyacente es que dos equipos están usando la misma IP en la red. Vemos los problemas de forma intermitente ya que la mayoría de entradas de la tabla ARP recientes son siempre del primero de los equipos que responda más rápidamente a una solicitud ARP particular.

Ejemplo de salida del comando arp -a:

Ya que las IP asignadas por DHCP no causan los conflictos definidos aquí(Aconsejo DHCP en cuanto el número de equipos sea grande), el principal origen de los mismos suelen ser las direcciones IP estáticas. El mantener una lista de las direcciones IP estáticas (y sus correspondientes MAC) y como se han asignado nos servirán de ayuda para cualquier seguimiento de conflicto y su comparación con los pares de la tabla de ARP.

Si no tenemos un registro de todos los pares IP y MAC de nuestra red, podemos examinar los bytes del vendedor de la MAC en busca de inconsistencias. Los primeros tres bytes de cada MAC identifican al vendedor/fabricante de la tarjeta. Estos tres bytes se llaman OUI y están asignados por la IEEE. Conociendo el equipamiento instalado y comparando lo con los valores devueltos por un arp -a puede permitirnos determinar cuales direcciones estáticas se han introducido erronéamente.

Comprobar las rutas persistentes de la tabla de rutas

Lo siguiente a examinar son las entradas persistentes en las tablas de rutas. Podemos verlas mediante el comando route. Las entradas persistentes se agregan mediante el comando y parámetros route add -p o desde el servicio de enrutamiento y acceso remoto. Las entradas incorrectas pueden cambiarse mediante route change. Con enrutamiento y acceso remoto agregamos una ruta estática:

Abrimos Enrutamiento y acceso remoto
En el árbol de la consola, extendemos enrutamiento IP y clic derecho en rutas estáticas.
Clic Nueva ruta estática.
En el cuadro de diálogo de Ruta estática, introducimos el interfaz, destino, máscara de red. puerta de enlace y métrica. Si fuera una interfaz de llamada por demanda, el campo de puerta de enlace no está disponible.

Solucionando errores TCP/IP. 4

2008-10-05T19:57:38Z

Vaciar la caché ARP

Entradas incorrectas en la caché de ARP pueden impedir la conectividad a equipos locales y remotos (si la entrada correspondiente a la puerta de enlace es incorrecta). Para ver el contenido de la caché podemos usar los comandos:

arp -a o arp -g

Los resultados que se obtienen con estos parámetros del comando pueden enviarse hacia un archivo de texto o doc si tenemos word instalado, con la sintaxis de redirección.

arp -a > ruta_del archivo (la extensión debe ser txt o doc)

Antes de cualquier cambio en la caché es conveniente volcar su contenido a un archivos y mantenerlo para su revisión si fuese necesario.

El vaciado de la caché la realizamos con:

arp -d *

Comprobar la puerta de enlace predeterminada

Hay que comprobar la puerta de enlace predeterminada. La dirección IP de la puerta de enlace debe estar en la misma sub-red de la dirección del equipo local, si no ese el caso, los paquetes no podrán reenviarse a ningún lugar fuera de la sub-red local. Así que comprobemoslo.

Ping a un equipo remoto

Si la puerta de enlace responden correctamente, hagamos un ping a un equipo remoto para asegurarnos de que la comunicación existe y es operativa con normalidad. Si esto falla, con Tracert examinemos la ruta hacia el destino. Para enrutadores IP que sean equipos ejecutando NT, 2000 o Windows Server 2003, podemos ver la tabla de rutas con route print o con enrutamiento y acceso remoto. En caso de otros enrutadores usaremos la herramienta que le corresponda para ver su tabla de enrutamiento.

Un ping nos devuelve cuatro mensajes de error durante la búsqueda del error.

TTL expiración en tránsito El número de saltos requerido para alcanzar el destino excede el TTL establecido por el equipo que envía, para el reenvío de paquetes. El valor predeterminado de TTL en el caso de mensajes Echo de ICMP es 128. Si esto no es suficiente para el número necesario de enlaces hasta el destino, podemos incrementarlo mediante ping -i, hasta un máximo de 255. Si al aumentarlo nos falla para resolver el problema, los paquetes comenzarán a ser reenvíados en un loop de enrutamiento, esto es, una ruta circular entre enrutadores. Usaremos Tracert para localizar el conjunto de enrutadores del loop, que aparece como una serie repetida de direcciones IP iguales en el informe del Tracert. Después, cambiemos de forma correcta las tablas de enrutamiento de los enrutadores del Loop, o avisemos al administrador del enrutador remoto para solucionar el problema.

Equipo destino inalcanzable Esto indica una de dos: O no hay ruta entre el equipo y el destino deseado, o un enrutador remoto informa que no hay ruta al destino. La forma del mensaje puede distinguirlos:

Si el mensaje es simple "Destination Host Unreachable" (equipo destino inalcanzable), no hay ruta desde el equipo local, y los paquetes a ser envíados nunca se pondrán en la red. Usaremos la herramienta route para comprobar la tabla de enrutamiento local para ver si la ruta al destino es equivocada o inexistente.
Si el mensaje es en cambio "Reply From IP Address: Destination Host unreachable" (Respuesta desde dirección_IP: equipo destino inalcanzable), el problema de enrutamiento se encuentra en un enrutador remoto, cuya dirección IP es la indicada en IP Address. Comprobaremos la tabla de rutas del enrutador remoto correspondiente o avisaremos para ello.

Si hacemos un ping a una dirección IP, hagámoslo también al nombre de host y asegúremonos que la IP es la correcta.

Tiempo de espera agotado para esta solicitud Este mensaje indica que no se recibe respuesta dentro del tiempo predeterminado de cuatro segundos. Esto puede deberse a distintas causas; la más común es una congestión de la red, un fallo de ARP en la resolución del próximo salto de dirección MAC, filtrado de paquetes, error de enrutamiento o descarte por silencio. Frecuentemente significa que una ruta de retorno al equipo de envío ha fallado. Esto puede ser porque el equipo destino no conoce la ruta de regreso al de envío, uno de los enrutadores intermedios no tiene una ruta de regreso o incluso que la puerta de enlace del equipo destino no conoce la ruta de regreso. Antes de comprobar als tablas de rutas de los enrutadores, comprobar la tabla de rutas del equipo destino para ver si tiene una ruta para llevar al equipo de envío.

Si las tablas de rutas remotas son correctas y contienen rutas válidas de retorno para el equipo de envío, mirar si la caché ARP carece de la dirección procedente con arp -a. Tambié, comprobar la máscara de subred para estar seguro que la dirección remota no se interpreta como local.

Después usamos TRacert para determinar la ruta al destino. Aunque Tracert no grava la ruta que los mensajes de Echo siguen en su retorno, puede mostrar lo que el paquete hace en el destino. Si es este caso, el problema es probablemente un problema de enrutamiento de la ruta de retorno. Si la traza no consigue llegar al destino, puede deberse a que el equipo está detrás de un cortafuegos. Cuando hay un cortafuegos, el filtrado de paquetes ICMP impide a los ping -y cualesquiera otros mensajes ICMP- traspasarlo y por tanto alcanzar su destino.

Para comprobar la congestión de red, solamente necesitamos incrementar la latencia permitida aumentando el tiempo de espera, unos 5 milisegundos, mediante el comando ping -w. Probar el ping al destino otra vez. Si la solicitud excede el tiempo de respuesta, la congestión no es el problema.

Equipo desconocido Este mensaje de error indica que el nombre de equipo solicitado no puede resolverse a una dirección IP; comprobar si el nombre es correcto y si los DNS pueden resolverlo.

Solucionando errores TCP/IP. 3

2008-10-01T13:38:37Z

Comprobación de la conectividad con Ping y Pathping

Ping nos ayuda a verificar la conectividad a nivel de IP y Pathping detecta paquetes perdidos en intentos de múltiples saltos. El comando ping lanza una serie de mensajes echo de ICMP a un destino: nombre de host o dirección IP. Con ping verificamos que un equipo puede enviar paquetes IP a un destino, así como aislar problemas de hard o configuraciones incorrectas.

Si el comando ipconfig /all nos muestra la dirección IP adecuada no necesitamos hacer un ping a la dirección de loopback (127.0.0.1) o la dirección IP.

Para verificar que una ruta existe entre el equipo y un equipo de la red:

ping dirección_IP

Comprobamos que TCP/IP está instalado y configurado correctamente en el equipo:

ping 127.0.0.1

Comprobamos que el equipo se añadió correctamente a la red (si la tabla de rutas es correcta, esto solamente reenvía el paquete a 127.0.0.1)

ping dirección_IP_equipo_local

Comprobamos que la puerta de enlace predeterminada funciona y podemos comunicarnos con un host dentro de nuestra red:

ping dirección_IP_puerta_de_enlace

Comprobación de la ruta a un host remoto pasando por un enrutador:

ping dirección_IP_host_remoto

Comprobamos la resolución de nombre del host remoto:

ping nombre_equipo_remoto

Comprobamos que los enrutadores de la ruta al destino funcionan correctamente:

pathping dirección_IP_host_remoto

Notas:

Sí la dirección IP local devuelta en cualquier comando es 169.254.y.z, significa que se ha asignado mediante APIPA (Automatic Private IP Adressing), una característica de Windows Server 2003. Lo cual nos indica que no hay servidor DHCP activo o que es inalcanzable por el equipo.
Si la IP es 0.0.0.0, se ha detectado que el adaptador de red no está conectado a una red. Comprobar el cable y que el concentrador/conmutador (hub/switch) funciona. Podría también ser un mal funcionamiento de controladores e incluso de la propia tarjeta de red.

Ping utiliza resolución de host name para resolver el nombre de un euipo a una IP, así que si el ping a la IP se realiza con éxito y al nombre del equipo falla, el problema reside en la resolución de nombres y no en la conectividad de la red.

Si por cualquier motivo no logramos pings con éxito comprobaremos:

Que el equipo dispone de una dirección IP válida y que se muestra correctamente en la pestaña General de las propiedades del protocolo TCP/IP de la conexión de red y también en la pestaña Soporte del Estado de la conexión de red (clic derecho conexión de red, Estado). Por supuesto si usamos ipconfig o netdiag también se nos muestra.
La puerta de enlace está configurada y el enlace entre ambos funciona adecuadamente. Windows Server 2003 dispone de lo que se llama Dead Gateway Detection que en caso de múltiples puertas de enlace configuradas, intentará enviar paquetes mediante la puerta de enlace predeterminada un número de veces sin recibir respuesta, esta característica hará que se cambie la dirección de próximo salto de esa conexión TCP a la siguiente puerta de enlace de la lista.

Solucionando errores TCP/IP. 2

2008-09-29T10:16:21Z

Próximo salto

Todos los equipos que utilizan cualquier versión de Windows y el protocolo TCP/IP usan una Tabla de enrutamiento IP. Esta tabla se usa para determinar el siguiente salto de interfaz y dirección IP. La tabla de enrutamiento almacena la información referente a destinos y como alcanzarlos. Hay una serie de entradas predeterminadas y dependientes de la propia configuración del equipo. Nosotros podemos agregar entradas desde la línea de comandos, o pueden añadirse dinámicamente al interactuar con enrutadores.

Cuando un paquete IP es reenviado, se usa la tabla para determinar:

Salto siguiente a dirección IP. Para una entrega directa (en el que el destino es un nodo adyacente), el siguiente salto IP es la IP destino en el paquete. Para una entrega indirecta (el destino no es adyacente), el siguiente salto IP es la IP de un enrutador.
Salto siguiente a interfaz. Aquí se identifica a qué interfaz, física (tardeta de red) o lógica se usará para el reenvío del paquete.

Antes de la determinación del siguiente salto, se usa ARP. En tecnologías LAN como ethernet y Token Ring, ARP intentará resolver la dirección MAC para el siguiente salto y reenviará el paquete usando la interfaz identificada como salto siguiente.

Contenido de la tabla de enrutamiento

Los campos más típicos de una tabla de enrutamiento en Windows Server 2003:

Destino de red. Una IP o un ID de red.
Máscara de red. La máscara utilizada para coincidencia de una dirección destino y la IP del campo destino de red.
Puerta de enlace(siguiente salto). IP donde se reenviará el paquete.
Interfaz. Interfaz de red a usar para el reenvío del paquete.
Métrica. Indica el costo de la ruta para la elección de la mejor entre múltiples rutas. Su uso más normal es indicar el número de saltos (enlaces o enrutadores a cruzar) en la ruta a su destino.
Rutas persistentes. Si se han configurado rutas agregadas.

Las entradas de la tabla pueden ser:

Rutas de red directas. Rutas para subredes a las que el nodo está directamente unido. Para éstas, el campo de puerta de enlace puede estar en blanco o contener la IP de la interfaz de subred. Si la dirección es local, la entrega requiere un pequeño esfuerzo adicional. ARP resuelve la IP a una dirección MAC de la tarjeta destino. Aquí los problemas suelen estar relacionados con ARP o la máscara de red, usando comandos ARP o Ipconfig podemos solucionarlos.
Rutas de red remotas. Rutas accesibles a través de enrutadores y que no están unidas directamente al nodo. El campo de puerta de enlace es la IP de un enrutador local. Cuando la dirección es remota, se determina que puerta de enlace se usará para alcanzarla. En una red con sólo un enrutador determinarlo es sencillo. Pero, en una red con más de un enrutador, determinar la puerta de enlace a usar puede complicarse.

IP lo soluciona consultando la tabla de enrutamiento. Sirve como un árbol de decisión que ayuda a IP a decidir qué interfaz y puerta de enlace debe utilizarse para el envío del tráfico saliente. La tabla contiene diversas rutas individuales y cada una de ellas consiste en un destino, máscara de red, puerta de enlace y métrica.

La tabla se analiza de lo más específico a lo más general, enviándose el paquete por la primera puerta de enlace que coincida con el destino del paquete. Si hay dos rutas iguales, se elegirá la que tiene la métrica más baja. En caso de estar ocupada, el nodo seleccionará arbitrariamente la entrada a usar.

Rutas de host. Ruta a una IP específica. Estas rutas permiten el enrutado entre IPs. La ID de red es una IP específica y la máscara de red 255.255.255.255.
Ruta predeterminada. Ruta a usar cuando no se encuentran o una red más específica o una ruta de host. De manera predeterminada es 0.0.0.0 y máscara de red 0.0.0.0. La puerta de enlace es la predeterminada en el nodo.

Para la determinación de que entrada a usar, IP realiza una operación lógica AND entre la IP de destino y el campo de máscara de red de cada entrada. El resultado se compara con el campo Destino de red de la entrada coincidente.

La lista de rutas coincidentes se compila. y se selecciona la que tiene mayor número de bits establecido a 1 en la máscara. Esta ruta será la más específica a la IP de destino. Si hay más de una ruta, el enrutador utiliza la de métrica más baja para seleccionar la mejor ruta. Si hay varias con la misma métrica baja, se elige arbitrariamente la entrada a usar.

El resultado del proceso es la selección de una ruta única de la tabla de enrutameinto. Si el proceso falla, hay un error de enrutado. El error se indica como TCP o UDP si el envío es a un host y en el caso de un enrutador 'Destino o host inalcanzable' y el paquete se descarta.

En cuanto se ha determinado la ruta, se procede a identificar la interfaz e IP de próximo salto:

Si la dirección del campo Puerta de enlace está en blanco o tiene una IP asignada a una interfaz en el nodo de reenvío:
- La dirección de próximo salto se establece como destino en el paquete IP.
- La interfaz de próximo salto se establece a la interfaz que está especificada en el campo interfaz.
Si la dirección del campo puerta de enlace no está asignada a una interfaz en el nodo de reenvío:
- la dirección de próximo salto se establece a la IP del campo puerta de enlace para la ruta.
- La interfaz de próximo salto se establece a la interfaz que está especificada en el campo interfaz.

Con los comandos route print o netstat -r obtenemos una salida similar a:

En este ejemplo hallamos:

Primera entrada: Destino y máscara 0.0.0.0/0, es la ruta predeterminada. Cualquier destino al que se le haga la operación AND con esta ruta da como resultado 0.0.0.0. por lo tanto la ruta predeterminada coincide con cualquier destino. Si ésta es la elegida la dirección de próximo salto le corresponde a 192.168.0.1 y la interfaz de próximo salto 192.168.0.225 que es el adaptador de red.
Segunda entrada: 127.0.0.0/8, que es la ruta de red loopback. Todos los paquetes envíados a una dirección 127.x.y.z tienen un próximo salto a 127.0.0.1 y la interfaz es la misma 127.0.0.1.
Tercera entrada: 192.168.0.0/24, es la ruta de red. Si ésta es la elegida la ip de próximo salto y la interfaz son 192.168.0.225.
Cuarta entrada: 192.168.0.255/32, ruta de host a la IP del host, todos los paquetes envíados a dicha IP tienen como próximo salto e interfaz la IP 127.0.0.1.
Quinta entrada: 192.168.0.255/32, ruta de host IP broadcast para la clase C 192.168.0.0/24.
Sexta entrada: 224.0.0.0/3, ruta de tráfico multicast envíada por este host. Todos los paquetes multicast tienen como próximo salto e interfaz la ip 192.168.0.255.
Séptima entrada: 255.255.255.255/32 ruta de host IP limitada de broadcast.

Houston we have a problem!

Introducción

Vamos a intentar explicar unas nociones para identificar los problemas de la comunicación TCP/IP y dar algunos pasos que podemos llevar a cabo para corregirlos.

Generalmente seguiremos un patrón:

Comprobar que la interfaz que está dando problemas no esté desconectada.
Comprobar que la configuración TCP/IP es adecuada y correcta.
Comprobar que existe un camino de enrutamiento entre el equipo y su destino.
Si la confianza con el enlace es dudosa, podemos utilizar el comando pathping en distintas ocasiones del día y registrar el ratio de éxito.

Si estos simples pasos no nos sirven de solución, podemos usar un analizador de protocolo de red, como Microsoft Network Monitor, y capturar el tráfico de red.

Cuando tenemos un problema deberíamos preguntarnos:

¿Otros equipos en la misma red pueden alcanzar el recurso?
¿Qué aplicaciones están fallando, cuáles funcionan y hay relación entre ellas? ¿Algún patrón deducido?
¿Es un problema de conectividad o de resolución de nombres? Y sí es lo segundo ¿Qué resolución usa la aplicación que falla, NetBIOS o Host names?
La aplicación que falla, ¿Había estado funcionando correctamente hasta el error?
¿Hemos hecho cambios en el equipo o en la red entre el funcionamiento correcto y la aparición del error?

Podemos usar la característica de reparación después de haber comprobado que el adaptador no está desconectado, ello hará que se refresque la configuración de red del adaptador. Esta reparación realiza lo siguiente:

	Acción	Similar a:
1	Comprueba si DHCP está habilitado y si lo ésta, emite una renovación broadcast para refrescar la IP.	Ipconfig /renew *
2	Limpia la caché ARP	arp -d
3	Limpia la caché NetBIOS	nbtstat -R
4	Limpia la caché de cliente DNS	ipconfig /flushdns
5	Registra de nuevo con WINS	nbstat -RR
6	Registra de nuevo con DNS	ipconfig /registerdns

* Una renovación de broadcast hace que un equipo acepte cualquier concesión de cualquier servidor DHCP disponible. Por contra, un ipconfig /renew (renovación unicast) renueva sólo la concesión existente del último servidor DHCP desde el que el cliente aceptó la concesión. El primer caso es preferible en las ocasiones en que existe un problema con el servidor DHCP del que se aceptó la concesión.

Si aún así seguimos con el problema, comprobaremos la configuración de la red y del dispositivo de red, desde la configuración de Estado de la conexión de res, o utilizando las herramientas de línea de comando como Netdiag.exe o Ipconfig. Las tres tienen información redundante y diferencias al mismo tiempo entre ellas mismas.

Para comprobar el estado:

Clic derecho sobre la conexión de red y pulsamos en Estado.

Las ventajas en este caso son: monitorizar en tiempo real la actividad de la red y ver fácilmente las propiedades de la conexión pulsando en propiedades, pudiendo cambiar y revisar cliente, servicios o protocolos.

Por contra, no tenemos acceso a una conexión que esté desconectada, los detalles son limitados, sólo una conexión a la vez, datos de ipv4 y no los de ipv6 y no podemos redirigir la info a la impresora.

Si usamos IPconfig /all, obtenemos un informe de configuración detallada para todas las interfaces. La salida puede ser redirigida a un archivo de texto o de word, al estilo,

ipconfig /all > C:\Mis documentos\ipconfig.txt

Con una salida similar a:

Las ventajas de ipconfig son: una información de equipos multi tarjeta en una única operación, podemos redirigir los resultados y obtener copia impresa, muestra tanto ipv4 como ipv6 y además con más información que usando Estado.

La desventaja es que no puede usarse para mostrar información de un equipo remoto.

Y con Netdiag.exe aislamos los problemas de conectividad y de red, realizando tests más extensos que con ipconfig. Estos tests y la información que nos facilitan nos ayudará a identificar y aislar los problemas de red. Y como no requiere parámetros u opciones a especificar sólo hemos de ocuparnos de analizar la salida más que de entrenar a los usuarios a usarla.

Podemos instalarla desde las Support tools.

Para ejecutarla desde la línea de comandos debemos indicar la ruta donde está netdiag.exe, por ejemplo, C:\Tools\Netdiag.exe.

La salida la podemos redirigir a una carpeta y guardarla en un archivo de texto.

La salida nos proporciona una lista detallada de información de configuración y de los tests llevados a cabo.

Las ventajas de netdiag son: información proporcionada de equipos multitarjeta en una operación única, que puede ser redirigida y guardada en un archivo, muestra ipv4 e ipv6 y la variedad de tests hacen que el informe sea de un diagnóstico detallado.

Si siguen los problemas, usaremos los comandos ping y pathping para comprobar la capacidad del equipo para conectarse a otro host mediante TCP/IP.

Dmdiag

2008-09-21T07:30:26Z

Dmdiag (dmdiag.exe) o Disk Manager Diagnostics, es una herramienta de línea de comandos que proporciona información sobre discos y volúmenes dinámicos (MBR y GPT), esta información nos sería útil, en su caso, para facilitarla a la Asistencia técnica de Microsoft o para utilizarla nosotros mismos si sabemos cómo.

Dmdiag es parte de las Windows Support Tools y su sintaxis es bastante común:

dmdiag [-f nombre_archivo] [-v] [/?]

-f nombre_archivo : Especificamos el nombre del archivo donde volcará la información de salida, si no se especifica de forma predeterminada será dmdiag.txt en la misma carpeta/directorio donde ejecutemos la herramienta, y si no usamos el parámetro (-f) la salida será por pantalla.

-v : Activa verbose mode, esto añade información sobre los discos y volúmenes dinámicos, con ello logramos un informe más completo.

-/? : Nos muestra la ayuda sobre la herramienta.

Solucionando errores TCP/IP. 1

2008-09-21T01:30:00Z

Sin entrar en demasiados detalles comentaré que MS re-escribió la pila de TCP/IP en los 90 para mejorar ciertos aspectos de la implementación del protocolo TCP/IP. En cada nueva generación de Windows, la implementación de dicha pila ha continuado evolucionando y incluyendo mejoras y servicios para aumentar el rendimiento la seguridad y la fiabilidad. La pila TCP/IP en Windows Server 2003 se vende como más autoajustable, escalable, fácil de administrar, rápida y más segura. Además de estar asociada a servicios instalados predeterminadamente y que no pueden desinstalarse desde el complemento de conexiones de red.

Como en versiones anteriores de Windows nos encontramos con cierta variedad de herramientas de diagnóstico y reparación incluídas en el propio SO, que en este caso han sido aumentadas.

Introducción al proceso TCP/IP

TCP/IP sigue una secuencia para el establecimiento de una comunicación en una red o entre redes dispersas. Antes del envío del primer paquete que establecerá la sesión de comunicación, el protocolo en el envío al host lleva a cabo cuatro pasos definidos:

Resuelve el nombre del host o nombre NetBIOS a una dirección IP.
Usando la IP destino y la tabla de rutas, determina la interfaz a usar en el siguiente salto de IP.
Para tráfico:
1. Unicast en tecnologías como ethernet, Token Ring y FDDI(Fiber Distributed Data Interface), el protocolo ARP (Address Resolution Protocol) resuelve el siguiente salto de dirección IP hacia una MAC address.
2. Multicast en ethernet y FDDI, la dirección IP multicast de destino es mapeada a la MAC address multicast correspondiente. En Token Ring se usa la dirección funcional 0xC0-00-00-04-00-00. Y en broadcast la MAC address se mapea a 0xFF-FF-FF-FF-FF-FF.
El datagrama IP es envíado a la dirección MAC, resuelta mediante ARP, al mapeo multicast o la dirección de broadcast.

La pila de TCP/IP siempre sigue el proceso descrito para determinar como llevar un paquete de un sitio a otro.

Resolución de un nombre a dirección IP

Si el destino está en formato nombre NetBIOS o nombre de Host es necesaria la resolución antes de que IP pueda enviar el primer paquete. IP sólo reconoce direcciones IP, la resolución de nombres de host o NetBIOS a una dirección IP, son realizadas, para cada uno, de distintas formas.

De nombre NetBIOS a una dirección IP

Estos nombres pueden ser directamente trasladados a una dirección IP mediante cuatro mecanismos: consultando la caché de nombre NetBIOS, consultando a un servidor WINS, por broadcasting o comprobando el archivo LMHOSTS.

Windows Server 2003 siempre comienza con la caché, en caso de fallo usará: un servidor WINS, series de broadcasts o el LMHOSTS. De las tres se usará primero dependerá en cada equipo de su tipo de nodo. De forma predeterminada el tipo de nodo es Híbrido o H-node, que comienza por el servidor WINS y seguirá con las series de broadcasts. Si ninguno de los métodos funciona, el cliente convierte el nombre NetBIOS en nombre de Host y lleva a cabo la resolución de Host-name.

En Windows Server 2003 el tipo de nodo predeterminado es B-node, convirtiéndose en H-node cuando se configuran con un servidor WINS.

Tipos de nodo

B-node (Broadcast)	Utiliza consultas de nombre NetBIOS por broadcast para registro y resolución de nombres. Tiene dos problemas serios: Broadcast molesta a todos los equipos en la red y además los enrutadores no reenvían broadcast, así que sólo funciona en redes locales.
P-node (Peer-peer)	Utiliza un servidor, como WINS. No hay broadcast, la consulta va directamente al WINS.
M-node (Mixed)	Es una combinación de los tipos B-node y P-node. De forma predeterminada actúa como B-node, si es incapaz de resolver el nombre de esta forma, entonces su consulta se realiza en modo P-node.
H-node (Hybrid)	Combinación de P-node y B-node. De forma predeterminada actúa como P-node, si es incapaz de resolver el nombre entonces pasa a modo B-node.

El comando nbstat -a nos servirá para comprobar la resolución de NetBIOS pura.

De nombre host o dominio a dirección IP

Los nombres de host pueden ser directamente resueltos mediante la caché de cliente DNS, la cual contiene sus entradas en el archivo HOSTS, o mediante un servidor DNS. Cualquier problema que aparece aquí suelen estar relacionados con una configuración errónea del servidor DNS, entradas del archivo HOST incorrectas (dirección IP errónea, múltiples IP para un mismo Host)

Los comandos Nslookup y Netdiag nos servirán para el diagnóstico y solución de problemas con la resolución de nombres de dominio o host.

Diskprobe

2008-07-30T11:01:00Z

Diskprobe (Dskprobe.exe) es un editor de sector de Widows Server 2003 que permite a los administradores editar, guardar y copiar datos en un disco duro. Usándolo con precaución, podemos reemplazar el MBR, reparar la información de la Tabla de particiones o sectores de arranque corruptos y otros en volúmenes FAT16, FAT32 y NTFS. También podemos usarlo para realizar una copia de seguridad del MBR o sectores de arranque en archivos binarios por si las moscas. Sin un conocimiento a fondo de la herramienta es mejor usar otras herramientas, como la consola de recuperación, antes de usarla.

Hay que ser precavido si realizamos cambios en la estructura del disco duro. Diskprobe no comprueba los cambios a grabar y valores incorrectos podrían dejar inaccesible el disco o impedir arrancar al sistema. En caso d no poder corregir los cambios efectuados deberemos crear y volver a formatear todos los volúmenes del disco.

Con Diskprobe podemos cambiar los valores de bytes individuales de cualquier sector en un disco dinámico pero no podemos navegar por su estructura. Por tanto se recomienda sólo usar Diskprobe en discos básicos. Sin embargo, podemos usarlo para copiar y restaurar el sector de arranque y el MBR de discos dinámicos.

Diskprobe es parte de las Windows Support Tools.

Podemos usarlo para ver las GUID de: la cabecera de la tabla de particiones y de las entradas de los discos GPT de equipos Itanium.Sin embargo no hay que usarlo para realizar cambios en la estructura de los GPT, estas se auto-reparan a sí mismas y cualquier cambio podría estropear el disco.

El archivo dskprobe.chm incluído nos facilitará la información para su uso y limitaciones.

DiskPart

2008-07-28T17:42:33Z

Diskpart (diskpart.exe) es una herramienta de administración de línea de comandos con una funcionalidad similar al complemento de Administrador de discos. Aunque siempre que sea posible está recomendado usar el complemento gráfico para administrar y solucionar problemas de discos y volúmenes. Sin embargo, diskpart proporciona un método para la resolución de problemas remotamente mediante el uso de Telnet, y para el uso en archivos de lotes que graban el estado del disco o detectan problemas en su configuración.

Algunos ejemplos:

Iniciarlo: Desde inicio, ejecutar, escribir CMD y pulsar enter. Después escribimos DISKPART y enter, entraremos en el prompt DISKPART>

Listar discos: Escribimos en el prompt el comando List disk

Ver los detalles de un disco: Escribimos Select disk número_del_disco y después detail disk

Lista de comandos posibles de DISKPART: Escribimos commands

Artículo de la knowledge base: Descripción de la utilidad Diskpart.exe