"Conexión rechazada" vs "No hay ruta al host"

20

Tengo un servidor Apache ejecutándose en un servidor:

[root@te-srv2 ~]# ps -ecf|grep httpd
root       698 32047 TS   19 10:45 pts/24   00:00:00 grep httpd
root     32081     1 TS   19 10:16 ?        00:00:00 /usr/sbin/httpd
apache   32083 32081 TS   19 10:16 ?        00:00:00 /usr/sbin/httpd
apache   32084 32081 TS   19 10:16 ?        00:00:00 /usr/sbin/httpd
....

Sin embargo, cuando intento conectarme con el host local me aparece "Conexión rechazada":

[root@te-srv2 ~]# wget http://127.0.0.1
--2014-02-24 10:46:16--  http://127.0.0.1/
Connecting to 127.0.0.1:80... failed: Connection refused.

Lo mismo sucede cuando intento conectarme a la dirección IP local:

[root@te-srv2 ~]# wget http://132.70.6.157
--2014-02-24 10:46:40--  http://132.70.6.157/
Connecting to 132.70.6.157:80... failed: Connection refused.

Por otro lado, cuando intento lo mismo desde otra computadora en la misma red, aparece un error diferente "No hay ruta al host":

[erelsgl@erel-biu ~]$ wget http://132.70.6.157
--2014-02-24 10:49:11--  http://132.70.6.157/
Connecting to 132.70.6.157:80... failed: No route to host.

¿Por qué recibo estos errores? ¿Y qué debo hacer para poder conectarme al servidor http desde la misma computadora y otras computadoras en la red?

ACTUALIZACIONES: Basado en los comentarios y respuestas, aquí hay más información:

[root@te-srv2 ~]# traceroute 132.70.6.157
traceroute to 132.70.6.157 (132.70.6.157), 30 hops max, 60 byte packets
 1  te-srv2 (132.70.6.157)  0.082 ms  0.007 ms  0.005 ms

[erelsgl@erel-biu ~]$ traceroute 132.70.6.157
traceroute to 132.70.6.157 (132.70.6.157), 30 hops max, 60 byte packets
 1  te-srv2 (132.70.6.157)  0.446 ms !X  0.431 ms !X  0.420 ms !X

[root@te-srv2 ~]# netstat -lnp|grep http
tcp        0      0 :::443                      :::*                        LISTEN      5756/httpd
networking apache-http-server routing Erel Segal-Halevi
fuente
¿Puedes traceroute 132.70.6.157desde ambos servidores y comparar la salida?
Werner Henze
1
443 son los puertos SSL (https). Verifique su configuración para asegurarse de escuchar el puerto http 80.
Mikpa

Respuestas:

13

Muestre el resultado de netstat -lnp, para que podamos ver qué procesos están realmente escuchando qué puertos en el servidor y a qué direcciones IP están vinculados.

Con respecto a la segunda computadora, su conectividad de red parece rota. netstat -rndará una idea del problema allí.

Para brindar un mejor asesoramiento, se necesitan más detalles sobre la configuración general de la red y la configuración de IP en ambas computadoras.

Editar:

Debe cambiar su configuración de Apache para que sea un servidor HTTP, no un servidor SSL. Los archivos de configuración se encuentran en / etc / apache2 la mayor parte del tiempo.

La información de configuración de red y configuración de IP todavía es necesaria para analizar el otro problema. La información del traceroute no reveló nada.

Tero Kilkanen
fuente
De hecho, ¡no hay ningún proceso para escuchar el puerto 80! El servidor Apache escucha en el puerto 443. ¿Pero por qué es esto?
Erel Segal-Halevi
@ErelSegalHalevi: normalmente, 80 es HTTP, 443 es HTTPS (a menos que cambie los puertos predeterminados). Entonces, ¿tal vez la aplicación solo espera HTTPS?
Olivier Dulac
Gracias a netstat, descubrimos que esto era realmente un problema de configuración en Apache.
Erel Segal-Halevi
26

"Conexión rechazada" significa que la máquina de destino rechazó activamente la conexión. Con el puerto 80 como contexto, una de las siguientes cosas es probablemente la razón:

  • Nada está escuchando en 127.0.0.1:80 y 132.70.6.157:80
  • Nada está escuchando *: 80
  • El firewall está bloqueando la conexión con RECHAZAR

Así que verifique su configuración de Apache e iptables.

"Sin ruta al host" se refiere a un problema de red. Es no una respuesta de la máquina de destino.

Daniel B
fuente
un problema de red? Entonces, ¿cómo puede el mismo dominio devolver "conexión rechazada" para uno y "ninguna ruta al host" para otro puerto, en el mismo dominio?
phil294
Tal vez su firewall o proxy esté bloqueando el otro puerto, ¿por eso hay un problema de red?
croraf
3

Encontré esta publicación que describe el problema que estaba enfrentando al intentar configurar una página http simple usando nodejs en un nodo de cómputo de Public Cloud.

Este comando hizo el truco para mí:

iptables -F

Este comando se descarga, es decir, borra las reglas de firewall que se configuran dentro del sistema Linux.

Palabra de advertencia: como uso el firewall distribuido que es parte de Public Cloud VCN, realmente no utilicé el firewall de mi sistema operativo. En caso de que no tenga un firewall externo, asegúrese de agregar una regla de firewall en iptables.

Sanjeev Gopinath
fuente