Выборочное использование прозрачного прокси на основе для каждого подключения
По моему опыту, прозрачное HTTP-проксирование обычно практически не влияет на сеансы пользователей.
Однако ваша стратегия и то, что вы на самом деле собираетесь выполнить, кажутся мне неясными. Я думаю, что реальность того, как работает HTTP, станет для вас проблемой. Возможно, вы сможете подробнее рассказать о том, чего вы действительно пытаетесь достичь с точки зрения конечного результата. Я не говорю, что это «ужасная идея», но совершенно неясно, что вы надеетесь получить.
С точки зрения протокола HTTP, ваша стратегия имеет серьезную проблему. Ваш брандмауэр уровня 7 по определению не может знать тип MIME запрашиваемого ресурса до тех пор, пока запрос не будет сделан. Вы можете выполнить сопоставление имени файла (увидеть его, если он оканчивается на «.html» и т. Д.), Но любой URL-адрес может возвращать произвольный тип MIME. Это . Файл b0rk - это text / html , но правило соответствия в вашем брандмауэре на .html или .htm этого не «знает». Запрос должен быть отправлен удаленному серверу, и удаленный сервер должен ответить до того, как станет известен тип MIME.
Почему вы предполагаете, что другие типы файлов (CSS, Javascript, изображения и т. Д.) Являются «статическими». Они определенно не должны быть такими. Объект, на который ссылается любой URL, может быть «динамическим».
Если вас беспокоят затраты на полосу пропускания, почему бы просто не разместить прозрачный прокси локально? Локальный прокси-сервер не будет подвергаться задержке в десятые доли секунды для запросов, попадающих на прокси, и у вас не будет потенциальных затрат на пропускную способность, связанных с отправкой всех ваших данных из стороннего центра обработки данных. Вы' Я также вижу некоторое улучшение использования вашей локальной пропускной способности, когда прокси-сервер кэширует объекты, и вы можете позволить ему кэшировать все (что это cna).
Я запустил образовательную сеть на 1000 мест через экземпляр Squid-cache, работающий на оборудовании, которое , сегодня казалось бы жалким. Если вы не говорите об очень, очень большой сети, очень скромная машина могла бы справиться с нагрузкой за вас. Если вас беспокоит единственная точка отказа, вы можете использовать протокол связи веб-кэша (WCCP), если ваше граничное устройство поддерживает его, для переключения между несколькими кэшами.
Если вы смотрите на это, чтобы сканировать HTML на предмет «вредоносного» кода, тогда я думаю, вы смотрите на него задом наперед. Я' я больше беспокоился о вредоносном коде в объектах Javascript и application / octet-stream , чем о объектах text / html . В любом случае, я сомневаюсь в том, чтобы сканировать, потому что все может быть достаточно запутано, чтобы проскочить сканирование (см. Проблема остановки ). Если вы не собираетесь использовать перехват SSL, вы также пропустите все, что доставляется по HTTPS. Сканирование может выявить известные эксплойты, и я действительно считаю это действительной частью архитектуры ИТ-безопасности, но нулевой день почти всегда ускользает.