Перевіряйте DNS там, де пошук завершується невдало. Якщо ноутбук розв’язує ім’я, це не доводить, що його може розв’язати Squid або батьківський проксі, який встановлює подальше з’єднання.

Прочитайте журнал кешу проблемного екземпляра та перевірте налаштування резолвера сервера. Допоміжна перевірка на рівні хоста:

getent ahosts target.example

Використовуйте справжню ціль. getent задіює механізм пошуку хоста; внутрішній резолвер або кеш Squid може відрізнятися. Перш ніж вважати їх однаковими, перевірте явно задані dns_nameservers та hosts_file.

У Squid 6.13 явно заданий список серверів імен містить IP-адреси:

dns_nameservers 192.0.2.53

Замініть цю адресу для документації схваленим резолвером, доступним із сервера Squid. Приватним іменам може бути потрібен резолвер організації; сторонній публічний резолвер може не бачити їх у своєму поданні DNS.

Псевдонім із файлу hosts ноутбука не передається разом із запитом за іменем хоста через проксі. На машині, яка виконує пошук, перевірте налаштування hosts_file встановленої версії Squid і за потреби врахуйте резолвер батьківського проксі. Ім’я хоста для ідентичності TLS має відповідати сервісу.

Після однієї контрольованої зміни конфігурації перевірте її синтаксис і перезавантажте конфігурацію потрібного екземпляра, повторіть той самий запит і дослідіть відповідні дані. Позитивні й негативні відповіді в кеші можуть впливати на повторні тести. Успішний пошук із подальшим вичерпанням часу з’єднання означає пізніший збій маршруту або прав доступу; не продовжуйте змінювати DNS, щоб його виправити. Оцінюючи зміну сервера, зберігайте незмінними DNS клієнта, маршрутизацію батьківського проксі та протокол проксі.

Схожі статті