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

"Connexion refusée" vs "Pas d'itinéraire vers l'hôte

J'ai un serveur Apache qui tourne sur un serveur :

[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
....

Cependant, lorsque j'essaie de me connecter à l'hôte local, j'obtiens “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.

La même chose se produit lorsque j'essaie de me connecter à l'adresse IP locale :

[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.

D'autre part, lorsque j'essaie la même chose depuis un autre ordinateur du même réseau, j'obtiens une erreur différente “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.

Pourquoi est-ce que j'obtiens ces erreurs ? Et que dois-je faire pour pouvoir me connecter au serveur http à partir du même ordinateur et d'autres ordinateurs du réseau ?

MISES À JOUR : Sur la base des commentaires et des réponses, voici quelques informations supplémentaires :

[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

Réponses (4)

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

“Connexion refusée” signifie que la machine cible a activement rejeté la connexion. Avec le port 80 comme contexte, l'une des raisons suivantes est probablement la suivante :

  • Rien n'écoute sur 127.0.0.1:80 et 132.70.6.157:80
  • Rien n'écoute sur *:80
  • Le pare-feu bloque la connexion avec REJECT

Vérifiez donc votre configuration Apache et iptables.

“Pas de route vers l'hôte” fait référence à un problème de réseau. Il ne s'agit pas d'une réponse de la machine cible.

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

Montrez la sortie de netstat -lnp, afin que nous puissions voir quels processus écoutent réellement quels ports sur le serveur, et à quelles adresses IP ils sont liés.

En ce qui concerne le deuxième ordinateur, sa connectivité réseau semble rompue. netstat -rn nous donnera un aperçu du problème.

Afin de donner de meilleurs conseils, il est nécessaire d'obtenir plus de détails concernant la configuration générale du réseau et la configuration IP sur les deux ordinateurs.

Edit :

Vous devez modifier votre configuration Apache pour qu'il s'agisse d'un serveur HTTP et non d'un serveur SSL. Les fichiers de configuration se trouvent sous /etc/apache2 la plupart du temps.

Les informations sur la configuration IP et la configuration réseau sont toujours nécessaires pour analyser l'autre problème. Les informations de traceroute n'ont rien révélé.

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

J'ai trouvé ce post décrivant le problème auquel je faisais face lorsque j'essayais de mettre en place une simple page http en utilisant des nodejs sur un nœud de calcul du Public Cloud.

Cette commande a fait l'affaire pour moi :

iptables -F

Cette commande permet de vider, c'est-à-dire d'effacer les règles du pare-feu qui sont configurées dans le système Linux.

Parole d'avertissement : Comme j'utilise le pare-feu distribué qui fait partie du VCN du nuage public, je n'ai pas vraiment utilisé le pare-feu de mon système d'exploitation. Si vous n'avez pas de pare-feu externe, veillez à ajouter une règle de pare-feu dans iptables.

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

Citant la réponse de Ron Maupin de https://networkengineering.stackexchange.com/questions/33397/debugging-no-route-to-host-over-ethernet :

Le message ICMP, “no route to host”, signifie que l'ARP ne peut pas trouver l'adresse de couche 2 pour l'hôte de destination. En général, cela signifie que l'hôte ayant cette adresse IP n'est pas en ligne ou ne répond pas.