Методы получения исходного IP-адреса клиента

В определенных ситуациях наши услуги требуют использования IP-адреса клиента для конкретных бизнес- или целей безопасности. Однако в обычном сценарии трафик проходит через несколько сетей, балансировщиков нагрузки или прокси-сервисов, прежде чем достигнуть фактического сервиса. На каждом уровне этого процесса оригинальный IP-адрес клиента может быть потерян, оставляя наш сервис только с IP-адресом предыдущей сети. Такой исход не является идеальным для нас.

Из-за сложности нашего технологического стека получение IP-адреса клиента требует использования различных методов, иногда в комбинации.

Управление IP-адресом клиента через NAT

В некоторых инфраструктурах IDC, созданных или арендованных пользователями, наши сервисы могут находиться в отдельной локальной сети за шлюзом. Когда клиенты пытаются подключиться к нашим сервисам из внешней сети, трафик проходит через шлюз.

Подобный сценарий может возникнуть при использовании облачных сервисов. Сеть VPC, предоставляемая публичными облачными платформами, функционирует как независимая локальная сеть, изолированная от других VPC и интернета. В результате требуется шлюз для обеспечения внешнего доступа в интернет и подключения к внешним сервисам.

Этот шлюз, который может быть маршрутизатором или устройством межсетевого экрана, обычно предоставляет услуги трансляции адресов DNAT (Destination NAT) для внутренних сервисов. Это подразумевает, что шлюз имеет один или несколько публичных IP-адресов и перенаправляет трафик с определенных портов публичного IP на определенные порты внутреннего IP. Шлюз управляет перенаправлением трафика и отображением портов. Однако из-за изменения исходного адреса в заголовке оригинального IP-пакета шлюзом, наши сервисы внутри внутренней сети могут идентифицировать только IP-адрес шлюза, а не фактический адрес клиента.

Исторически возможности DNAT, предоставляемые сетевыми устройствами или программным обеспечением, были относительно базовыми. Они работали в основном на уровне 3 и не обладали возможностями анализа и манипуляции более глубокими уровнями полезной нагрузки. Их основной целью было предоставление сервисов, и они не могли передавать IP-адрес клиента дальше. Кроме того, из-за ограничений производительности этих устройств или программного обеспечения существовали ограничения на количество активных соединений и максимальное количество новых соединений, которые они могли обрабатывать. Масштабирование без аппаратных обновлений часто было затруднено, что делало их менее адаптируемыми к динамичной среде сегодняшнего дня.

Для устранения этих ограничений мы обращаемся к балансировке нагрузки, которая обладает более продвинутыми возможностями управления трафиком.

IP-адрес клиента в балансировке нагрузки

В общем случае балансировка нагрузки в основном классифицируется на два типа в зависимости от их рабочего уровня: уровень 4 и уровень 7, соответствующие TCP-потокам данных и прикладному трафику (представленному HTTP), соответственно.

В отличие от IP-шлюзов, балансировка нагрузки не изменяет заголовок IP-пакета. На уровне IP-пакета она только выполняет прозрачное перенаправление. Следовательно, в отличие от ранее обсуждаемого DNAT, балансировка нагрузки обеспечивает правильную передачу исходного IP-адреса, содержащегося в IP-пакете, компонентам за балансировщиком нагрузки.

Для балансировки нагрузки уровня 4, после выполнения базового перенаправления трафика, последующие сервисы могут точно получить IP-адрес клиента без необходимости специальной обработки. В исключительных случаях можно использовать Proxy Protocol. Это подразумевает добавление нового раздела перед оригинальной полезной нагрузкой трафика, включающего IP-адрес клиента. Другие обратные прокси-серверы или сам сервис за балансировщиком нагрузки могут затем интерпретировать данные Proxy Protocol для получения IP-адреса клиента.

Для балансировки нагрузки уровня 7, она обладает более глубокими возможностями обработки трафика. Она может напрямую передавать исходный IP-адрес на уровне протокола HTTP. Распространенным подходом является использование HTTP-заголовка X-Forwarded-For. Компонент балансировки нагрузки извлекает исходный IP-адрес из IP-пакета трафика, затем анализирует и переписывает HTTP-запрос. Он вставляет новое поле XFF в заголовок запроса, включая значение IP-адреса клиента.

HTTPS представляет собой особую проблему из-за зашифрованной полезной нагрузки, что делает компонент балансировки нагрузки неспособным напрямую манипулировать его HTTP-заголовками. В таких ситуациях можно рассмотреть следующие подходы:

• Без специфических требований, можно рассматривать HTTPS-трафик как стандартный TLS-трафик и перенаправлять его напрямую на уровне 4. В этом сценарии IP-адрес клиента все еще может быть передан сервису за балансировщиком нагрузки через заголовок IP-пакета.

• Когда необходима функциональность уровня 7, размещение TLS-сертификата на компоненте балансировки нагрузки позволяет выполнить TLS-терминацию. Этот процесс включает удаление TLS-шифрования на уровне балансировки нагрузки, использование обычного HTTP в локальной сети за балансировщиком нагрузки или установление нового HTTPS-соединения с сервисом вместо прямого перенаправления. Это позволяет компоненту балансировки нагрузки снова обрабатывать оригинальный HTTP-трафик и продолжать передачу IP-адреса с использованием метода XFF.

Благодаря тонкой обработке трафика, балансировка нагрузки предлагает различные методы передачи IP-адреса клиента на серверную часть сервиса. Представительными реализациями компонентов балансировки нагрузки являются облачные сервисы ELB, аппаратные решения F5 BIG-IP, Linux Virtual Server (LVS) на основе ядра Linux и программное обеспечение на основе пользовательского ПО, такое как NGINX.

Передача IP-адреса клиента в сервисах CDN

Иногда мы используем сервисы CDN, предоставляемые публичными облачными платформами, чтобы ускорить доступ пользователей к нашим сервисам. Их функционирование похоже на обратный прокси-сервер уровня 7, но в более широком контексте CDN можно рассматривать как часть области балансировки нагрузки.

Сервисы CDN обычно предоставляют возможности TLS-терминации и могут включать IP-адрес клиента в HTTP-запросы, отправляемые на сервис. Например, сервис CDN AWS CloudFront поддерживает передачу IP-адреса клиента с использованием метода XFF, что похоже на подход, используемый в балансировке нагрузки уровня 7.

Использование API Gateway

Хотя компоненты балансировки нагрузки обычно предлагают базовые возможности управления трафиком, API, предоставляемые облачными или аппаратными балансировщиками нагрузки, могут быть сложными для согласования с нашими конкретными бизнес-потребностями. В таких сценариях мы обращаемся к более адаптируемым компонентам для применения индивидуальных стратегий к нашим сервисам. Здесь на помощь приходит API-шлюз, такой как Apache APISIX или API7 Enterprise.

APISIX и API7 Enterprise поддерживают Proxy Protocol, что позволяет извлекать IP-адрес клиента из балансировщика нагрузки.

Кроме того, они имеют плагин под названием "real-ip", аналогичный модулю ngx_http_realip_module в NGINX. Этот плагин извлекает IP-адрес клиента из источника и использует его для передачи и логирования вниз по потоку. Плагин real-ip в APISIX и API7 Enterprise расширяет функциональность, найденную в NGINX. Он позволяет динамически активировать или деактивировать функцию реального исходного IP-адреса и расширяет источники IP-адресов клиента за пределы ограничений ngx_http_realip_module, который ограничен HTTP-заголовками и Proxy Protocol. Он может использовать любую переменную NGINX или APISIX, такую как параметры запроса или поля POST-формы.

Резюме

Используя комбинацию технологий на разных уровнях, мы можем эффективно передавать IP-адрес клиента через каждый компонент сервиса, удовлетворяя как бизнес-потребности, так и требования безопасности.

Чтобы узнать больше о решениях для управления API, свяжитесь с API7.ai.