Cómo solucionar problemas de una PC que tiene problemas de red al acceder al servidor web remoto

Para acceder a un servidor web remoto, necesita una ruta, un DNS que funcione y ningún firewall que bloquee su acceso. Puede depurar los bits por separado. En primer lugar, ¿tiene una interfaz de red que funcione (ifconfig), como eth0 o wlan0? ¿Está arriba y tiene una dirección razonable? ¿Tienes una ruta (ruta -n)? ¿Se puede hacer ping al enrutador predeterminado (la puerta de enlace para el destino 0.0.0.0)? ¿Tiene DNS en funcionamiento en /etc/resolv.conf (puede hacer ping a ellos, ¿resuelven direcciones, por ejemplo, “host quora [.] Com 192.168.3.4”)? Si algo de eso falla, ¿tiene un cliente DHCP ejecutándose (ps ax | grep dhcp)? ¿Recibió un contrato de arrendamiento (grep dhcp / var / log / messages)? Si todo es normal, ¿puedes acceder a otros sitios en Internet? ¿Puedes resolver la dirección del servidor web? ¿Puedes hacer ping (la mayoría de los servidores tienen ping)? ¿Funciona desde otras computadoras? Puede ejecutar traceroute y encontrar problemas, a veces, pero generalmente son problemas de otra persona y se solucionarán con bastante rapidez. Por ejemplo, si puede acceder a un sitio desde su teléfono a través de 3G pero no desde su casa a través del cable, tal vez su ISP tenga una falla de hardware o un problema de ruta.

Un problema ligeramente esotérico es que si el sitio web tiene una dirección IPv6 (un registro AAAA en DNS), e IPv6 está habilitado en su sistema Linux (por lo general, tiene prioridad sobre IPv4), e IPv6 funciona localmente pero no funciona red y el sitio web, entonces puede fallar. Sin embargo, creo que los navegadores recientes compensarán eso.

Comienzo con “ping 8.8.8.8” para ver si la computadora puede llegar al mundo exterior sin un DNS, si le da resultados su conexión a internet funciona, no tiene conexión a internet si “ping 8.8.8.8” no funciona trabajo.

Entonces, el ping 8.8.8.8 funciona, el siguiente paso, “ping google.se” también verifique si su computadora puede resolver el dominio a una dirección IP, si eso funciona, entonces está listo para comenzar. Si no funciona, verifique la configuración de su dns.

la IP 8.8.8.8 es una de las DNS públicas de Google, 8.8.4.4 es otra. IP fáciles de recordar.

Si ninguno de estos funciona, verifique su conexión a Internet, conecte la WAN del ISP a una PC directamente (probablemente se necesitaría un convertidor de fibra si se usa fibra) y pruebe lo mismo o simplemente vea si obtiene una dirección IP de su ISP.

Lo que necesitamos ahora es más información sobre exactamente cómo su PC con Linux tiene problemas para conectarse al servidor remoto.

Estás diciendo que es un problema de red, pero ¿cómo has llegado a esa conclusión? ¿Tiene información comparable sobre otros servidores, mensajes de error, qué? ¿La conexión simplemente falla? ¿Tienes problemas de velocidad?

El consejo dado por Andrew Daviel y Rodney Howard aquí es bueno, pero podría no responder a su pregunta, porque la pregunta no está tan bien definida.

Recomiendo una herramienta que conocí hace unos 2 años llamada mtr o WINMTR. Ejecuta múltiples rutas de rastreo de un sistema a otro y puede ayudarlo a diagnosticar rápidamente dónde está el problema entre los sistemas. MTR es parte de la mayoría de las distribuciones de Linux y se puede instalar con:

apt-get install mtr

yum install mtr

dnf install mtr

Y la versión de Windows que es WINMTR se puede descargar desde sourcefourge o en WinMTR – Herramienta de diagnóstico de red gratuita

Normalmente, para un vistazo rápido, ejecuto 10 bucles a través de mtr y lo solicito en formato de informe para tener una idea de dónde están los problemas o la ralentización entre los servidores.

mtr -c 10 -r

Lo que te da algo como esto:

Me muestra todos los enrutadores entre los dos sistemas y los tiempos de respuesta para los paquetes a los enrutadores y puedo ver que hay una ligera desaceleración en el 12º enrutador, pero que el 90% de los paquetes (pérdida del 10%) llegaron al sistema final . En este caso, normalmente volvería a ejecutar la herramienta durante 100 iteraciones y comprobaría si el servidor remoto tiene una carga alta para averiguar por qué no respondió el 100% del tiempo. Los lugares donde hubo una pérdida del 100% pero el siguiente enrutador se recuperó correctamente, normalmente solo implica que el enrutador no está configurado para responder o estaba ocupado, pero pasó todos los paquetes.