У нас есть прокси-сервер Squid в облаке с IP-адресом 50.x.y.z, который прослушивает TCP-порт 3128 и работает в прозрачном режиме. Этот прокси-сервер работает под управлением Debian 6.0 и расположен в центре обработки данных.
В нашем офисе есть маршрутизатор Cisco с общедоступным IP-адресом 203.x.y.z / 29 и частным IP-адресом 192.168.1.1/24. Локальная сеть LAN - 192.168.1.0/24. Я разрешил общедоступный IP-адрес 203.x.y.z / 29 в файле squid.conf, и, следовательно, пользователи локальной сети могут просматривать Интернет с помощью этого прокси-сервера squid. Я хотел бы знать, можно ли прозрачно перенаправить весь веб-трафик на сервер squid, работающий в центре обработки данных ??
Обратите внимание, что я полностью осознаю тот факт, что это можно сделать с помощью карты маршрутов или WCCP, если у меня был прокси-сервер в ЛОКАЛЬНОЙ ЛВС, а также что я могу использовать WPAD для автоматического обнаружения прокси, но мне нужно прозрачное перенаправление.
Единственный реальный способ сделать это без дополнительного оборудования на месте - это использовать WCCP. Вы должны иметь возможность создать туннель WCCP GRE через внешний публичный адрес в облачную систему.
Если ваш интернет-провайдер также управляет центром обработки данных, он может маршрутизировать ваш трафик через имеющийся у вас сервер Squid. В противном случае я бы посмотрел на установку небольшого ящика squid локально, который выполняет прозрачный перехват трафика, а затем отправляет его в облачную систему, или заменяет ящик cisco на универсальный прокси / кеш / фильтр / брандмауэр, будь то доморощенный СОПО или что-то коммерческое.
Единственное, что я могу придумать, - это какой-то туннель. Вам просто нужно направить этот трафик порта 80, который будет иметь случайные глобальные IP-адреса назначения, на ваш облачный прокси. Это невозможно без какой-либо поддержки в вашей инфраструктуре маршрутизации.
В любом случае вам, вероятно, понадобится туннель IPsec между вашей сетью и облачным экземпляром для обеспечения безопасности. Если ваш текущий маршрутизатор (-ы) не поддерживает такие функции, я бы предложил поэкспериментировать с Вятта Ядро, указав для некоторых тестовых рабочих станций маршрутизатор Vyatta в качестве шлюза по умолчанию. Затем они Vyatta будут настроены для перенаправления всего общедоступного трафика TCP-port-80 через туннель IPsec (или даже GRE или IP-in-IP, если вас не заботит безопасность), который завершается в экземпляре облака.
Обратите внимание, что всякий раз, когда задействованы туннели, у вас будут проблемы с MTU, поэтому вы должны убедиться, что вы не блокируете слишком большие сообщения ICMP-пакета в любом брандмауэре (даже локальном для рабочей станции), и вы потенциально можете переписать максимальный размер сегмента TCP в пакетах подтверждения TCP видит Вятта.
Честно говоря, с proxy-auto-config справиться будет намного проще. Вы даже можете принудительно настроить прокси-сервер для IE и Google Chrome через групповую политику, если у вас есть домен ACtive Directory, и использовать автоконфигурацию прокси для посетителей / пользователей Mac / Linux / Firefox.