У меня вопрос о настройке squid в качестве обратного прокси за прозрачным / прямым прокси. По сути, я ищу, можно ли настроить (B) следующим образом:
Клиент (A) -> Squid как обратный прокси (B) -> Squid как прямой прокси (C) -> Серверы происхождения в зависимости от URI запроса клиента (D)
В зависимости от запроса клиента от (A), (B) может направить запрос на разные исходные серверы (несколько строк cache_peer). Запрос должен пройти через (C), чтобы достичь (D), поскольку (C) - единственный выход из сети в Интернет. Более того, логика определения, куда идти, заключается в (B).
И у нас нет доступа или контроля над (A) и (C).
Допустим, у меня есть следующие строки cache_peer в (B), а адрес для (C) - «forward-proxy.example.com:3128».
cache_peer origin-x.example.com parent 443 0 no-query originserver ssl
cache_peer origin-y.example.com parent 443 0 no-query originserver ssl
cache_peer origin-z.example.com parent 443 0 no-query originserver ssl
Каким будет синтаксис для настройки (B) использования «forward-proxy.example.com:3128» (C) в качестве прокси-сервера для исходных серверов (D)?
Спасибо!
Да, это возможно, хотя, вероятно, не так, как вы об этом думаете.
Вы много говорите о C, как будто это имеет значение; поскольку вы не можете это контролировать, вам следует перестать об этом беспокоиться. Если не существует более одного C, и который может использоваться для выбора ваших исходных серверов, C совершенно не имеет значения ... он просто мешает (и не позволяет вам использовать более прямые методы выбора исходных серверов).
Вы не можете / не можете определить исходный сервер в этом сценарии с помощью директив cache_peer; cache_peer настраивает, как Squid общается с другими прокси, а не с исходными серверами. Поскольку вы не можете управлять средним Squid, вы не можете выполнять какой-либо выбор непосредственно на исходном сервере; то есть прямой прокси всегда будет переходить на запрошенное вами доменное имя, и это не будет основано на ваших критериях выбора в B. (Если бы у вас был контроль над этим другим Squid, у вас было бы больше возможностей.)
Один из способов добиться того, чего вы хотите, - дать вашим исходным серверам некоторые дополнительные имена, чтобы ваш первый Squid (B) мог переписывать запросы на основе URI в новые доменные имена, а средний кальмар мог делать запросы на основе имени домена.
Вы можете использовать параметр url_rewrite_helper, чтобы использовать программу перезаписи для изменения URL-адреса любым способом, который вы выберете. Если бы это был я, я бы, вероятно, создал новое имя для каждого исходного сервера (a, b, c и т. Д.), А затем переписал бы эти имена на основе любых имеющихся у вас данных. Итак, если ваш URI "http: //domain.tld/a/image.png"Вы можете переписать это на"http: //a.domain.tld/image.png", и "http: //domain.tld/b/image.png"к"http: //b.domain.tld/image.png".
Вам, конечно, потребуется настроить исходные серверы для ответа на эти новые домены и, возможно, настроить их для восстановления URI из измененного, который он получает.
Ссылки:
http://www.squid-cache.org/Doc/config/url_rewrite_program/
И перепишите информацию и пример программы перезаписи:
http://wiki.squid-cache.org/Features/Redirectors#Using_a_re-writer_to_mangle_the_URL_as_it_passes
Вы также можете пропустить определение источника первым сквидом и позволить приложению-источнику распределять ваши запросы по доменам любым разумным способом, указав клиенту запросить с того сервера, который является правильным. Надеюсь это поможет.