înregistrare Logare
Puncte:0
Kitserve avatar Server

Cauze posibile pentru care Apache nu răspunde pe portul 443

drapel tr
Kitserve

Context: serverul Debian Stretch amd64 pe Google Cloud cu Apache 2.4.25. Rulează un site web bazat pe PHP prin proxy_fcgi la PHP-FPM. Baza de date backend este PostgreSQL 10. Pachetele Postgres au fost instalate din depozitul oficial de apt Postgres, totul este vanilla din depozitul Debian. Există o redirecționare a portului 80 către 443 cu certificate Let's Encrypt. HTTP/2 și Brotli sunt activate. Există, de asemenea, un proxy invers pentru un daemon de eveniment trimis de server pe același server (https://github.com/vgno/ssehub).

Serverul a funcționat de peste 2 ani, dar în ultimele luni există o defecțiune intermitentă în care site-ul nu mai răspunde la solicitări. De obicei, se limpezește după câteva minute. Am făcut multe analize de jurnal și nu pare să aibă legătură cu procesele serverului. Utilizarea CPU este nominală, utilizarea memoriei este scăzută, nu apar erori în jurnalele pentru Apache, PostgreSQL, FPM, syslog, ssehub. Serverul are și fail2ban instalat, dar nu există nicio intrare de jurnal pentru asta. Am introdus o înregistrare suplimentară de diagnosticare în Apache și FPM pentru a verifica cererile care durează mult timp pentru a procesa, dar care nu au rezultat nimic.

Iată rezultatul de la iptables -L:

INTRARE în lanț (politica ACCEPTĂ)
target prot opt ​​sursă destinație         
f2b-sshd tcp -- oriunde oriunde multiport dports ssh
DROP udp -- oriunde oriunde udp dpt:l2f politica potrivire dir în pol nici unul
DROP all -- oriunde oriunde ctstate INVALID
ACCEPTĂ toate -- oriunde oriunde ctstate RELATED,STABLISHED
ACCEPT udp -- oriunde oriunde multiport dports isakmp,ipsec-nat-t
ACCEPT udp -- oriunde oriunde udp dpt:l2f policy potrivire director în pol ipsec
DROP udp -- oriunde oriunde udp dpt:l2f

Lanț FORWARD (politica ACCEPT)
target prot opt ​​sursă destinație         
DROP all -- oriunde oriunde ctstate INVALID
ACCEPTĂ toate -- oriunde oriunde ctstate RELATED,STABLISHED
ACCEPT pe toate -- oriunde oriunde            
ACCEPT pe toate -- 192.168.42.0/24 192.168.42.0/24     
ACCEPT pe toate -- oriunde 192.168.43.0/24 ctstate RELATED,STABLISHED
ACCEPTĂ toate -- 192.168.43.0/24 oriunde            
DROP all -- oriunde oriunde            

Ieșire în lanț (politica ACCEPT)
target prot opt ​​sursă destinație         

Lanț f2b-sshd (1 referințe)
target prot opt ​​sursă destinație         
RETURN all -- oriunde oriunde

Orice sugestii pentru cauze posibile sau lucruri pe care ar trebui să le verific? Momentan, singura cauză la care mă pot gândi este congestionarea rețelei, dar este foarte greu de demonstrat, deoarece este o problemă intermitentă și de obicei se lămurește în momentul în care îmi dau seama și încep să fac niște teste. În plus, pare surprinzător că Google Cloud ar avea probleme atât de frecvente de rețea.Are Google un fel de politici de modelare a traficului pe care nu le cunosc? Este un server cu trafic foarte scăzut și problema apare frecvent în afara orelor de program, când practic nimeni nu folosește site-ul.

177
0 + 0
Jyothi Kiranmayi avatar
drapel at
Jyothi Kiranmayi
1. Când a început problema? 2. Ați făcut modificări instanței dvs. VM (de exemplu, ați instalat o aplicație, ați configurat firewall-urile etc.)? Rulați următoarea comandă și partajați captura de ecran a rezultatului și verificați dacă portul 443 ascultă (ar trebui să vedeți „Ascultați 443”). $ cat /etc/apache2/ports.conf
0
Răspunde
Kitserve avatar
drapel tr
Kitserve
Nu s-au făcut modificări la configurația serverului sau codul site-ului web. Serverul ascultă pe portul 443 - așa cum am spus, aceasta este o defecțiune intermitentă. De cele mai multe ori site-ul răspunde normal. Nu sunt sigur exact când a început problema, dar a fost raportată pentru prima dată acum aproximativ 6 luni.
0
Răspunde
Bakul Mitra avatar
drapel cn
Bakul Mitra
Puteți verifica ori de câte ori apare o problemă intermitentă, puteți să vă conectați serviciul de aplicație (site-ul web) de la o altă instanță VM din aceeași rețea? Utilizați vreun echilibrator de încărcare în spatele instanței VM?
0
Răspunde
Kitserve avatar
drapel tr
Kitserve
Nu există un echilibrator de încărcare.Data viitoare când se întâmplă, dacă reușesc să-l prind în timp ce problema este în curs, voi încerca să încerc să mă conectez din câteva locații diferite. Nu sunt sigur dacă oricare dintre celelalte VM ale mele se află în exact aceeași rețea, dar voi verifica.
0
Răspunde
Abhijith Chitrapu avatar
drapel tr
Abhijith Chitrapu
@Kitserve ai verificat și problema ta este rezolvată?
0
Răspunde
Kitserve avatar
drapel tr
Kitserve
Nu, nu s-a rezolvat. Am aliniat câteva teste pe care să le încerc atunci când apare următoarea problemă, în principal tcptraceroute, așa cum este descris la https://support.opendns.com/hc/en-us/articles/227989007-How-to-Running-a-TCP -Traceroute. De când am postat întrebarea inițială, problema nu a reapărut, așa că nu am mai multe informații de diagnostic de partajat.
0
Răspunde
Srividya avatar
drapel cn
Srividya
Pentru a izola mai mult, vă rugăm să-mi furnizați următoarele informații: Vă rugăm să verificați dacă serverul apache răspunde (de exemplu, apache rulează?) Vă puteți conecta la portul 443? Este certificatul la zi? Vă puteți conecta prin SSL/TLS cu openssl s_client -connect localhost:443 Îmi puteți împărtăși jurnalele tcpdump și apache în timpul emiterii.
0
Răspunde
Kitserve avatar
drapel tr
Kitserve
Apreciez răspunsurile, dar am crezut că am spus destul de clar în numărul original, aceasta este o problemă **intermitentă**. În mod normal, Apache răspunde normal. Portul 443 este deschis, certificatul este configurat corect și site-ul funcționează conform așteptărilor *aproape* 100% din timp. Dacă aș fi capabil să identific problema în timp ce se produce și să execut niște teste, aș avea o idee mult mai bună despre ce se întâmplă. Întrebarea mea este dacă cineva are sugestii de cauze posibile pentru ca Apache să nu mai răspundă aleatoriu la solicitări fără să apară nicio intrare de jurnal. Mulțumiri.
0
Răspunde
Jyothi Kiranmayi avatar
drapel at
Jyothi Kiranmayi
Există posibilitatea ca problemele de memorie să împiedice apache să răspundă la solicitări (http/https). De asemenea, verificați setările din fișierul de configurare (httpd.conf): **AcceptFilter http niciunul, AcceptFilter https niciunul** . Vă sugerez că data viitoare când îl porniți, începeți să ruleze o urmărire, astfel încât după ce acesta moare să puteți investiga ce apeluri au avut loc ultimele înainte de a eșua. Puteți folosi următoarea comandă după ce o porniți pentru a vă asigura că vă atașați la procesul principal și la toți copiii acestuia și la orice alt nou care se furcă.
0
Răspunde
Jyothi Kiranmayi avatar
drapel at
Jyothi Kiranmayi
pidlist=''; pentru pid în `ps ax | grep httpd | awk '{print $1}''; do pidlist="$pidlist -p $pid"; Terminat; strace -tt -F -f $pidlist 2>&1 |tee /root/apache_strace.out dacă procesul Apache se numește httpd sau altceva (cum ar fi apache sau apache2), dar dacă nu este httpd, atunci schimbați numele corect în comanda de mai sus.
0
Răspunde
Kitserve avatar
drapel tr
Kitserve
Mulțumesc, nu cunoșteam AcceptFilter, în prezent nu există referințe la acesta în configurație, așa că voi verifica asta și și strace. Am luat în considerare problemele de memorie, dar dacă asta s-ar întâmpla, mă așteptam să văd ceva în graficele munin și, de asemenea, o referință la OOM Killer în jurnalul de erori.Serverul are 4 GB de RAM și de obicei rulează la mai puțin de 25% din aceasta, așa că ar trebui să fie un vârf destul de puternic de utilizare a memoriei pentru a nu arăta niciun indiciu.
0
Răspunde
Abhijith Chitrapu avatar
drapel tr
Abhijith Chitrapu
@Kitserve ai verificat și problema ta este rezolvată?
0
Răspunde
Kitserve avatar
drapel tr
Kitserve
Problema nu a reapărut de când am deschis această întrebare, așa că nu a fost rezolvată, deoarece nu am informații noi de diagnosticare cu care să lucrez. Voi actualiza sau voi închide această întrebare dacă se schimbă ceva.
0
Răspunde
drapel romania
SEF 777
întrebarea această in alte limbi:

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.