Настройте сквид как обратный прокси позади прозрачного прокси
У меня есть вопрос об установке сквида как обратный прокси позади прозрачного / вперед прокси. В основном то, что я ищу, - возможно ли настроить (B) в следующем:
Клиент (A)-> Сквид как Обратный Прокси (B)-> Сквид как Вперед Прокси (C)-> Серверы Источника В зависимости от Клиентского Запроса URI (D)
В зависимости от клиента запрашивают от (A), (B) мог направить запрос к различным серверам источника (несколько cache_peer строк). Запрос должен пройти (C) для достижения (D), поскольку (C) является единственным выходом из сети к Интернету. Кроме того, логика выяснения, куда перейти ко лжи в (B).
И у нас нет доступа к или управления (A) и (C).
Скажем, у меня есть следующие cache_peer строки в (B), и адрес для (C) "вперед-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) для использования "вперед-proxy.example.com:3128" (C) в качестве вперед прокси к серверам источника (D)?
Спасибо!
Да, это возможно, хотя, вероятно, не так, как вы думаете.
Вы много говорите о C, как будто это имеет значение; так как вы не имеете контроля над этим, вы должны перестать беспокоиться об этом. Если нет более одного C, и это можно использовать для выбора исходных серверов, то C совершенно не имеет значения... это просто мешает (и действительно мешает вам использовать более прямые методы выбора исходных серверов).
В этом сценарии вы не определяете/не можете определить исходный сервер с помощью директив cache_peer; cache_peer настраивает, как Squid взаимодействует с другими прокси-серверами, а не с исходными серверами. Так как вы не можете контролировать средний Squid, вы не можете осуществлять выбор непосредственно на исходном сервере; т.е. forward proxy всегда будет обращаться к доменному имени, которое вы запросили, и это не будет основано на ваших критериях выбора в B. (Если бы у вас был контроль над другим Squid, у вас было бы больше вариантов. )
Один из способов достичь желаемого - дать вашим исходным серверам дополнительные имена, чтобы ваш первый Squid (B) мог переписывать запросы, основанные на URI, на новые доменные имена, а средний squid мог делать запросы, основанные на доменном имени.
Вы можете использовать опцию 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
Вы также можете пропустить то, что первый squid определил происхождение, и позволить исходному приложению распределить ваши запросы по доменам так, как это имеет смысл, сказав клиенту, чтобы он запросил с любого сервера, который ему нужен. Надеюсь, это поможет.