înregistrare Logare
Puncte:0
Tilman Schmidt avatar Server

Cum se depanează Squid ERR_DNS_FAIL

drapel bd
Tilman Schmidt

Gestionez câteva proxy-uri web care rulează Squid 4.10 pe Ubuntu 20.04LTS în mai multe locații distribuite în întreaga lume. Unul dintre ei a dezvoltat un obicei urât de a nu accesa ocazional o pagină web. Utilizatorul primește în schimb o pagină de eroare care spune:

Hmmm... nu pot ajunge la această pagină
Se pare că pagina web de la <URL> ar putea avea probleme,
sau este posibil să se fi mutat definitiv la o nouă adresă web.
ERR_TUNNEL_CONNECTION_FAILED

După adăugare %err_code/%err_detail până la sfârșitul relevantului format de jurnal asa cum este recomandat pe această postare pe lista de corespondență, Intrările Squid access.log pentru accesările eșuate arată astfel:

1635169354.239 171 10.72.1.103 NIMIC/503 0 CONECTARE ad.360yield.com:443 - HIER_
NONE/- - ERR_DNS_FAIL/-

Starea calamarului este NIMIC/503, iar codul de eroare și detaliile întotdeauna ERR_DNS_FAIL/-. Marca temporală, adresa IP a clientului și adresa URL solicitată variază, desigur.

Fiecare apariție a problemei afectează un singur FQDN sau un număr foarte mic de FQDN, adesea toate din aceeași organizație (de ex.lm.licenses.adobe.com și cc-api-data.adobe.io, ambele de la Adobe.) Toate celelalte accesări continuă să funcționeze normal. O apariție durează de obicei între cinci și zece minute. În acest timp, toți clienții care încearcă să acceseze acel FQDN sunt afectați. Înainte și după aceea, același FQDN funcționează fără probleme. Nu există o regularitate vizibilă în FQDN-urile afectate.

Unele dintre apariții sunt însoțite de un mesaj precum:

25/10/2021 15:42:34 copil1| ipcacheParse Nu există înregistrări de adresă ca răspuns la „ad.360yield.com”

în /var/log/squid/cache.log dar în majoritatea cazurilor nu este înregistrat nimic acolo.

Cum pot afla ce nu merge bine acolo?

695
0 + 0
Puncte:0
Tilman Schmidt avatar Server
drapel bd
Tilman Schmidt

Creșterea nivelului de jurnal pentru căutările DNS la 6 prin introducerea directivei

debug_options ALL,1 78,6

în /etc/squid/squid.conf face Squid log la /var/log/squid/cache.log ce server de nume a fost folosit pentru interogările eșuate, de exemplu:

2021/10/26 16:16:43.088 kid1| 78,3| dns_internal.cc(1369) idnsRead: idnsRead: FD 17: a primit 32 de octeți de la 127.0.0.1:53
2021/10/26 16:16:43.088 kid1| 78,3| dns_internal.cc(1176) idnsGrokReply: idnsGrokReply: QID 0x376f, 0 răspunsuri

Eșecurile pot fi apoi investigate în continuare pe acel server de nume.

În cazul meu, aceasta a indicat un dnsmasq Server proxy DNS care rulează pe aceeași mașină. Se activează conectarea la interogare dnsmasq a dezvăluit că unul dintre cele patru servere de nume externe configurate a fost responsabil pentru defecțiuni. Interogările care au fost trimise către acel server de nume au eșuat, în timp ce interogările trimise către unul celorlalte trei au reușit. Deci soluția a fost să renunți la serverul de nume extern defect din configurație.

0 + 0
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.