Настройка прозрачного прокси-сервера SQUID с базовой аутентификацией

Похоже, вы пытаетесь выполнить прозрачное проксирование (или «проксирование с перехватом», как это называется в FAQ по Squid )с аутентификацией.

FAQ по Squid говорит об этом достаточно ясно:

Can I use ''proxy_auth'' with interception?

No, you cannot. See the answer to the previous question. With interception proxying, the client thinks it is talking to an origin server and would never send the Proxy-authorization request header.

А "предыдущий вопрос":

Why can't I use authentication together with interception proxying?

Interception Proxying works by having an active agent (the proxy) where there should be none. The browser is not expecting it to be there, and it's for all effects and purposes being cheated or, at best, confused. As an user of that browser, I would require it not to give away any credentials to an unexpected party, wouldn't you agree? Especially so when the user-agent can do so without notifying the user [...]

Кроме того, ваш вариант использования больше похож на обратный прокси-сервер , также известный как веб-ускоритель , который также добавляет такие функции, как аутентификация и ведение журнала, поскольку веб--сервер -как применение в вашем http://jarvis:5000может быть недостаточным в этих вещах.

• прозрачный прокси-сервер используется, когда клиентам необходимо иметь доступ практически к любому веб-серверу, не требуя какой-либо конкретной конфигурации прокси-сервера -в браузере :сети (обычно маршрутизатор )перехватывает и перенаправляет любой браузер -, например соединения с прокси-сервером, который затем может применять кеширование, например, минимизируйте международный трафик или внедрите что-то вроде проверки на вредоносное ПО или фильтрации контента для взрослых.

• Обратный прокси-сервер используется только с одним конкретным веб-сервером или группой серверов. Его можно использовать для балансировки загрузки -группы внутренних серверов или для добавления чего-то вроде аутентификации или HTTPS к устройству, которое обеспечивает только HTTP без аутентификации.

Если то, что вы на самом деле хотите, на самом деле больше похоже на обратный прокси-сервер , то вам может быть гораздо лучше использовать возможности прокси-сервера реального веб-сервера, поскольку они дадут вам гораздо лучшие возможности по HTTP. аутентификация на стороне сервера -, которая, по-видимому, является вашим основным требованием.

С Apache вы можете сделать что-то вроде этого:

<Location />
    AuthType Basic
    AuthName "Restricted Service"
    # (Following line optional)
    AuthBasicProvider file
    AuthUserFile "/etc/apache/htpasswd"
    Require user me
    ProxyPass http://jarvis:5000
    ProxyPassReverse http://jarvis:5000
</Location>

и инициализируйте файл /etc/apache/htpasswdс помощью:

# htpasswd -c /usr/local/apache/passwd/passwords me
New password: itsame
Re-type new password: itsame
Adding password for user me

Если сервер в http://jarvis:5000встраивает ссылки или другие ссылки на себя в HTML, который он выводит, и эти ссылки не могут быть изменены путем настройки этого сервера,вам, возможно, придется проделывать трюки, например заставить этот сервер прослушивать только локальный интерфейс, а Apache - только порт 5000 фактического сетевого интерфейса.

Здесь важно знать больше о возможностях сервера http://jarvis:5000. Если он строит свои ответы, используя любое имя хоста и порт, которые, по словам клиента, он использовал для доступа к нему (по принципу «ну, эта информация позволила клиенту подключиться ко мне, поэтому она должна быть правильной» ), тогда это будет легко.. Но если он жестко кодирует свой HTML со ссылками на себя, используя определенный протокол, имя хоста и порт, и они не настраиваются, для достижения того, что вы хотите, может потребоваться хитрость с именами хостов или что-то для редактирования URL-адресов в HTML-ответе в реальном -время.