Para empezar el blog, voy a poner una serie de entradas de blog de Juansa (http://geeks.ms/blogs/juansa/default.aspx), a modo de copia de seguridad porque es muy interesante:
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.
Posted por
Juansa con
sin comentarios Archivado en: Redes (Networking),Windows Server,Herramientas
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.
Posted por
Juansa con
sin comentarios Archivado en: Redes (Networking),Windows Server,Herramientas
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.
Posted por
Juansa con
sin comentarios Archivado en: Redes (Networking),Windows Server,Herramientas
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.
Posted por
Juansa con
sin comentarios Archivado en: Redes (Networking),Windows Server,Herramientas
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.
Posted por
Juansa con
sin comentarios Archivado en: Redes (Networking),Herramientas
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:
- 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.
- 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.
Posted por
Juansa con
2 comentario(s) Archivado en: Redes (Networking)
