nginx, похоже, игнорирует proxy_bind.

Содержание

Вопрос или проблема
Ответ или решение
Теория
Пример
Применение на практике
Разбор возможных причин
Рекомендации

Вопрос или проблема

У меня есть сервер с двумя Ethernet-портами, один из которых с IP-адресом 192.168.x.y, а другой с другим IP-адресом. Сервер работает на Debian Bookworm и nginx 1.22.1. Вот моя конфигурация сайта nginx:

server {
        server_name <hostname>;

        listen 443 ssl;
        listen [::]:443 ssl;

        ssl_certificate <path to cert>
        ssl_certificate_key <path to key>

        location / {
                proxy_bind 192.168.x.y;
                proxy_pass http://192.168.x.y:<port>/;
                proxy_set_header X-Forwarded-For $remote_addr;
        }
}

proxy_bind установлен на 192.168.x.y, однако в логах сервиса, работающего на http://192.168.x.y:<port>/, указано, что соединения приходят с IP-адреса другого Ethernet-порта. Это проблема, потому что этот сервис настроен доверять X-Forwarded-For только от 192.168.x.y. Почему nginx игнорирует proxy_bind?

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

<wrong ip> - - [23/Jan/2025:20:42:22 +0000] "GET /index.html HTTP/1.0" 200 615 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:134.0) Gecko/20100101 Firefox/134.0" "<my laptop's ip>"

Нашел проблему — NAT в nftables менял IP-адрес. Почему, я не знаю, но так как мне нужен NAT только на одном интерфейсе, изменение

table ip nat {
  ...
  chain postrouting {
    type nat hook postrouting priority 100;
    masquerade
  }
}

на

table ip nat {
  ...
  chain postrouting {
    type nat hook postrouting priority 100;
    oif $wan masquerade
  }
}

не сломало никакой NAT, который мне действительно нужен, и исправило нежелательный NAT.

Ответ или решение

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

Теория

Начать следует с разъяснения того, как должна работать директива proxy_bind. В nginx она используется для указания IP-адреса, с которого сервер будет устанавливать связь с целевым ресурсом. Это особенно важно, когда сервер имеет несколько сетевых интерфейсов, и требуется направить исходящий трафик через конкретный интерфейс.

Когда proxy_bind не работает, как ожидается, это может быть вызвано несколькими факторами, такими как неправильные настройки самой nginx, сетевые конфигурации операционной системы или правила фаервола, например, через nftables.

Пример

Опишем ситуацию, представленную в вашем сценарии. У вас на сервере установлено два Ethernet порта с разными IP-адресами. Однако вы заметили, что сервис, расположенный по http://192.168.x.y:<port>/, получает соединения не с ожидаемого IP-адреса, а с адреса второго интерфейса. Это создает проблему, так как доверие к заголовку X-Forwarded-For предоставляется только от 192.168.x.y.

Вы воспроизвели проблему в контейнере nginx, который четко показал, что основной nginx-сервер использует «неверный» IP-адрес. Причиной данной проблемы оказалось поведение системы NAT в nftables, которая изменяла IP-адрес трафика.

Применение на практике

Для устранения проблемы необходимо модифицировать правила nftables. В частности, было замечено, что правило:

table ip nat {
  ...
  chain postrouting {
    type nat hook postrouting priority 100;
    masquerade
  }
}

Применяет маскарадинг ко всем исходящим подключениям, что приводит к изменению исходящего адреса. Для контроля над изменением IP-адреса нужно уточнить, на каких интерфейсах должен применяться NAT. Изменив правила на:

table ip nat {
  ...
  chain postrouting {
    type nat hook postrouting priority 100;
    oif $wan masquerade
  }
}

Вы ограничили действие маскарадинга только до интерфейсов, определенных переменной $wan, что впоследствии устранило непредвиденные изменения в IP-адресации трафика на уровне NAT.

Разбор возможных причин

Неправильная конфигурация nginx: Проверка конфигурационных файлов на наличие ошибок также важна. Директива proxy_bind должна быть прописана корректно и в нужных контекстах, например, внутри блока location.
Сетевые настройки ОС: Убедитесь, что IP-адрес, указанный в proxy_bind, действительно доступен и правильно настроен в системных сетевых интерфейсах.
Конфигурация фаервола и NAT: Как оказалось в описанном сценарии, правила фаервола могут неявно менять трафик, поэтому их проверка и модификация являются неотъемлемой частью решения.
Логирование и мониторинг: Анализ журналов может дать дополнительную информацию о том, как обрабатываются запросы и каким образом приложение взаимодействует с другими узлами сети.