У меня есть набор серверов Nginx за балансировщиком нагрузки Amazon ELB. Я использую set_real_ip (из HttpRealIpModule), чтобы я мог получить доступ к исходному IP-адресу клиента на этих серверах (для перехода к php-fpm и для использования в HttpGeoIPModule).
Кажется, что set_real_ip_from в конфигурации nginx может принимать только IP-адрес. Однако в отношении машин ELB Amazon заявляет:
Примечание. Поскольку набор IP-адресов, связанных с LoadBalancer, может меняться со временем, вам никогда не следует создавать запись «A» с каким-либо конкретным IP-адресом. Если вы хотите использовать понятное DNS-имя для LoadBalancer вместо имени, созданного службой Elastic Load Balancing, вам следует создать запись CNAME для DNS-имени LoadBalancer или использовать Amazon Route 53 для создания размещенной зоны. Дополнительные сведения см. В разделе Использование доменных имен с эластичной балансировкой нагрузки.
Но если мне нужно ввести IP-адрес, я не могу использовать CNAME (как Amazon, так и мой собственный). Есть решение этой проблемы?
Если вы можете гарантировать, что все запросы будут поступать из ELB (я с ним не знаком), вы можете попробовать:
real_ip_header X-Forwarded-For;
set_real_ip_from 0.0.0.0/0;
Это должно заставить nginx доверять заголовку X-Forwarded-For от кого угодно. Обратной стороной является то, что если кто-либо напрямую обращается к вашему серверу, он сможет подделать заголовок X-Forwarded-For, и nginx будет использовать неправильный IP-адрес клиента.
Сегодня лучше всего использовать VPC, чтобы вы знали точный CIDR для вашего ELB. Затем вы можете добавить что-то вроде этого в свой файл конфигурации Nginx:
real_ip_header X-Forwarded-For;
set_real_ip_from 10.0.0.0/8;
Используйте VPC CIDR для set_real_ip_from Вы можете найти его в консоли Amazon в разделе VPC => Your VPC (замените <your VPC CIDR here> с этим):
real_ip_header X-Forwarded-For;
set_real_ip_from <your VPC CIDR here>;
В realip_module заявляет, что в случае X-Forwarded-For этот модуль использует последний IP-адрес в заголовке X-Forwarded-For для замены. Этот модуль не будет работать, если только real_ip_header и set_real_ip_form установлены. Это связано с тем, что этот модуль будет использовать IP-адрес прокси вместо IP-адреса клиента. Чтобы решить эту проблему real_ip_recursive директива должна быть включена.
Кроме того, если у вас есть сертификаты SSL, которые развернуты и обновлены на экземпляре (например, сертификаты letsencrypt или certbot). Эти центры сертификации могут попытаться проверить эти сертификаты через IPV6.
Поэтому важно также иметь IPV6. Таким образом, конфигурационный файл Nginx также должен содержать адрес set_real_ip_from IPV6.
real_ip_header X-Forwarded-For;
real_ip_recursive on;
set_real_ip_from <your VPC IPV4 CIDR here>;
set_real_ip_from <your VPC IPV6 CIDR here>;
если применяются дополнительные ограничения безопасности, нам также может потребоваться включить set_real_ip_from VPC CIDR (IPV4 и IPV6) для подсетей cloudfront / elb / ec2.
Установка доверенного диапазона 0.0.0.0/0 на Amazon ELB наверняка доставит вам неприятности. Вы можете гарантировать, что запросы поступают от ELB, если вы можете настроить группу безопасности для своего сервера nginx, но оригинал запрос будет исходить из любого возможного источника (Amazon ELB - это общедоступные интерфейсы).
Простой тест покажет это:
curl --header "X-Forwarded-For: 1.2.3.4" "http://your-elb-dns-address/"
Журналы на вашем сервере nginx будут отображать 1.2.3.4 как настоящий IP-адрес, который является поддельным. Видеть Диапазон IP-адресов для внутреннего частного IP-адреса Amazon ELB для лучших ответов.