Протокол PROXY в Squid: доверяйте отправителю до проверок доступа по HTTP
Держите проверки отправителя протокола PROXY в Squid отдельно от авторизации домена назначения и клиентского запроса.
Используйте proxy_protocol_access, чтобы доверять реле, которое передаёт метаданные, а не для выбора разрешённых сайтов. В Squid 5–7 проверка выполняется один раз после установления TCP на слушателе require-proxy-header, до обработки заголовков HTTP-запроса:
acl trusted_relay src 192.0.2.20/32
http_port 3128 require-proxy-header
proxy_protocol_access allow trusted_relay
proxy_protocol_access deny allЗамените адрес реле из примера и ограничьте сетевой доступ к этому слушателю. На этом этапе Squid проверяет фактического участника TCP, прежде чем принять переданные метаданные. После принятия он использует заявленный адрес клиента для последующих проверок ACL и журналирования. Доверие реле на основании адреса клиента, который оно заявляет, перевернуло бы этот порядок.
Сохраните http_access для последующих разрешений на источник клиента и назначение. Принятие метаданных не даёт права доступа к сайтам, а ACL домена назначения не может ответить на более ранний вопрос о доверии к отправителю.
Отправитель и получатель должны согласовать поддерживаемую версию протокола PROXY. Обычный HTTP-клиент не может использовать этот слушатель с обязательным префиксом как обычную конечную точку прокси. Если нужны обе формы, используйте намеренно раздельные конечные точки, а не дублируйте один и тот же адрес прослушивания и порт.
Доверенное реле может влиять на авторизацию по адресу через предоставляемую им личность клиента. Давайте эту возможность только предназначенному посреднику.