Глубокое погружение в то, что такое Forward Proxy
January 12, 2024
Мы часто используем NGINX или Apache в качестве балансировщиков нагрузки и обратных прокси-серверов, даже когда внешний сетевой трафик перенаправляется через это программное обеспечение для доступа к реальным сервисам внутри внутренней сети. Хотя существует обратный прокси, также существует и прямой прокси. Давайте углубимся в их функциональность.
От модели OSI к прокси-серверам
При доступе к интернет-сервисам мы обычно используем протокол HTTP, который работает на 7-м уровне модели OSI. Знакомые компоненты этого протокола, такие как имена хостов, пути и параметры запроса, являются частью этого уровня. Протокол HTTP построен на основе протоколов TCP или UDP, которые функционируют на 4-м уровне модели OSI, и концепции портов, используемых при доступе к сервисам, существуют в рамках этих протоколов. Далее, как TCP, так и UDP основаны на Интернет-протоколе (IP), который работает на 3-м уровне модели OSI, где IP-адреса служат "адресами домов" в интернете.
При использовании IP-сети для доступа к интернету, IP-протокол отвечает за адресацию цели, инкапсуляцию пакетов данных в соответствии с правилами и их пересылку с исходного адреса на адрес назначения в пределах IP-сети. Например, сетевой трафик перемещается из локальной сети посетителя через шлюзовое устройство, предоставленное провайдером интернет-услуг (ISP), подключаясь к сети ISP перед доступом к сервисам поставщика ресурсов.
На этом этапе мы используем шлюз для доступа к интернету. Когда мы говорим о прокси-серверах, можно провести параллель с IP-сетью. Прокси-серверы действуют как шлюзы, заполняя разрыв, чтобы помочь клиентам получить доступ к сервисам. По сути, они работают между 4-м и 7-м уровнями модели OSI, и действительно, они относятся к 5-му уровню модели OSI.
Цели прокси-серверов
Прокси-серверы обычно используются для следующих целей:
- Централизованный выход для доступа из внутренней сети
Компании часто имеют определенные требования к информационной безопасности, такие как контроль доступа и журналирование трафика. С распространением зашифрованного трафика, такого как HTTPS, скрытие сетевого трафика под паролями затрудняет запись и аудит на границе сети, увеличивая риск утечек. Существование прокси-сервера служит единым выходом для трафика, выступая в качестве посредника для обработки задач аудита трафика.
Помимо целей, ориентированных на человека, прокси-сервисы также могут служить выходом для программных сервисов, обращающихся к внешней сети. Например, когда поставщик услуг предлагает функциональность вебхуков, ему необходимо направлять трафик через фиксированный выход, используя один фиксированный IP-адрес или диапазон фиксированных IP-адресов. Это облегчает получателю вызовов вебхуков правильное добавление их в белый список в брандмауэре. Невыполнение этого подвергает обе стороны вызовов вебхуков потенциальным рискам безопасности.
- Сокрытие личности посетителя
Иногда пользователи интернета могут желать скрыть свою личность, например, свой IP-адрес. В таких случаях вступают в действие прозрачные прокси-серверы. Клиент сначала подключается к прокси-серверу, указывая реальный адрес сервиса для подключения, а затем получает доступ к целевому сервису через прокси-сервер с использованием протокола HTTPS. Наличие прокси-сервера гарантирует, что личность клиента остается скрытой, а использование зашифрованного протокола гарантирует, что прокси-сервер не может украсть данные в этом процессе.
HTTP-прокси
На прокси-серверах мы обычно сталкиваемся с HTTP-прокси на основе HTTP и бинарным протоколом SOCKS 4/5. Они выполняют схожие функции, но с разными методами реализации. Давайте сосредоточимся на HTTP-прокси.
На ранних этапах реализации протокола трафик на HTTP был в основном открытым текстом. Эта прозрачность позволяла прокси-серверам, находящимся между клиентом и сервисом, легко анализировать URL-адреса и полезную нагрузку запросов. Через DNS-разрешение и подобные процессы прокси мог подключаться к сервису, используя свой собственный сетевой адрес, тем самым скрывая клиента.
Пример такого вызова выглядит следующим образом:
GET http://example.com/resource HTTP/1.1 Proxy-Authorization: Basic encoded-credentials
Прокси-сервер понимает адрес, к которому пытается получить доступ клиент, и отправляет запрос на сервис для получения ответа, который затем возвращается клиенту.
HTTP/1.1 200 OK Content-Type: text/html ... body blahblah ...
Это представляет собой простейшую форму реализации HTTP-прокси-сервера. Однако мы наблюдаем недостатки: прокси-сервер обрабатывает трафик клиента в открытом тексте, что представляет потенциальный риск безопасности, так как он может записывать трафик пользователя при пересылке. Поэтому необходимо рассмотреть методы шифрования для обеспечения безопасности.
Сложная работа HTTPS-трафика и прокси-серверов
С увеличением доли зашифрованного HTTPS-трафика в общем HTTP-трафике прокси-серверы должны адаптироваться к этому сценарию.
Однако возникает проблема: трафик, отправляемый клиентом поставщику услуг, теперь зашифрован. Прокси-сервер не может понять, к какому ресурсу клиент получает доступ через расшифровку. Это связано с тем, что трафик защищен механизмом согласования ключей на основе алгоритмов асимметричного шифрования между клиентом и поставщиком услуг, и последующий зашифрованный трафик использует симметричные ключи, которые не могут быть получены человеком посередине во время общения. Основная цель TLS — предотвратить возможность атак "человек посередине".
Итак, как работает прокси-сервер в этом случае?
Это более сложно по сравнению с предыдущим методом анализа запросов в открытом тексте. Протокол HTTP ввел специальный метод запроса CONNECT. Клиент использует этот метод для отправки начального запроса на прокси-сервер:
CONNECT server.example.com:80 HTTP/1.1 Host: server.example.com:80 Proxy-Authorization: Basic encoded-credentials
Клиент отправляет запрос CONNECT на прокси-сервер, включая домен или IP-адрес и порт, к которым клиент хочет подключиться. Получив запрос, прокси-сервер устанавливает TCP-соединение с целевым сервисом и сохраняет отображение портов между клиентом и сервисом. Впоследствии клиент может отправлять правильные запросы на прокси-сервер, который будет пересылать трафик на сервис как есть, не пытаясь анализировать данные. Следовательно, зашифрованная связь HTTPS является надежной.
Этот механизм, по сравнению с прокси-серверами HTTP в открытом тексте, более универсален. Как только первый HTTP-запрос информирует прокси-сервер о информации для установления соединения, он по сути становится прозрачным прокси-каналом. Он может облегчить связь как для HTTPS, так и для бинарного TCP-трафика (например, SSH) через прокси-сервер.