Pārbaudiet DNS tur, kur notiek neveiksmīgā uzmeklēšana. Tas, ka klēpjdators atrisina nosaukumu, nepierāda, ka to spēj Squid vai augstāka līmeņa starpniekserveris, kas izveido tālāko savienojumu.

Izlasiet kļūdainās instances kešatmiņas žurnālu un pārbaudiet servera resolvera iestatījumus. Papildu pārbaude resursdatora līmenī ir:

getent ahosts target.example

Izmantojiet patieso mērķi. getent izmanto resursdatora uzmeklēšanas mehānismu; Squid iekšējais resolveris vai kešatmiņa var atšķirties. Pirms pieņemat, ka tie sakrīt, pārbaudiet skaidri norādītās dns_nameservers un hosts_file ievades.

Squid 6.13 skaidri norādīts nosaukumu serveru saraksts satur IP adreses:

dns_nameservers 192.0.2.53

Aizstājiet šo dokumentācijas adresi ar apstiprinātu resolveri, kas sasniedzams no Squid servera. Privātiem nosaukumiem var būt vajadzīgs organizācijas resolveris; nesaistīts publiskais resolveris tos savā DNS skatā var neredzēt.

Klēpjdatora hosts faila aizstājvārds netiek pārsūtīts kopā ar pieprasījumu pēc resursdatora nosaukuma caur starpniekserveri. Datorā, kas veic uzmeklēšanu, pārskatiet instalētās Squid versijas hosts_file iestatījumu un attiecīgā gadījumā ņemiet vērā augstāka līmeņa starpniekservera resolveri. TLS identitātei lietotajam resursdatora nosaukumam jāatbilst pakalpojumam.

Pēc vienas kontrolētas konfigurācijas izmaiņas pārbaudiet sintaksi un pārlādējiet paredzēto instanci, atkārtojiet to pašu pieprasījumu un pārskatiet ar to saistītos pierādījumus. Kešoti pozitīvi un negatīvi atbilžu rezultāti var ietekmēt atkārtotus testus. Veiksmīga uzmeklēšana, kam seko savienojuma noildze, ir vēlāka maršruta vai atļauju kļūme; neturpiniet mainīt DNS, lai to labotu. Vērtējot servera izmaiņu, nemainiet klienta DNS, augstāka līmeņa starpniekservera maršrutēšanu un starpniekservera protokolu.

Saistītie raksti