Resolución de Problemas de Conectividad (No puedo conectarme a …) – Conectividad IP

Creo que uno de los problemas más veces preguntado es “¿Por qué no puedo conectarme a una máquina o servicio? Es una de las preguntas que se repite constantemente en los foros de soporte, o inclusive puedo verlo a veces en las palabras de búsqueda que llegan a este blog

E inclusive muchas veces la pregunta está formulada como “No puedo ver a …” determinada máquina. Esto es totalmente diferente a tener conectividad o no. Cuando alguna pregunta comienza así generalmente es porque la está buscando por el entorno de red, y esto no tiene relación con poder conectarse o no. El entorno de red está creado por servicios que son totalmente independientes de los protocolos que permiten conectividad. “Verla” no siempre permite conectarse, y “Conectarse” no implica siempre poder verla :)

Así que voy a hacer dos o tres notas, sobre este tema, que en realidad involucra tres temas diferentes:

  1. Conectividad IP
  2. Resolución de nombres de máquina
  3. Cortafuegos y existencia de servicio que espere conexión

En esta primera nota comenzaré con el tema conectividad IP

La causa origen de “casi todos los males” suele ser desconocimiento sobre cómo trabaja IP, parte del protocolo TCP/IP, para enviar tráfico de red entre dos equipos, y si no hay conectividad IP, los otros dos temas carecen de sentido ya que por más que se resuelva el nombre de destino a una dirección IP correcta no hay posibilidad de conexión

Y no, no voy a hacer un curso de direccionamiento IP, o cómo trabaja IP, sería demasiado largo y tedioso. El que lo necesite tiene muchísima información en la web, y hay libros enteros dedicados al tema

Este caso se identifica rápidamente; cuando alguien hace la pregunta, pone alguna dirección IP, pero no agrega la Máscara de Subred (“Subnet Mask”) ya da para pensar que no conoce el tema, porque una dirección IP sin indicar la máscara casi diría que carece de sentido. A veces se puede intuir, pero es un dato fundamental a suministrar cuando se hace una pregunta

En básico ejemplo: “No puedo acceder desde 10.0.0.1 a 10.0.1.2 ¿por qué?” porque si ambas máscaras son 255.255.255.0 están en redes diferentes, pero si en cambio son 255.0.0.0 o 255.255.0.0 entonces sí están en la misma red

Resumiendo, dos valores fundamentales:

  • Dirección IP
  • Máscara de Subred (“Subnet Mask”)

Y si dos equipos están en redes diferentes entonces no hay otra forma de interconectarlos si, por lo menos, no hay un Router que interconecte ambas redes. Esa es justamente la función de un Router (Enrutador) pasar tráfico de una red a otra

Dentro de los Routers en la realidad se involucran dos tipos diferentes de funcionalidad: el “Router puro” que sólo enruta sin cambiar direcciones IP de origen y destino, y el NAT (“Network Address Translation”) que enruta pero cambiando la dirección IP de origen, y que además salvo configuración específica es unidireccional

Además de dirección IP y Máscara de Subred, es importante conocer otros dos parámetros adicionales, si la conectividad es entre equipos y redes diferentes

  • Puerta de Enlace (“Default Gateway”)
    Que indica a qué Router se enviará la información cuando la conexión sea a un equipo en otra red diferente
  • Tabla de Enrutamiento (“Routing Table”)
    Sí, todas los equipos que trabajan con IP tienen una Tabla de Enrutamiento, sean o no Routers. Esta indica a qué Router debe enviar la información cuando el destino esté en una red diferente, y por supuesto si existe más de una “salida” de la red local

Para conocer toda la información anterior, más que la interfaz gráfica, es muy útil el comando IPCONFIG

  • IPCONFIG — sólo información básica
  • IPCONFIG /ALL — Información completa

Aunque con el segundo ya podemos ver la Puerta de Enlace, si deseamos ver la Tabla de Enrutamiento completa, incluyendo la Puerta de Enlace entonces necesitamos otro comando:

  • ROUTE PRINT — tabla de enrutamiento de IPv4 e IPv6
  • ROUTE PRINT -4 — tabla de enrutamiento sólo de IPv4
  • ROUTE PRINT -6 — tabla de enrutamiento sólo de IPv6

Para todo aquel que sea “inquieto” y quiera conocer más sobre cada comando simplemente ingréselo seguido de “/?” y podrá ver todos los modificadores y posibilidades de cada uno

Hay otro comando que sirve para verificar conectividad entre dos equipos, que es el conocido PING, pero la mayoría de los que preguntan dicen algo así como “PING no responde” y eso no ayuda, es importante para hacer un diagnóstico saber exactamente cuál es el mensaje de error que informa, pues esto ya da una idea del posible problema. Algo muy importante a tener en cuenta es si el equipo destino o los dispositivos que pueden estar intermedios filtran o no el protocolo ICMP, ya que PING utiliza este protocolo y tiene que estar permitido

Algunos ejemplos, no es lo mismo cuando la propia máquina no sabe cómo llegar a destino, que cuando el que no sabe es el Router, o cuando la máquina supone que sabe cómo llegar pero no obtiene respuesta. Inclusive hay errores mucho menos frecuentes pero que he visto que indican que el TTL expiró en tránsito (“TTL expired in transit”) que indican un problema entre Routers

Si la falta de conectividad es entre equipos locales, entonces toca revisar la configuración de dirección IP y máscara de subred de ambos equipos, pero no olvidarse nunca de los cortafuegos incluidos en los sistemas

Si la falta de conectividad es entre equipos remotos, entoces el tema es mucho más complejo, porque pueden estar involucrados en el problema uno o más de los Routers que existan entre ambas redes origen y destino

Los comandos que podemos utilizar para ver si podemos y está a nuestro alcance solucionar el problema son:

  • Tanto en equipos origen y destino, como si podemos en los Routers intermedios el comando ROUTE PRINT es fundamental, ya que podemos verificar por qué interfaz y hacia cual enviará el pedido de información. Vale también para saber si el equipo destino puede responder, porque a veces el problema no está en el origen, sino en el equipo destino
  • Otro comando que podemos utilizar es TRACERT. Este nos permite conocer qué ruta hacia el destino toma el pedido del PING, identificar los Routers que están de por medio, aunque en muchos casos los routers están configurados por seguridad para no responder al protocolo ICMP aunque lo dejen pasar. Con esto ya tenemos una buena orientación para saber de dónde puede venir el problema. El uso rápido es “TRACERT <IPDestino> y da resultados correctos simper y cuando no exista balanco dinámico en el trayecto
  • Y similar al anterior pero que nos permite identificar si hay altas latencias de por medio es el comando PATHPING que es similar al TRACERT pero da estadísticas durante un lapso de tiempo

 

Resumiendo, si va a pedir ayuda, siempre incluya la siguiente información:

  • Dirección IP y Máscara de Subred del equipo origen
  • Si el equipo destino está en otra red, incluya la direción de la Puerta de Enlace, y si el equipo le pertence o no. Puede ser útil lo que muestra un “ROUTE PRINT”
  • Indique, si conoce, la dirección IP del equipo destino
  • Revise tanto en el origen como en el destino que los cortafuegos permitan el protocolo ICMP

Continuamos con el tema en la siguiente nota: “Resolución de Problemas de Conectividad (No puedo conectarme a …) – Resolución de Nombres”

Anuncios
Post a comment or leave a trackback: Trackback URL.

Comentarios

Trackbacks

Este espacio es para comentarios sobre la nota. No es un sitio de soporte

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: