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

20

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          
Erel Segal-Halevi
źródło
Czy potrafisz traceroute 132.70.6.157z obu serwerów i porównać wyniki?
Werner Henze
1
443 to porty SSL (https). Sprawdź konfigurację, aby upewnić się, że słuchasz portu HTTP 80.
Mikpa

Odpowiedzi:

13

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.

Tero Kilkanen
źródło
Rzeczywiście, nie ma procesu nasłuchującego na porcie 80! Serwer Apache nasłuchuje na porcie 443. Ale dlaczego?
Erel Segal-Halevi
@ErelSegalHalevi: zazwyczaj 80 to HTTP, 443 to HTTPS (chyba że zmienisz te domyślne porty). Więc może aplikacja oczekuje tylko HTTPS?
Olivier Dulac
Dzięki netstat odkryliśmy, że był to naprawdę problem z konfiguracją w Apache.
Erel Segal-Halevi
26

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

Daniel B.
źródło
problem z siecią? jak więc ta sama domena może zwrócić „odmowę połączenia” dla jednego i „brak trasy do hosta” dla innego portu w tej samej domenie?
phil294
Być może twoja zapora ogniowa lub serwer proxy blokuje drugi port, dlatego problem z siecią?
croraf
3

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.

Sanjeev Gopinath
źródło
1

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.

Jan
źródło