We can define a transparent proxy as a server that acts as an intermediary system intercepting the connection between an end-user and a content provider. Other names for transparent proxy are inline proxy or forced proxy. We use the word ‘transparent’ with the proxy because it intercepts requests by intercepting packets directed to the destination
Мы можем определить прозрачный прокси как сервер, который выступает в качестве системы-посредника, перехватывающей соединение между конечным пользователем и поставщиком контента. Другие названия прозрачного прокси - встроенный прокси или принудительный прокси. Мы используем слово "прозрачный" в отношении прокси, потому что он перехватывает запросы, перехватывая пакеты, направленные к месту назначения, создавая впечатление, что место назначения само обрабатывает запрос. Прозрачные прокси настраиваются веб-сайтом или оператором сети, а не конечным пользователем.
Иногда мы также используем термин "принудительный прокси" для обозначения прозрачного прокси. Это связано с тем, что он может быть применен к подключению пользователя без изменения настроек прокси на его компьютере. Следовательно, прозрачные прокси могут быть навязаны пользователям без их согласия, но во многих случаях они знают о своем присутствии.
Брандмауэр - это пример прозрачного прокси-сервера, который разрешает прохождение трафика между внутренней сетью и Интернетом, но блокирует его, если он нарушает таблицу правил брандмауэра.
Другими примерами прозрачных прокси являются сети доставки контента (CDN). Они обеспечивают избыточность, кэширование и повышают скорость работы, не изменяя и не раскрывая исходную систему. Пользователь думает, что он напрямую подключен к поставщику услуг, но на самом деле все его запросы обрабатывает CDN. Именно так такие технологические компании, как Google, Twitter и Facebook, управляют миллионами запросов с минимальным временем простоя.
Ниже приведены стандартные настройки прозрачного прокси при его настройке:
Мы можем развернуть прозрачный прокси на стороне клиента, что означает, что прокси перехватывает весь трафик, идущий к конечной точке клиента и обратно. Прозрачные прокси на стороне клиента могут использоваться следующим образом:
Когда несколько человек получают доступ к одному и тому же контенту из одной и той же области или места - например, когда несколько студентов просматривают один и тот же новостной сайт через университетскую сеть, - то эффективнее использовать прозрачный прокси-сервер для первоначального кэширования контента и его обслуживания из кэша последующими пользователями.
Операторы сотового интернета и публичные точки Wi-Fi иногда используют прозрачные прокси-серверы, заставляя пользователей аутентифицироваться в сети и соглашаться с условиями предоставления услуг. Серфинг разрешается только после того, как пользователь подтвердит свою подлинность и согласится с условиями.
Большинство пользователей даже не подозревают, что все соединение может быть перехвачено и проконтролировано оператором даже после начального экрана аутентификации через прозрачный прокси.
При эксплуатации сети мы можем установить прозрачный прокси-сервер для мониторинга трафика и поведения пользователей, но мониторинг трафика имеет и множество незаконных применений. Например, недобросовестный и ненадежный оператор публичной сети Wi-Fi может легко отслеживать подключения пользователей и красть учетные данные и информацию.
Мы можем использовать шлюзовой прокси для изменения или блокирования сетевого трафика на основе правил. Примером шлюзового прокси является прозрачный прокси брандмауэра, рассмотренный в примере выше.
Мы также можем использовать прозрачный прокси для фильтрации ненужного и нежелательного контента. Например, прокси может не пересылать запрос на веб-сервер, когда запрашивается определенный сайт. Вместо этого он перехватывает соединение и выводит пользователю уведомление или сообщение об ошибке.
Защитить сервер от атаки типа SYN-flood Denial of Service (DoS) можно с помощью одного из видов прозрачного прокси - TCP-перехвата. Он выполняет функцию перехвата всего трафика веб-сервера, принимает клиентские запросы и выполняет трехстороннее рукопожатие. Кроме того, в случае успешного перехвата трафика он выполняет трехстороннее рукопожатие с сервером, тем самым соединяя два полусоединения между клиентом и сервером.
Перехватчик протокола управления передачей проверяет запросы TCP и обычно ждет 30 секунд, чтобы установить соединение. Он переходит в "агрессивный режим", когда количество неактивных соединений превышает определенный порог. В этом режиме каждое новое прибывающее соединение приводит к удалению самого старого пассивного соединения.
Однако вышеописанная техника уже неэффективна против современных масштабных распределенных атак типа "отказ в обслуживании" (DDoS). Это связано с тем, что в настоящее время злоумышленники контролируют миллионы компьютеров-зомби и мощных серверов для создания SYN-флуда, подавляющего контроллер перехвата TCP.
По этой причине большинство организаций сегодня используют облачные сервисы, такие как Imperva DDoS Protection. Эти сервисы способны защитить от крупных DDoS-атак, а также масштабироваться по требованию, что позволяет справляться с масштабными атаками.
Например, службы DDoS могут предотвращать атаки на уровне приложений и протокольные атаки, которые происходят не на уровне TCP.
Мы можем определить сеть доставки контента (CDN) как глобально распределенную сеть прокси-серверов, которая обслуживает и кэширует контент для пользователей вблизи их географического местоположения.
Примером CDN может служить глобальная сеть доставки контента Imperva - прозрачный прокси-сервер, работающий на стороне сервера. Его задача - выполнять внешнюю оптимизацию для улучшения качества работы конечного пользователя. Он перехватывает трафик веб-сервера и предлагает тот же контент из кэша сервера вместо того, чтобы давать пользователю прямой доступ к серверу. В результате повышается производительность пользователя и снижается потребление системных ресурсов сервера.
Несмотря на то, что прозрачные прокси имеют целый ряд преимуществ, в сложных корпоративных средах они могут вызывать некоторые разочарования.
Отсутствие надежности: Если между клиентом и кэшем устанавливается соединение, а затем происходит изменение маршрутизации, в результате которого клиент переходит на путь, который больше не проходит через "отводящее" сетевое устройство, сессия обрывается, и пользователю приходится перезагружать страницу.
С другой стороны, если маршрутизаторы в Интернете работают по принципу flapping (маршрутизатор попеременно рекламирует сеть назначения в быстрой последовательности), то результаты будут еще более непредсказуемыми.
Зависимость от браузера: Большинство прозрачных прокси полагаются на то, что браузер для успешной работы будет указывать имя хоста сервера-оригинала в заголовке HTTP-запроса.
Это необходимо, поскольку эти кэши не имеют доступа к IP-адресу назначения исходного сервера из IP-адреса пакета.
Поэтому, когда происходит пропуск кэша, они не могут определить адрес исходного сервера, на который следует отправить запрос.
Мы обсудили, что интернет-трафик можно отслеживать и фильтровать с помощью прозрачного прокси. Он также определяет способы взаимодействия с Интернетом. Будь то ускоренная передача данных за счет фильтрации нежелательного контента, кэширование или предоставление предприятиям большего контроля над своими сетями, прозрачный прокси добавляет функциональность Интернету без каких-либо неудобств.