Назад | Перейти на главную страницу

Настройте squid в качестве обратного прокси за прозрачным прокси

У меня вопрос о настройке 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

Вы также можете пропустить определение источника первым сквидом и позволить приложению-источнику распределять ваши запросы по доменам любым разумным способом, указав клиенту запросить с того сервера, который является правильным. Надеюсь это поможет.