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

"Connessione rifiutata" vs "Nessuna rotta verso l'host"

Ho un server Apache in esecuzione su un server: 

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

Tuttavia, quando provo a connettermi all'host locale ottengo “Connessione rifiutata”: 

[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 stesso accade quando provo a connettermi all'indirizzo 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'altra parte, quando provo lo stesso da un altro computer nella stessa rete, ottengo un errore diverso “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.

Perché ricevo questi errori? E cosa dovrei fare per essere in grado di connettermi al server http sia dallo stesso computer che da altri computer della rete?

Aggiornamenti: Sulla base dei commenti e delle risposte, ecco altre informazioni: 

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

Risposte (4)

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

“Connessione rifiutata” significa che la macchina di destinazione ha attivamente rifiutato la connessione. Con la porta 80 come contesto, una delle seguenti cose è probabilmente la ragione:

  • Niente è in ascolto su 127.0.0.1:80 e 132.70.6.157:80
  • Niente è in ascolto su *:80
  • Il firewall sta bloccando la connessione con REJECT

Quindi controlla la configurazione di Apache e iptables.

“No route to host” si riferisce a un problema di rete. Non è non una risposta dalla macchina di destinazione.
Fonte
13
13
13
2014-02-24 09:09:12 +0000

Mostra l'output di netstat -lnp, così possiamo vedere quali processi sono effettivamente in ascolto su quali porte del server, e a quali indirizzi IP sono legati.

Per quanto riguarda il secondo computer, la sua connettività di rete sembra rotta. netstat -rn darà qualche informazione sul problema.

Per poter dare un consiglio migliore, sono necessari maggiori dettagli sulla configurazione generale della rete e sulla configurazione IP di entrambi i computer.

Modifica:

Devi cambiare la configurazione di Apache in modo che sia un server HTTP, non SSL. I file di configurazione si trovano sotto /etc/apache2 il più delle volte.

Le informazioni di configurazione IP e di rete sono ancora necessarie per analizzare l'altro problema. Le informazioni di traceroute non hanno rivelato nulla.
Fonte
3
3
3
2018-06-14 09:23:31 +0000

Ho trovato questo post che descrive il problema che stavo affrontando quando ho cercato di impostare una semplice pagina http usando nodejs su un nodo di calcolo Public Cloud.

Questo comando ha fatto il trucco per me:

iptables -F

Questo comando esegue il flush, cioè cancella le regole del firewall che sono impostate nel sistema Linux.

Una parola di cautela: Dato che uso il firewall distribuito che fa parte del Public Cloud VCN, non ho usato il firewall del mio sistema operativo. Nel caso non abbiate un firewall esterno, assicuratevi di aggiungere una regola firewall in iptables.
Fonte
1
1
1
2017-08-01 08:16:53 +0000

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

Il messaggio ICMP, “no route to host”, significa che ARP non può trovare l'indirizzo layer-2 per l'host di destinazione. Di solito, questo significa che l'host con quell'indirizzo IP non è online o non risponde.
Fonte