Score:0

สาเหตุที่เป็นไปได้สำหรับ Apache ไม่ตอบสนองบนพอร์ต 443

ธง tr

ความเป็นมา: เซิร์ฟเวอร์ Debian Stretch amd64 บน Google Cloud พร้อม Apache 2.4.25 กำลังเรียกใช้เว็บไซต์ที่ใช้ PHP ผ่าน proxy_fcgi ไปยัง PHP-FPM ฐานข้อมูลแบ็กเอนด์คือ PostgreSQL 10 แพ็คเกจ Postgres ได้รับการติดตั้งจาก Postgres apt repo อย่างเป็นทางการ อย่างอื่นคือวานิลลาจาก Debian repos มีพอร์ต 80 เปลี่ยนเส้นทางไปที่ 443 ด้วยใบรับรอง Let's Encrypt เปิดใช้งาน HTTP/2 และ Brotli นอกจากนี้ยังมีพร็อกซีย้อนกลับไปยังดีมอนเหตุการณ์ที่เซิร์ฟเวอร์ส่งบนเซิร์ฟเวอร์เดียวกัน (https://github.com/vgno/ssehub).

เซิร์ฟเวอร์เปิดใช้งานมานานกว่า 2 ปีแล้ว แต่ในช่วงไม่กี่เดือนที่ผ่านมา มีข้อบกพร่องเป็นระยะซึ่งไซต์หยุดตอบสนองคำขอ โดยปกติแล้วจะหายไปหลังจากผ่านไปสองสามนาที ฉันได้ทำการวิเคราะห์บันทึกจำนวนมาก และดูเหมือนว่าจะไม่เกี่ยวข้องกับกระบวนการของเซิร์ฟเวอร์ การใช้งาน CPU เป็นเพียงเล็กน้อย การใช้หน่วยความจำต่ำ ไม่มีข้อผิดพลาดปรากฏในบันทึกสำหรับ Apache, PostgreSQL, FPM, syslog, ssehub เซิร์ฟเวอร์ยังติดตั้งfail2ban แต่ไม่มีรายการบันทึกสำหรับสิ่งนั้น ฉันได้เพิ่มการบันทึกการวินิจฉัยเพิ่มเติมใน Apache และ FPM เพื่อตรวจสอบคำขอที่ใช้เวลานานในการประมวลผล แต่ก็ไม่ได้เกิดอะไรขึ้น

นี่คือผลลัพธ์จาก iptables -L:

เชนอินพุท (ยอมรับนโยบาย)
เป้าหมาย prot เลือกปลายทางต้นทาง         
f2b-sshd tcp -- ทุกที่ ทุกแห่ง หลายพอร์ต dports ssh
DROP udp -- ทุกที่ ทุกแห่ง udp dpt:l2f นโยบายตรงกับ dir ในแบบสำรวจไม่มี
วางทั้งหมด -- ทุกที่ที่ใดก็ได้ ctstate ไม่ถูกต้อง
ยอมรับทั้งหมด -- ทุกที่ ทุกแห่ง ctstate ที่เกี่ยวข้อง ก่อตั้ง
ยอมรับ udp -- ทุกที่ ทุกแห่ง หลายพอร์ต dports isakmp,ipsec-nat-t
ยอมรับ udp -- ทุกที่ ทุกแห่ง udp dpt:l2f ตรงกับนโยบาย dir ใน pol ipsec
DROP udp -- ที่ไหนก็ได้ udp dpt:l2f

ส่งต่อไปข้างหน้า (ยอมรับนโยบาย)
เป้าหมาย prot เลือกปลายทางต้นทาง         
วางทั้งหมด -- ทุกที่ที่ใดก็ได้ ctstate ไม่ถูกต้อง
ยอมรับทั้งหมด -- ทุกที่ ทุกแห่ง ctstate ที่เกี่ยวข้อง ก่อตั้ง
ยอมรับทั้งหมด - ทุกที่ทุกที่            
ยอมรับทั้งหมด -- 192.168.42.0/24 192.168.42.0/24     
ยอมรับทั้งหมด -- ทุกที่ 192.168.43.0/24 ctstate ที่เกี่ยวข้อง ก่อตั้ง
ยอมรับทั้งหมด -- 192.168.43.0/24 ทุกที่            
วางทั้งหมด - ทุกที่ทุกที่            

Chain OUTPUT (ยอมรับนโยบาย)
เป้าหมาย prot เลือกปลายทางต้นทาง         

เชน f2b-sshd (อ้างอิง 1 รายการ)
เป้าหมาย prot เลือกปลายทางต้นทาง         
คืนทั้งหมด - ทุกที่ทุกที่            

คำแนะนำสำหรับสาเหตุที่เป็นไปได้หรือสิ่งที่ฉันควรตรวจสอบ? ในขณะนี้ สาเหตุเดียวที่ฉันคิดได้คือความแออัดของเครือข่าย แต่นั่นพิสูจน์ได้ยากมากเนื่องจากเป็นปัญหาที่ไม่ต่อเนื่องและมักจะหายไปเมื่อฉันรู้ตัวและเริ่มทำการทดสอบบางอย่าง นอกจากนี้ยังน่าแปลกใจที่ Google Cloud จะมีปัญหาเครือข่ายบ่อยครั้งGoogle มีนโยบายการกำหนดปริมาณการเข้าชมบางประเภทที่ฉันไม่ทราบหรือไม่ เป็นเซิร์ฟเวอร์ที่มีทราฟฟิกต่ำมากและปัญหามักเกิดขึ้นนอกเวลาทำการเมื่อแทบไม่มีใครใช้ไซต์

Jyothi Kiranmayi avatar
at flag
1. ปัญหาเริ่มต้นเมื่อใด 2. คุณได้ทำการแก้ไขใดๆ กับอินสแตนซ์ VM ของคุณ (เช่น ติดตั้งแอปพลิเคชัน กำหนดค่าไฟร์วอลล์ ฯลฯ) หรือไม่ เรียกใช้คำสั่งต่อไปนี้และแบ่งปันภาพหน้าจอของผลลัพธ์และตรวจสอบว่าพอร์ต 443 กำลังฟังอยู่หรือไม่ (คุณควรเห็น "ฟัง 443") $cat /etc/apache2/ports.conf
Kitserve avatar
tr flag
ไม่มีการเปลี่ยนแปลงการกำหนดค่าเซิร์ฟเวอร์หรือรหัสเว็บไซต์ เซิร์ฟเวอร์กำลังฟังพอร์ต 443 - อย่างที่ฉันพูดไป นี่เป็นข้อผิดพลาดที่ไม่ต่อเนื่อง เวลาส่วนใหญ่ไซต์ตอบสนองตามปกติ ฉันไม่แน่ใจว่าปัญหาเริ่มต้นเมื่อใด แต่มีการรายงานครั้งแรกเมื่อประมาณ 6 เดือนที่แล้ว
Bakul Mitra avatar
cn flag
คุณสามารถตรวจสอบเมื่อใดก็ตามที่เกิดปัญหาเป็นระยะๆ ได้หรือไม่ คุณสามารถเชื่อมต่อบริการแอปพลิเคชันของคุณ (เว็บไซต์) จากอินสแตนซ์ VM อื่นภายในเครือข่ายเดียวกันได้หรือไม่ คุณใช้โหลดบาลานเซอร์หลังอินสแตนซ์ VM หรือไม่
Kitserve avatar
tr flag
ไม่มีโหลดบาลานเซอร์ครั้งหน้าถ้าฉันจับได้ในขณะที่ปัญหายังดำเนินอยู่ ฉันจะพยายามเชื่อมต่อจากสถานที่ต่างๆ สักแห่ง ไม่แน่ใจว่า VM อื่นๆ ของฉันอยู่ในเครือข่ายเดียวกันหรือไม่ แต่ฉันจะตรวจสอบ
Abhijith Chitrapu avatar
tr flag
@Kitserve คุณตรวจสอบแล้วและปัญหาของคุณได้รับการแก้ไขแล้วหรือยัง
Kitserve avatar
tr flag
ไม่ ยังไม่ได้รับการแก้ไข ฉันได้จัดเตรียมการทดสอบบางอย่างเพื่อลองเมื่อเกิดปัญหาในครั้งถัดไป ส่วนใหญ่เป็น tcptraceroute ตามที่อธิบายไว้ที่ https://support.opendns.com/hc/en-us/articles/227989007-How-to-Running-a-TCP -Traceroute. เนื่องจากฉันโพสต์คำถามเดิม ปัญหาไม่ปรากฏขึ้นอีก ดังนั้นฉันจึงไม่มีข้อมูลการวินิจฉัยที่จะแชร์
Srividya avatar
cn flag
หากต้องการแยกตัวเพิ่มเติม โปรดให้ข้อมูลต่อไปนี้แก่ฉัน: โปรดตรวจสอบว่าเซิร์ฟเวอร์ apache ตอบสนองหรือไม่ (เช่น apache ทำงานอยู่หรือไม่) คุณสามารถเชื่อมต่อกับพอร์ต 443 ได้หรือไม่ ใบรับรองเป็นปัจจุบันหรือไม่ คุณสามารถเชื่อมต่อผ่าน SSL/TLS ด้วย openssl s_client -connect localhost:443 คุณช่วยแชร์บันทึก tcpdump และ apache กับฉันในช่วงเวลาที่มีปัญหาได้ไหม
Kitserve avatar
tr flag
ฉันขอขอบคุณสำหรับคำตอบ แต่ฉันคิดว่าฉันได้พูดไว้ค่อนข้างชัดเจนแล้วในฉบับดั้งเดิมว่า นี่เป็นปัญหา **เป็นระยะๆ** โดยปกติ Apache จะตอบสนองตามปกติ พอร์ต 443 เปิดอยู่ ใบรับรองได้รับการกำหนดค่าอย่างถูกต้อง และไซต์ทำงานได้ตามปกติ *เกือบ* 100% ของเวลาทั้งหมด ถ้าฉันสามารถตรวจจับปัญหาในขณะที่มันเกิดขึ้นและทำการทดสอบบางอย่างได้ ฉันจะมีความคิดที่ดีขึ้นมากเกี่ยวกับสิ่งที่เกิดขึ้น คำถามของฉันคือมีใครมีคำแนะนำเกี่ยวกับสาเหตุที่ทำให้ Apache สุ่มหยุดตอบสนองคำขอโดยไม่มีรายการบันทึกปรากฏขึ้นหรือไม่ ขอบคุณ.
Jyothi Kiranmayi avatar
at flag
มีความเป็นไปได้ที่ปัญหาหน่วยความจำจะหยุด apache จากการตอบสนองต่อคำขอ (http/https) นอกจากนี้ ตรวจสอบการตั้งค่าในไฟล์คอนฟิกูเรชัน (httpd.conf) : **AcceptFilter ไม่มี http ยอมรับตัวกรอง https ไม่มี** ฉันขอแนะนำว่าครั้งต่อไปที่คุณเริ่มต้น ให้เริ่มต้นการติดตามการทำงาน เพื่อที่ว่าหลังจากที่มันตาย คุณสามารถตรวจสอบได้ว่าการโทรใดเกิดขึ้นครั้งสุดท้ายก่อนที่มันจะล้มเหลว คุณสามารถใช้คำสั่งต่อไปนี้หลังจากที่คุณเริ่มต้นเพื่อให้แน่ใจว่าคุณแนบกับกระบวนการหลักและรายการย่อยทั้งหมดและรายการใหม่ใดๆ ที่ถูกแยก
Jyothi Kiranmayi avatar
at flag
พิดลิสต์=''; สำหรับ pid ใน `ps ax | grep httpd | awk '{พิมพ์ $1}'`; ทำ pidlist="$pidlist -p $pid"; เสร็จแล้ว; strace -tt -F -f $pidlist 2>&1 |tee /root/apache_strace.out หากกระบวนการ Apache เรียกว่า httpd หรืออย่างอื่น (เช่น apache หรือ apache2) แต่ถ้าไม่ใช่ httpd ให้สลับชื่อที่ถูกต้องเป็นคำสั่งด้านบน
Kitserve avatar
tr flag
ขอบคุณ ฉันไม่รู้จัก AcceptFilter ตอนนี้ไม่มีการอ้างอิงถึงสิ่งนั้นในการกำหนดค่า ดังนั้นฉันจะตรวจสอบและติดตามด้วย ฉันพิจารณาปัญหาเกี่ยวกับหน่วยความจำ แต่ถ้าสิ่งนั้นเกิดขึ้น ฉันคาดว่าจะเห็นบางอย่างในกราฟ munin และยังมีการอ้างอิงถึง OOM Killer ในบันทึกข้อผิดพลาดด้วยเซิร์ฟเวอร์มี RAM ขนาด 4GB และมักจะทำงานน้อยกว่า 25% ของจำนวนนั้น ดังนั้นจึงต้องมีการใช้งานหน่วยความจำที่ค่อนข้างคมชัดเพื่อไม่ให้แสดงคำใบ้ใดๆ
Abhijith Chitrapu avatar
tr flag
@Kitserve คุณตรวจสอบแล้วและปัญหาของคุณได้รับการแก้ไขแล้วหรือยัง
Kitserve avatar
tr flag
ปัญหาไม่ปรากฏขึ้นอีกตั้งแต่ฉันเปิดคำถามนี้ ดังนั้นจึงไม่ได้รับการแก้ไขเนื่องจากฉันไม่มีข้อมูลการวินิจฉัยใหม่ให้ใช้งาน ฉันจะอัปเดตหรือปิดคำถามนี้หากมีอะไรเปลี่ยนแปลง

โพสต์คำตอบ

คนส่วนใหญ่ไม่เข้าใจว่าการถามคำถามมากมายจะปลดล็อกการเรียนรู้และปรับปรุงความสัมพันธ์ระหว่างบุคคล ตัวอย่างเช่น ในการศึกษาของ Alison แม้ว่าผู้คนจะจำได้อย่างแม่นยำว่ามีคำถามกี่ข้อที่ถูกถามในการสนทนา แต่พวกเขาไม่เข้าใจความเชื่อมโยงระหว่างคำถามและความชอบ จากการศึกษาทั้ง 4 เรื่องที่ผู้เข้าร่วมมีส่วนร่วมในการสนทนาด้วยตนเองหรืออ่านบันทึกการสนทนาของผู้อื่น ผู้คนมักไม่ตระหนักว่าการถามคำถามจะมีอิทธิพลหรือมีอิทธิพลต่อระดับมิตรภาพระหว่างผู้สนทนา