Source: https://windowserver.wordpress.com/2017/01/10/resolucin-de-problemas-de-conectividad-no-puedo-conectarme-a-conectividad-ip/
Timestamp: 2017-06-23 18:52:04+00:00

Document:
Resolución de Problemas de Conectividad (No puedo conectarme a …) – Conectividad IP | WindowServer
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:
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”
By Guillermo Delprato, on 10/01/2017 at 06:19, under Conectividad de Red. Etiquetas: conectar redes, Conectividad de Red.	6 comentarios	Post a comment or leave a trackback: Trackback URL.
« Windows Server Core – Cambiar Aspecto de Interfaz
Resolución de Problemas de Conectividad (No puedo conectarme a …) – Resolución de Nombres »
Sergio A. Bustos	On 10/01/2017 at 22:05
Permalink | Responder	Excelente, simplemente excelente!
Guillermo Delprato	On 11/01/2017 at 07:07
Permalink | Responder	¡Gracias Sergio! Igualmente para ti :-)
javierdenicola	On 13/01/2017 at 13:15
Permalink | Responder	Muy bien explicado Guille !!
Guillermo Delprato	On 15/01/2017 at 09:23
Permalink | Responder	Gracias Javier! :-)
By Resolución de Problemas de Conectividad (No puedo conectarme a …) – Resolución de Nombres | WindowServer on 17/01/2017 at 06:06	[…] ya leyó la nota anterior (“Resolución de Problemas de Conectividad (No puedo conectarme a …) – Conectividad IP”), en esta comenzaremos con el segundo posible problema que es el llamado resolución de nombres, […]
By Resolución de Problemas de Conectividad (No puedo conectarme a …) – Cortafuegos y Servicio que Espere Conexión | WindowServer on 24/01/2017 at 06:47	[…] Resolución de Problemas de Conectividad (No puedo conectarme a …) – Conectividad IP […]

References: Resolución 

Resolución 
 Resolución 
 Resolución 
 Resolución 
 resolución 
 Resolución 
 Resolución