Дозвольте ще один HTTPS-порт через Squid

Оновіть обидва ACL портів у Squid 6.13 та обмежте ціль, якщо дозволений HTTPS-сервіс використовує порт 8443.

HTTPS-сервіс на порту 8443 може не працювати через правильно налаштований проксі Squid, навіть якщо звичайний HTTPS на 443 працює. Перш ніж змінювати протокол проксі в клієнті, перевірте відмову CONNECT і політику цільових портів.

У типовій політиці доступу Squid 6.13 важливі дві перевірки: ціль має пройти Safe_ports, а CONNECT — SSL_ports. Додавання порту лише до одного ACL може залишити другу відмову чинною.

Розширюйте наявні визначення обдумано

Для політики, що дозволяє звичайні вебпорти та ще один HTTPS-порт:

acl Safe_ports port 80 443 8443
acl SSL_ports port 443 8443

Замініть або відредагуйте відповідні визначення, щоб не залишити неочікуваний старий набір значень. Збережіть звичайні правила заборони небезпечних портів і CONNECT, а також передбачені обмеження клієнтів.

Обмежте виняток

Якщо додатковий порт потрібен лише для однієї контрольованої цілі, додайте цільову заборону перед правилом, що дозволяє клієнта:

acl extra_tls_port port 8443
acl approved_tls_target dst 203.0.113.20/32
http_access deny CONNECT extra_tls_port !approved_tls_target

Адреса є прикладом для документації. Використовуйте ціль, якою ви керуєте або до якої маєте дозволений доступ, і враховуйте реальні зміни її адреси. Це обмежує виняток для додаткового порту, а не дозволяє всі цілі на 8443.

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

Перевірте дозволене ім’я хоста з його справжнім сертифікатом і портом, потім контрольовану ціль, яка має залишатися забороненою. Залишайте перевірку TLS увімкненою, щоб відрізняти помилки ідентифікації цілі від помилок політики проксі. Не видаляйте весь захист CONNECT заради роботи одного запиту на нестандартний порт.

Схожі статті