Localhost (Raspberry Pi) se niega a conectarse a una de las dos PC en LAN (WiFi)

Estoy en mi segundo intento de configurar un servidor web LAMP ( https://projects.raspberrypi.org/en/projects/lamp-web-server-with-wordpress/3 ) en mi LAN. El primer intento fue exitoso hasta que de repente me di cuenta de que el servidor rechazó la conexión a mi computadora portátil (Windows 10), ya que se había conectado con éxito anteriormente. Finalmente, desesperado, borró a Pi y comenzó de nuevo, probando cuidadosamente paso a paso. Entonces, después de haber conectado Pi a WiFi (ping desde la computadora portátil, OK), el primer paso es instalar Apache2. Todo bien, y la página Apache2 Debian Default aparece en el navegador de Pi en respuesta a http://192.168.1.22 (dirección IP de Pi). Como se esperaba.

En esta etapa, mi computadora portátil (llámela laptop1) no tiene conexión en esa dirección IP. Pero comprobando en una segunda PC (laptop2 con XP), nos conectamos a la página de Apache2 Debian Default como se esperaba. Laptop1, laptop2 y Pi están, por supuesto, todas en el mismo WiFi.

No he realizado otros cambios en Pi ni en ninguna computadora portátil.

Concluyo: la instalación de Apache está bien. La dificultad radica en la computadora portátil1.

¿Alguien puede sugerirme cómo puedo rastrear esto en la computadora portátil1? ¿Dónde debería comenzar a buscar? ¿Es una configuración que he cambiado inadvertidamente? ¿Podría un dll haberse corrompido?

Agregado más tarde: el registro de acceso de Apache muestra dos códigos de error asociados con laptop1. estos son 404 (no se encuentra) y 408 (Tiempo de espera, se leyó mal anteriormente 407 Se requiere identificación de proxy). Entonces, ¿por qué laptop1 no se encuentra?

Gracias John

networking windows-10 apache-http-server

— usuario30578
fuente

¿Puedes hacer ping al servidor? Si intenta conectarse, ¿tcpdump muestra los paquetes que llegan? ¿Utiliza un nombre o una dirección IP como destino? ¿Cuál es exactamente el significado de "conexión rechazada"?

— RalfFriedl

Gracias Ralf Sí, puedo hacer ping al servidor. No sé acerca de tcpdump, así que buscaré esto y veré qué puedo hacer al respecto. ¡Y si supiera lo que significa "rechazar la conexión" significaría que estaría en camino de resolver esto! La frase está tomada del mensaje que recibo en el navegador de laptop1. Ahora he tenido el sentido de verificar el registro de acceso de Apache (ver pregunta editada) parece que estoy obteniendo un tiempo de espera o URL del cliente no encontrada, por servidor, supongo. Entonces, ¿por qué se encuentra la URL de laptop2, pero no la laptop1?

— user30578

En el servidor (Rapsberry), ejecutas tcpdump -n. Es posible que deba agregar un nombre de interfaz como tcpdump -n -i eth0o tcpdump -n -i wlan0. Si systemd usa los llamados nombres predecibles, use ip lpara mostrar los nombres de la interfaz. tcpdumpmostrará los paquetes enviados y recibidos. Los dos efectos principales cuando no se conecta son una espera de algunos segundos seguida de un tiempo de espera o una respuesta inmediata cuando se rechaza la conexión.

— RalfFriedl

Ah, y uso la dirección IP como destino.

— user30578

Entraré en tcpdump tan pronto como pueda ... mientras tanto, he establecido que puedo hacer ping a la computadora portátil1 DESDE el servidor (RPi), por ejemplo, $ ping -c 3 192.168.1.7: 3 paquetes transmitidos, 3 recibidos, así que sé que la computadora portátil1 está escuchando . Aunque en retrospectiva, podría haber deducido eso del ping DESDE laptop1 al servidor.

— user30578

El problema desapareció cuando borré las cookies del navegador Chrome en Laptop1, pero no entiendo por qué. Gracias RalfFriedel por sugerir tcpdump: he aprendido mucho jugando con él, pero en realidad no ayudó a diagnosticar el problema. Los rastros de la computadora portátil1 (conexión rechazada) eran muy diferentes de la computadora portátil2 (la página predeterminada de Apache se muestra correctamente). El rastro de la computadora portátil1 no ha cambiado mucho ahora que se conecta bien, ¡así que me quedo desconcertado! Supongo que aquí (tal vez alguien pueda solucionarme), pero parece que tcpdump está mirando alrededor de las capas de Transporte / Red, mientras que mi problema probablemente estaba en el nivel de Aplicación.

De todos modos, el problema desapareció. Pero no resuelto. John

— usuario30578
fuente