2014-02-24 08:49:11 +0000 2014-02-24 08:49:11 +0000
20
20
Advertisement

"Conexión rechazada" frente a "No hay ruta al host"

Advertisement

Tengo un servidor Apache funcionando 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 al host local me sale “Connection refused”:

[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 ocurre 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 otro ordenador de la misma red, me sale otro error “No route to 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 tanto desde el mismo ordenador como desde otros ordenadores de la red?

ACTUALIZACIONES: En base a los comentarios y respuestas, aquí hay algo más de 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
Advertisement

Respuestas (4)

26
26
26
2014-02-24 09:11:38 +0000

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

  • No hay nada escuchando en 127.0.0.1:80 y 132.70.6.157:80
  • No hay nada escuchando en *:80
  • El cortafuegos está bloqueando la conexión con REJECT

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

“No route to host” se refiere a un problema de red. No es una respuesta de la máquina de destino.

13
13
13
2014-02-24 09:09:12 +0000

Muestra la salida de netstat -lnp, para que podamos ver qué procesos están realmente escuchando en qué puertos del servidor, y a qué direcciones IP están vinculados.

En cuanto al segundo ordenador, su conectividad de red parece rota. netstat -rn nos dará una idea del problema.

Para poder dar un mejor consejo, se necesitan más detalles sobre la configuración general de la red y la configuración IP en ambos ordenadores.

Edita:

Tienes que cambiar la configuración de tu Apache para que sea un servidor HTTP, no un servidor SSL. Los archivos de configuración se encuentran en /etc/apache2 la mayoría de las veces.

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

3
Advertisement
3
3
2018-06-14 09:23:31 +0000

Encontré este post que describe el problema que estaba enfrentando al tratar de configurar una página http simple usando nodejs en un nodo de computación de la Nube Pública.

Este comando hizo el truco para mí:

iptables -F

Este comando borra las reglas del firewall que están configuradas dentro del sistema Linux.

Una advertencia: Dado que utilizo el firewall distribuido que forma parte de la VCN de la Nube Pública, no he utilizado realmente el firewall de mi sistema operativo. En caso de que no tengas un firewall externo, asegúrate de añadir una regla de firewall en iptables.

1
1
1
2017-08-01 08:16:53 +0000

Citando la respuesta de Ron Maupin de https://networkengineering.stackexchange.com/questions/33397/debugging-no-route-to-host-over-ethernet :

El mensaje ICMP, “no route to host”, significa que ARP no puede encontrar la dirección de capa 2 para el host de destino. Normalmente, esto significa que el host con esa dirección IP no está en línea o no responde.

Advertisement
Advertisement