“ การเชื่อมต่อถูกปฏิเสธ” vs“ ไม่มีเส้นทางไปยังโฮสต์”


20

ฉันมีเซิร์ฟเวอร์ Apache ทำงานบนเซิร์ฟเวอร์:

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

อย่างไรก็ตามเมื่อฉันพยายามเชื่อมต่อกับโฮสต์ในพื้นที่ฉันจะได้รับ "การเชื่อมต่อถูกปฏิเสธ":

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

เกิดขึ้นเหมือนกันเมื่อฉันพยายามเชื่อมต่อกับที่อยู่ 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.

ในทางกลับกันเมื่อฉันลองคอมพิวเตอร์เครื่องเดียวกันในเครือข่ายเดียวกันฉันได้รับข้อผิดพลาด "ไม่มีเส้นทางไปยังโฮสต์":

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

เหตุใดฉันจึงได้รับข้อผิดพลาดเหล่านี้ และฉันควรทำอย่างไรเพื่อให้สามารถเชื่อมต่อกับเซิร์ฟเวอร์ http จากคอมพิวเตอร์เครื่องเดียวกันและคอมพิวเตอร์เครื่องอื่นในเครือข่าย

ปรับปรุง: ขึ้นอยู่กับความคิดเห็นและคำตอบนี่คือข้อมูลเพิ่มเติมบางส่วน:

[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          

คุณสามารถtraceroute 132.70.6.157จากเซิร์ฟเวอร์ทั้งสองและเปรียบเทียบผลลัพธ์ได้หรือไม่
Werner Henze

1
443 คือ SSL-ports (https) ตรวจสอบการกำหนดค่าของคุณเพื่อให้แน่ใจว่าคุณได้ฟัง http port 80
Mikpa

คำตอบ:


13

แสดงผลลัพธ์ของnetstat -lnpดังนั้นเราสามารถดูว่ากระบวนการใดที่กำลังรับฟังพอร์ตใด ๆ บนเซิร์ฟเวอร์และที่อยู่ IP ใดที่ถูกผูกไว้

เกี่ยวกับคอมพิวเตอร์เครื่องที่สองการเชื่อมต่อเครือข่ายนั้นดูเสีย netstat -rnจะให้ข้อมูลเชิงลึกเกี่ยวกับปัญหาที่นั่น

เพื่อให้คำแนะนำที่ดีขึ้นจำเป็นต้องมีรายละเอียดเพิ่มเติมเกี่ยวกับการกำหนดค่าเครือข่ายทั่วไปและการกำหนดค่า IP ในคอมพิวเตอร์ทั้งสองเครื่อง

แก้ไข:

คุณต้องเปลี่ยนการกำหนดค่า Apache ของคุณเพื่อให้เป็นเซิร์ฟเวอร์ HTTP ไม่ใช่เซิร์ฟเวอร์ SSL ไฟล์การกำหนดค่าจะอยู่ที่ / etc / apache2 เกือบตลอดเวลา

ข้อมูลการกำหนดค่า IP และการกำหนดค่าเครือข่ายยังจำเป็นสำหรับการวิเคราะห์ปัญหาอื่น ๆ ข้อมูล traceroute ไม่ได้เปิดเผยอะไรเลย


แน่นอนว่าไม่มีกระบวนการรับฟังพอร์ต 80! เซิร์ฟเวอร์ Apache ฟังที่พอร์ต 443 แต่ทำไมถึงเป็นเช่นนั้น
Erel Segal-Halevi

@ErelSegalHalevi: โดยทั่วไป 80 คือ HTTP, 443 คือ HTTPS (เว้นแต่คุณจะเปลี่ยนพอร์ตเริ่มต้นเหล่านั้น) ดังนั้นแอปพลิเคชันอาจคาดหวัง HTTPS เท่านั้น
Olivier Dulac

ขอบคุณ netstat เราพบว่านี่เป็นปัญหาการกำหนดค่าใน Apache จริงๆ
Erel Segal-Halevi

26

"การเชื่อมต่อถูกปฏิเสธ" หมายความว่าเครื่องเป้าหมายปฏิเสธการเชื่อมต่ออย่างแข็งขัน ด้วยพอร์ต 80 เป็นบริบทหนึ่งในสิ่งต่อไปนี้น่าจะเป็นเหตุผล:

  • ไม่มีอะไรฟังบน 127.0.0.1:80 และ 132.70.6.157:80
  • ไม่มีอะไรฟัง *: 80
  • ไฟร์วอลล์กำลังบล็อกการเชื่อมต่อกับ REJECT

ดังนั้นตรวจสอบการตั้งค่า Apache และ iptables ของคุณ

"ไม่มีเส้นทางสู่โฮสต์" หมายถึงปัญหาเครือข่าย มันไม่ใช่คำตอบจากเครื่องเป้าหมาย


ปัญหาเครือข่าย ดังนั้นโดเมนเดียวกันจะส่งกลับ "การเชื่อมต่อปฏิเสธ" สำหรับหนึ่งและ "ไม่มีเส้นทางไปยังโฮสต์" สำหรับพอร์ตอื่นบนโดเมนเดียวกันได้อย่างไร
phil294

บางทีไฟร์วอลล์หรือพรอกซีของคุณกำลังบล็อกพอร์ตอื่นดังนั้นนั่นเป็นสาเหตุของปัญหาเครือข่าย
croraf

3

ฉันพบโพสต์นี้อธิบายถึงปัญหาที่ฉันเผชิญเมื่อพยายามตั้งค่าหน้า http อย่างง่ายโดยใช้ nodejs บนโหนดการคำนวณของ Cloud สาธารณะ

คำสั่งนี้ได้หลอกลวงสำหรับฉัน:

iptables -F

คำสั่งนี้จะล้างข้อมูลเช่นล้างกฎไฟร์วอลล์ที่ตั้งค่าไว้ในระบบ Linux

คำเตือน: เนื่องจากฉันใช้ไฟร์วอลล์แบบกระจายซึ่งเป็นส่วนหนึ่งของ Public Cloud VCN ฉันไม่ได้ใช้ไฟร์วอลล์ของระบบปฏิบัติการจริงๆ ในกรณีที่คุณไม่มีไฟร์วอลล์ภายนอกตรวจสอบให้แน่ใจว่าได้เพิ่มกฎไฟร์วอลล์ใน iptables


1

อ้างคำตอบของ Ron Maupin จาก/networkengineering/33397/debugging-no-route-to-host-over-ethernet :

ข้อความ ICMP "ไม่มีเส้นทางไปยังโฮสต์" หมายความว่า ARP ไม่สามารถค้นหาที่อยู่เลเยอร์ 2 สำหรับโฮสต์ปลายทาง โดยปกติหมายความว่าโฮสต์ที่มีที่อยู่ IP นั้นไม่ออนไลน์หรือตอบสนอง

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.