Мой сервер Apache находится за брандмауэром с трансляцией NAT. Проблема в том, что я хочу видеть, кто на самом деле делает запрос, а не адрес моего брандмауэра. Приятно знать, что брандмауэр работает, но для того, чтобы действительно взглянуть на шаблоны трафика, мне нужно увидеть реальный IP-адрес.
ОБНОВИТЬ
Брандмауэр - это ящик CentOS 5.2, использующий правила iptable, созданные fwbuilder.
iptables отвечает на запросы на всех интерфейсах, Squid работает только на внутренних интерфейсах.
Я видел это с прокси-серверами и балансировщиками нагрузки. Обычно входящий трафик проходит через прокси-сервер, чтобы попасть на веб-сервер, но шлюзом по умолчанию для веб-сервера является нечто иное, чем прокси. Выполняя обратный NAT, веб-сервер получает IP прокси вместо клиента. Поскольку у него будет маршрут к прокси (и на самом деле он, вероятно, находится в той же подсети), он всегда может получить ответный трафик обратно клиенту.
Одно из исправлений заключается в том, что прокси-сервер вставляет настраиваемый HTTP-заголовок, содержащий реальный IP-адрес клиента, в HTTP-запрос, который веб-сервер может проанализировать. Для Apache это становится простой проблемой изменения вашего LogFormat заявление об использовании %{Custom-Header} вместо того %h. Конечно, это зависит от того, действительно ли ваше устройство поддерживает HTTP и может вставлять произвольные заголовки в GET / POST и т. Д. Запросы. Это обычная функция для прокси и балансировщиков нагрузки, но не для брандмауэров. Кроме того, если ваше устройство не выполняет завершение SSL, это не поможет вам для запросов HTTPS. Как сказал Кайл, нам нужно больше узнать о вашем брандмауэре.
Я думаю, что чаще всего с NAT в этом случае используется только NAT для адреса назначения. Следовательно, клиенты по-прежнему будут иметь тот же исходный адрес (общедоступный IP-адрес). Поэтому я думаю, нам нужно больше узнать о брандмауэре.
Так например:
Client: 12.12.12.12
Public Website Address: 11.11.11.11
Private Web Server ip: 10.0.0.2
Client --> Your Firewall --> Web Server
Client Packet:
Src IP:12.12.12.12
Dst IP:11.11.11.11
NAT Firewall:
Takes client Packet, changes Dst from 11.11.11.11 to 10.0.0.2.
Make entry in table to remember this mapping
Web Server (When Client Packet Arrives):
Src:12.12.12.12
Dst: 10.0.0.2
Reply Packet from Web Server:
Src: 10.0.0.2
Dst: 12.12.12.12
NAT Firewall:
Takes Reply Packet, changes Src to 11.11.11.11 after looking at mapping
Client (When Packet Arives):
Src: 11.11.11.11
Dst: 12.12.12.12
Скорее всего, клиент также находится за NAT, но это только усложняет задачу.
Судя по тому, как вы это описываете, этот «брандмауэр» больше похож на обратный прокси.
NAT обычно применяется к исходящим соединениям, а не к входящим. Когда компьютер в частной сети открывает соединение с внешним миром, удаленный сервер видит соединение как исходящее с публичного IP-адреса брандмауэра; но когда удаленный компьютер открывает соединение с одним из ваших внутренних серверов (через переадресацию портов на брандмауэре), он видит соединение как исходящее с фактического общедоступного IP-адреса, с которого оно исходит. Вы описываете типичное поведение обратного прокси, а не межсетевого экрана NAT.
Вы уверены, что на этом брандмауэре не работает обратный прокси (например, SQUID) и не перехватывает входящие HTTP (S) соединения? SQUID также может действовать как прозрачный прокси, поэтому он может быть там, даже если вы об этом не знаете. Это также будет стандартным поведением ISA Server при публикации внутреннего веб-сайта: даже если вы думаете, что просто выполняете переадресацию портов, на самом деле вы выполняете обратное проксирование своего веб-сервера.
Если у вас в миксе есть squid, вам следует искать заголовок X-Forwarded-For, который был реализован специально с целью передачи этой информации вперед.
Обратите внимание, что этот заголовок по крайней мере так же небезопасен, как и использование исходного IP-адреса, поскольку оба могут быть подделаны.
Вы можете проверить, так ли это, изменив свой LogFormat, заменив% h на% {X-Forwarded-For} i, а затем перезагрузив конфигурацию.
Если вы видите локальный IP-адрес в журналах, также проверьте пользовательский агент рядом с ним; если это "PageSpeed", то должно быть хорошо чтобы показать локальный IP для этих запросов.