„Odmowa połączenia” vs „Brak trasy do hosta”

Mam serwer Apache działający na serwerze:

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

Jednak gdy próbuję połączyć się z hostem lokalnym, pojawia się komunikat „Odmowa połączenia”:

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

To samo dzieje się, gdy próbuję połączyć się z lokalnym adresem IP:

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

Z drugiej strony, gdy próbuję tego samego z innego komputera w tej samej sieci, pojawia się inny błąd „Brak trasy do hosta”:

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

Dlaczego dostaję te błędy? A co powinienem zrobić, aby móc połączyć się z serwerem http z tego samego komputera i innych komputerów w sieci?

AKTUALIZACJE: Na podstawie komentarzy i odpowiedzi oto kilka dodatkowych informacji:

[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          

Pokaż wynik netstat -lnp, abyśmy mogli zobaczyć, które procesy faktycznie nasłuchują, które porty na serwerze i jakie adresy IP są powiązane.

Jeśli chodzi o drugi komputer, jego połączenie sieciowe wygląda na zepsute. netstat -rnda wgląd w problem.

Aby udzielić lepszych porad, potrzebne są dodatkowe szczegóły dotyczące ogólnej konfiguracji sieci i konfiguracji IP na obu komputerach.

Edytować:

Musisz zmienić konfigurację Apache, aby była to serwer HTTP, a nie serwer SSL. Pliki konfiguracyjne znajdują się w większości przypadków w / etc / apache2.

Informacje o konfiguracji IP i konfiguracji sieci są nadal potrzebne do analizy drugiego problemu. Informacje traceroute niczego nie ujawniły.

„Odmowa połączenia” oznacza, że ​​komputer docelowy aktywnie odrzucił połączenie. W kontekście portu 80 przyczyną może być jedna z następujących rzeczy:

• Nic nie nasłuchuje na 127.0.0.1:80 i 132.70.6.157:80
• Nic nie słucha *: 80
• Zapora blokuje połączenie z REJECT

Więc sprawdź konfigurację Apache i iptables.

„Brak trasy do hosta” oznacza problem z siecią. To nie jest odpowiedź z maszyny docelowej.

Znalazłem ten post opisujący problem, z którym miałem do czynienia, próbując skonfigurować prostą stronę http za pomocą nodejs w węźle obliczeń Public Cloud.

To polecenie załatwiło sprawę:

iptables -F

To polecenie opróżnia, tzn. Usuwa reguły zapory, które są konfigurowane w systemie Linux.

Uwaga: ponieważ korzystam z rozproszonej zapory ogniowej, która jest częścią Public Cloud VCN, tak naprawdę nie użyłem zapory mojego systemu operacyjnego. Jeśli nie masz zewnętrznej zapory, upewnij się, że dodałeś regułę zapory w iptables.

Powołując się na odpowiedź Rona Maupina z /networkengineering/33397/debugging-no-route-to-host-over-ethernet :

Komunikat ICMP „brak trasy do hosta” oznacza, że ​​ARP nie może znaleźć adresu warstwy 2 dla hosta docelowego. Zwykle oznacza to, że host z tym adresem IP nie jest w trybie online lub nie odpowiada.