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

Получите весь HTTP-трафик с помощью прокси

Я хочу настроить прокси-сервер, который будет получать весь HTTP-трафик в моей сети. Думаю использовать установленный на Debian Squid.

Под схемой сети:

Я не хочу настраивать прокси-сервер в своей локальной сети, потому что я не могу настроить прокси-сервер на каждом компьютере.

Может ли кто-нибудь сказать мне, как лучше всего это сделать?

Лучше всего настроить squid в прозрачном режиме, но ваша сетевая диаграмма изменится. Поскольку прокси-сервер использует NAT, это также заменит ваш cisco в качестве маршрутизатора. (и, пока на нем, почему бы не удалить маршрутизатор вашего интернет-провайдера, чтобы не удваивать NAT? Как будто когда-нибудь вы захотите создать какой-то VPN, вы не можете использовать двойной NAT)

См. Учебник там; http://xmodulo.com/squid-transparent-web-proxy-centos-rhel.html

В учебнике есть несколько деталей, которые показывают, как он это сделал;

Установка Squid

Чтобы настроить прозрачный прокси с Squid, мы начнем с добавления необходимых правил iptables. Эти правила должны помочь вам начать работу, но убедитесь, что они не противоречат какой-либо существующей конфигурации.

iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT - к порту 3128

Первое правило приведет к тому, что все исходящие пакеты от eth1 (интерфейс WAN) будут иметь исходный IP-адрес eth1 (т.е. включить NAT). Второе правило будет перенаправлять все входящие HTTP-пакеты (предназначенные для TCP 80) с eth0 (интерфейс LAN) на порт прослушивания Squid (TCP 3128), вместо того, чтобы сразу пересылать их на интерфейс WAN.

Имейте в виду, что есть побочные эффекты перехвата соединений с http, и на самом деле в нашей технической поддержке для нашего продукта (WinGate) хотя мы поддерживаем перехват соединений, мы не рекомендуем этого делать.

  1. Если вы используете аутентификацию на прокси-сервере, клиент не знает, что он обращается к прокси. Если прокси-сервер хочет аутентифицировать перехваченного клиента, он может отправить только ответ 401 (не 407), и это выглядит для клиента так, как будто конечный сервер запрашивает аутентификацию. для страницы с ресурсами со многих серверов может появиться несколько диалоговых окон входа в систему.

  2. Кеширование ведет себя иначе. Существуют директивы кэширования для конкретного прокси, которые не работают, когда вы перехватываете соединение с прокси.

  3. Некоторые подвиги. В предложенном вами сценарии, когда вы перенаправляете соединение от ASA к прокси, адрес назначения перезаписывается ASA, и соединение завершается на прокси. Тогда у прокси-сервера есть только заголовок хоста, который будет использоваться в качестве основы для создания восходящего соединения. Это требует дополнительного поиска DNS через прокси, что может привести к другому ответу, нежели тот, который клиент получил при поиске на сайте. Также в некоторых случаях известно, что клиенты подключаются к разрешенному IP-адресу, используя заголовок hosts для запрещенного сайта. Разрешенный IP-адрес проходит через брандмауэр, но прокси просматривает заголовок хоста и подключается к другому (запрещенному) IP-адресу.

Вы, вероятно, также захотите подумать, что делать с https.

Отказ от ответственности: я работаю в Qbik, который является авторами WinGate.