прокси pfSense + Nginx и реальный IP-адрес пользователя

Итак, у меня есть 1 сервер с pfSense и множество виртуальных серверов. Я использую функции восходящего потока Nginx для запуска нескольких веб-серверов на одном общедоступном IP-адресе. Конечно, мне нужно знать IP РЕАЛЬНЫХ пользователей, а не прокси Nginx, который равен 192.168.2.2, но после перехода на pfSense (недавно был простой потребительский маршрутизатор) веб-серверы не могут видеть IP реальных пользователей.

Я пытался изменить различные настройки в Системе / Дополнительно / Брандмауэр и NAT, например: Режим NAT Reflection для переадресации портов Включить автоматический исходящий NAT для отражения

Также в Firewall / NAT / Outbound пробовал каждый режим, ничего не помогло, все равно у каждого пользователя есть IP моего прокси-сервера.

Итак, как отключить маскарадинг или как передать реальный IP клиента.

Обновление

Хорошо, похоже, проблема связана с поддоменами, а не с доменами. Текущая ситуация:

Если клиент переходит на domain.com - все в порядке, внутренний сервер может видеть реальный IP-адрес клиента

Если клиент переходит на subdomain.domain.com - внутренний сервер видит IP-адрес прокси-сервера

Все домены A записи указывает на внешний IP-адрес, затем pfSense перенаправляет порт 80 на прокси, затем прокси в зависимости от домена перенаправляет на соответствующий внутренний сервер.

У меня есть 2 физических сервера, 1 - маршрутизатор pfSense и еще один с виртуальным ящиком, на котором запущено много виртуальных машин в этом примере 4 виртуальных машины

enter image description here

Еще одна интересная вещь, когда я пытаюсь достичь проблемного subdomain.domain1.com изнутри локальной сети, я получаю следующее:

enter image description here

Опять же, никаких проблем с domain1.com, domain2.com и так далее ...

0
27.08.2016, 13:57
2 ответа

В основном существует два способа переадресации портов: Первый - это то, что сейчас делает ваш pfSense («полный» NAT, conntrack в Linux): когда новое соединение инициируется клиентом, pfSense создает новое сопоставление в своей таблице NAT, заменяет исходный адрес своим собственным, при необходимости меняет исходный порт и отправляет измененный пакет на ваш веб-сервер. Ваш веб-сервер автоматически отправит свои ответы машине pfSense, которая затем может снова поменять поля местами и отправить пакет клиенту. Преимущество этого подхода в том, что вашему веб-серверу не нужно об этом знать, он просто работает. Насколько я помню, вы можете отключить это в pfSense, если переключите режим NAT на «AON» и отключите NAT для (webserverip, targetport).

Ваш потребительский маршрутизатор выполнил простую переадресацию портов (DNAT в Linux): по прибытии пакета он просто поменял местами адрес назначения и отправил пакет на ваш веб-сервер. Поскольку пакет теперь по-прежнему имеет реальный адрес отправителя, веб-сервер может видеть реальный адрес клиента. К сожалению, когда он отправляет ответ, он помещает свой собственный (частный) адрес в поле источника, которое маршрутизатор должен заменить на ваш общедоступный IP-адрес на выходе (SNAT в Linux). Поскольку веб-сервер напрямую адресует пакет клиенту, маршрутизатор может сделать это, только если он также является шлюзом по умолчанию! (или когда вы настраиваете довольно забавные политики маршрутизации на своем веб-сервере)

0
28.01.2020, 04:50

Итак, проблема была не в pfSense и не в прокси, проблема была в конкретной конфигурации бэкенд-сервера (зеленый квадрат). Я случайно отключил опцию "Use Client IP in Header", я был уверен, что она включена, я знаю об этой опции, так что это была неправильная конфигурация backend сервера. Бэкенд-сервер - это Litespeed.

0
28.01.2020, 04:50

Теги

Похожие вопросы