Điểm:0

Các nguyên nhân có thể khiến Apache không phản hồi trên cổng 443

lá cờ tr

Bối cảnh: Máy chủ Debian Stretch amd64 trên Google Cloud với Apache 2.4.25. Nó đang chạy một trang web dựa trên PHP thông qua proxy_fcgi đến PHP-FPM. Cơ sở dữ liệu phụ trợ là PostgreSQL 10. Các gói Postgres đã được cài đặt từ kho lưu trữ apt Postgres chính thức, mọi thứ khác là vanilla từ kho lưu trữ Debian. Có một cổng 80 chuyển hướng đến 443 với chứng chỉ Let's Encrypt. HTTP/2 và Brotli được bật. Ngoài ra còn có một proxy ngược tới daemon Sự kiện do Máy chủ Gửi trên cùng một máy chủ (https://github.com/vgno/ssehub).

Máy chủ đã hoạt động được hơn 2 năm, nhưng trong vài tháng gần đây, có một lỗi không liên tục khiến trang web ngừng phản hồi các yêu cầu. Nó thường rõ ràng sau một vài phút. Tôi đã thực hiện rất nhiều phân tích nhật ký và có vẻ như nó không liên quan đến các quy trình của máy chủ. Mức sử dụng CPU là không đáng kể, mức sử dụng bộ nhớ thấp, không có lỗi nào xuất hiện trong nhật ký cho Apache, PostgreSQL, FPM, syslog, ssehub. Máy chủ cũng đã cài đặt fail2ban nhưng cũng không có mục nhật ký nào cho điều đó. Tôi đã đưa vào nhật ký chẩn đoán bổ sung trong Apache và FPM để kiểm tra các yêu cầu mất nhiều thời gian để xử lý, nhưng điều đó không giải quyết được gì.

Đây là đầu ra từ iptables -L:

ĐẦU VÀO chuỗi (chính sách CHẤP NHẬN)
đích prot opt ​​nguồn đích         
f2b-sshd tcp -- mọi nơi mọi nơi đa cổng dports ssh
DROP udp -- bất cứ đâu ở bất cứ đâu udp dpt:l2f policy match dir in pol none
DROP all -- mọi nơi mọi nơi ctstate INVALID
CHẤP NHẬN tất cả -- mọi nơi mọi nơi ctstate LIÊN QUAN, THÀNH LẬP
CHẤP NHẬN udp -- bất cứ nơi đâu nhiều cổng dports isakmp,ipsec-nat-t
CHẤP NHẬN udp -- mọi nơi mọi nơi udp dpt:l2f khớp chính sách dir trong pol ipsec
DROP udp -- mọi nơi mọi nơi udp dpt:l2f

Chuỗi FORWARD (chính sách CHẤP NHẬN)
đích prot opt ​​nguồn đích         
DROP all -- mọi nơi mọi nơi ctstate INVALID
CHẤP NHẬN tất cả -- mọi nơi mọi nơi ctstate LIÊN QUAN, THÀNH LẬP
CHẤP NHẬN tất cả -- mọi nơi mọi nơi            
CHẤP NHẬN tất cả -- 192.168.42.0/24 192.168.42.0/24     
CHẤP NHẬN tất cả -- mọi nơi 192.168.43.0/24 ctstate LIÊN QUAN,THÀNH LẬP
CHẤP NHẬN tất cả -- 192.168.43.0/24 mọi nơi            
DROP all -- mọi nơi mọi nơi            

ĐẦU RA chuỗi (chính sách CHẤP NHẬN)
đích prot opt ​​nguồn đích         

Chuỗi f2b-sshd (1 tài liệu tham khảo)
đích prot opt ​​nguồn đích         
TRẢ LẠI tất cả -- mọi nơi mọi nơi            

Bất kỳ đề xuất cho nguyên nhân có thể hoặc những điều tôi nên kiểm tra? Hiện tại, nguyên nhân duy nhất tôi có thể nghĩ đến là tắc nghẽn mạng, nhưng điều đó rất khó chứng minh vì đây là sự cố không liên tục và thường sẽ hết khi tôi biết về nó và bắt đầu thực hiện một số thử nghiệm. Ngoài ra, có vẻ ngạc nhiên khi Google Cloud thường xuyên gặp sự cố mạng như vậy.Google có một số loại chính sách định hình lưu lượng truy cập mà tôi không biết không? Đó là một máy chủ có lưu lượng truy cập rất thấp và sự cố thường xảy ra ngoài giờ khi hầu như không có ai sử dụng trang web.

Jyothi Kiranmayi avatar
lá cờ at
1. Vấn đề bắt đầu từ khi nào? 2. Bạn đã thực hiện bất kỳ sửa đổi nào đối với phiên bản VM của mình chưa (ví dụ: Đã cài đặt ứng dụng, định cấu hình tường lửa, v.v.)? Chạy lệnh sau và chia sẻ ảnh chụp màn hình kết quả và xác minh xem cổng 443 có đang nghe không (bạn sẽ thấy "Nghe 443"). $ con mèo /etc/Apache2/ports.conf
Kitserve avatar
lá cờ tr
Không có thay đổi nào được thực hiện đối với cấu hình máy chủ hoặc mã trang web. Máy chủ đang lắng nghe trên cổng 443 - như tôi đã nói, đây là lỗi không liên tục. Hầu hết thời gian trang web phản hồi bình thường. Tôi không chắc chính xác thời điểm sự cố bắt đầu nhưng sự cố được báo cáo lần đầu cách đây khoảng 6 tháng.
Bakul Mitra avatar
lá cờ cn
Bạn có thể kiểm tra bất cứ khi nào xảy ra sự cố không liên tục không, Bạn có thể kết nối dịch vụ ứng dụng (trang web) của mình từ một phiên bản VM khác trong cùng một mạng không? Bạn có đang sử dụng bất kỳ bộ cân bằng tải nào phía sau phiên bản VM không?
Kitserve avatar
lá cờ tr
Không có bộ cân bằng tải.Lần tới khi nó xảy ra, nếu tôi cố gắng nắm bắt được nó trong khi sự cố đang diễn ra, tôi sẽ cố gắng kết nối từ một vài địa điểm khác nhau. Không chắc liệu có bất kỳ máy ảo nào khác của tôi nằm trong cùng một mạng hay không, nhưng tôi sẽ kiểm tra.
Abhijith Chitrapu avatar
lá cờ tr
@Kitserve bạn đã kiểm tra và sự cố của bạn đã được giải quyết chưa?
Kitserve avatar
lá cờ tr
Không, nó không được giải quyết. Tôi đã sắp xếp một số thử nghiệm để thử khi sự cố tiếp theo xảy ra, chủ yếu là tcptraroute như được mô tả tại https://support.opendns.com/hc/en-us/articles/227989007-How-to-Running-a-TCP -Theo dõi tuyến đường. Vì tôi đã đăng câu hỏi ban đầu nên sự cố không xuất hiện lại nên tôi không có thêm thông tin chẩn đoán nào để chia sẻ.
Srividya avatar
lá cờ cn
Để cách ly hơn nữa, vui lòng cung cấp cho tôi thông tin sau: Vui lòng kiểm tra xem máy chủ apache có phản hồi không (ví dụ: apache có đang chạy không?) Bạn có thể kết nối với cổng 443 không? Giấy chứng nhận có được cập nhật không? Bạn có thể kết nối qua SSL/TLS với openssl s_client -connect localhost:443 Bạn có thể chia sẻ cho mình log tcpdump và apache trong thời gian phát hành được không.
Kitserve avatar
lá cờ tr
Tôi đánh giá cao các câu trả lời, nhưng tôi nghĩ rằng tôi đã nói khá rõ ràng trong vấn đề ban đầu, đây là vấn đề **không liên tục**. Thông thường Apache phản hồi như bình thường. Cổng 443 đang mở, chứng chỉ được định cấu hình chính xác và trang web hoạt động như mong đợi *gần như* 100% thời gian. Nếu tôi có thể nắm bắt được vấn đề trong khi nó đang xảy ra và chạy một số thử nghiệm, thì tôi sẽ hiểu rõ hơn nhiều về những gì đang diễn ra. Câu hỏi của tôi là liệu có ai có bất kỳ đề xuất nào về nguyên nhân có thể khiến Apache ngừng phản hồi ngẫu nhiên các yêu cầu mà không có bất kỳ mục nhật ký nào xuất hiện hay không. Cảm ơn.
Jyothi Kiranmayi avatar
lá cờ at
Có khả năng xảy ra sự cố bộ nhớ khiến apache không phản hồi các yêu cầu (http/https). Ngoài ra, hãy kiểm tra cài đặt trong tệp cấu hình (httpd.conf): **Không chấp nhận bộ lọc http, AcceptFilter https none** . Tôi khuyên bạn nên khởi động nó vào lần tới, hãy bắt đầu chạy một dấu vết để sau khi nó chết, bạn có thể điều tra xem cuộc gọi nào đã xảy ra lần cuối trước khi nó không thành công. Bạn có thể sử dụng lệnh sau sau khi khởi động nó để đảm bảo rằng bạn đã đính kèm vào quy trình chính và tất cả các quy trình con của nó cũng như bất kỳ quy trình mới nào được rẽ nhánh.
Jyothi Kiranmayi avatar
lá cờ at
pidlist=''; cho pid trong `ps ax | grep httpd | awk '{in $1}'`; làm pidlist="$pidlist -p $pid"; xong; strace -tt -F -f $pidlist 2>&1 |tee /root/apache_strace.out nếu quy trình Apache được gọi là httpd hoặc một cái gì đó khác (như apache hoặc apache2), nhưng nếu nó không phải là httpd, thì hãy đổi tên chính xác thành lệnh trên.
Kitserve avatar
lá cờ tr
Cảm ơn, tôi không biết về AcceptFilter, hiện tại không có bất kỳ tài liệu tham khảo nào về điều đó trong cấu hình, vì vậy tôi sẽ kiểm tra điều đó và cả strace nữa. Tôi đã xem xét các vấn đề về bộ nhớ, nhưng nếu điều đó xảy ra, tôi mong đợi sẽ thấy điều gì đó trong biểu đồ munin và cũng có một số tham chiếu đến Kẻ giết người OOM trong nhật ký lỗi.Máy chủ có 4GB RAM và thường chạy ở mức thấp hơn 25% trong số đó, do đó, nó sẽ phải là mức sử dụng bộ nhớ khá cao để không hiển thị bất kỳ gợi ý nào.
Abhijith Chitrapu avatar
lá cờ tr
@Kitserve bạn đã kiểm tra và sự cố của bạn đã được giải quyết chưa?
Kitserve avatar
lá cờ tr
Vấn đề đã không xuất hiện lại kể từ khi tôi mở câu hỏi này, vì vậy nó không được giải quyết vì tôi không có bất kỳ thông tin chẩn đoán mới nào để xử lý. Tôi sẽ cập nhật hoặc đóng câu hỏi này nếu có gì thay đổi.

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.