Вопрос или проблема
Ситуация: у меня есть домен, скажем, mydomain.com.
На сервере в моей локальной сети работают несколько служб, включая Nginx Proxy Manager.
В NPM я настроил различные хосты, такие как service1.mydomain.com, service2.mydomain.com и так далее.
Все эти службы общедоступны. Я могу получить доступ к service1.mydomain.com как изнутри, так и снаружи моей сети.
На моем собственном DNS-сервере я создал A-запись для *.mydomain.com, указывающую на NGINX, чтобы я мог получить доступ ко всем своим службам внутри своей сети с использованием их FQDN.
Одна из служб, скажем, service3.mydomain.com, немного более чувствительна. Поэтому я разместил список доступа под названием “Только LAN”, который разрешает только адреса RFC1918.
И вот где происходит сбой: когда этот список доступа активен на service3.mydomain.com, я получаю 403 запрещено, даже когда получаю доступ к ресурсу из своей сети.
Смотрим на журнал доступа NPM:
[error] 10010#10010: *2988 доступ запрещён по правилу, клиент: {МОЙ ПУБЛИЧНЫЙ IP}, сервер: service3.mydomain.com, запрос: "GET / HTTP/2.0", хост: "service3.mydomain.com", реферер: "https://{ЧАСТНЫЙ IP}:{PORT}/"
Итак, я обращаюсь к внутренним ресурсам из локальной сети с моих публичных IP-адресов. Почему это происходит?
Это не проблема DNS, учитывая, что запрос dig service3.mydomain.com возвращает правильную локальную A-запись с частным IP, и я могу успешно его пинговать.
Может быть, будет полезно знать: если я отключу кабель от моего провайдера, я все равно смогу получить доступ ко всем своим службам без проблем. И те, с “Только LAN” ACL теперь работают, поскольку журналы подтверждают, что я обращаюсь к ним с моего частного клиентского IP. Мой браузер не использует DNS через TLS или HTTPS, он просто использует DNS-резолверы хоста.
Nginx Proxy Manager старается изо всех сил, чтобы сохранить исходный адрес, даже через IPv4 NAT.
Посмотрите конфигурационные файлы. Допустим, я нашёл представительный nginx.conf, он имеет set_real_ip_from для всех адресов RFC 1918. Внутри nginx вы больше не работаете с внутренним адресом.
Совершенно внутренней службе не нужно проходить через прокси на границе интернета. Вы можете выбрать, чтобы не использовать прокси и сделать так, чтобы service3 разрешался на бэкенд-хост. Или вы можете использовать прокси, но изменить конфигурацию так, чтобы использовать сеть, которая не находится в реальных диапазонах IP.
Ответ или решение
Почему внутренние ресурсы, доступные через NPM, приходят с моего публичного IP-адреса?
Ваша ситуация демонстрирует распространенную ошибку конфигурации, связанная с доступом к локальным сервисам через обратный прокси-сервер Nginx Proxy Manager (NPM). Давайте подробно разберем основные причины, по которым вы сталкиваетесь с этой проблемой.
1. Проблема маршрутизации
Когда вы находитесь в локальной сети и пытаетесь получить доступ к сервису, используя его FQDN, DNS-сервер правильно разрешает имя в локальный адрес. Однако, поскольку ваши запросы проходят через Nginx Proxy Manager, система видит их как внешние, если они не правильно настроены для обработки внутреннего трафика.
Ваша конфигурация NPM может не распознавать запросы как исходящие с локальной сети, если не настроены соответствующие параметры для реальной IP-адресации. Это означает, что при использовании NPM доступ к сервису всё равно идет как через интернет, что и приводит к тому, что NPM «видит» вас как клиент с публичным IP-адресом.
2. Реальная IP-адресация
Как вы упомянули, NPM использует директиву set_real_ip_from для определения реальных IP-адресов клиентов (RFC 1918). Однако, если эта настройка не охватывает вашу локальную сеть или неправильно настроена, запросы, исходящие из вашей сети, будут демонстрировать публичный IP-адрес.
Для решения этой проблемы вам следует убедиться в следующем:
-
Проверьте, настроены ли ваши подсети и собственный локальный IP-адрес в директиве
set_real_ip_from. Он должен охватывать диапазон ваших локальных IP-адресов (например, 192.168.0.0/16 для частных адресов). -
Убедитесь, что на конфигурацию не влияют другие правила, например, NAT, которые могут изменять внешний вид пакетов.
3. Настройка ACL в NPM
Вы также упомянули, что на сервисе service3.mydomain.com включен список доступа "LAN Only", разрешающий доступ только для внутренней сети. Если NPM не правильно распознает ваш внутренний IP-адрес и принимает его за публичный, это может приводить к ошибке 403 «доступ запрещен». Храните порядок в правилах ACL и изменения настройках.
На этом этапе, если сконфигурированная ACL не позволяет доступ с вашего публичного IP, пространство для улучшения очевидно.
4. Использование локальных IP-адресов
При отключении Ethernet-кабеля от вашего провайдера, доступ к службам возвращается к нормальному состоянию, и вы можете получить доступ к service3.mydomain.com как ожидается. Это подтверждает, что проблема заключается именно в конфигурации обработки запросов через NPM, а не в DNS или сетевом подключении.
5. Опции для исправления
-
Настройка прокси: Вы можете попробовать использовать альтернативные подходы, например, оставлять некоторые сервисы без прокси, чтобы они были доступны на внутренних IP-адресах напрямую.
-
Изменение конфигурации: При необходимости пересмотрите параметры NPM и ваш локальный маршрутизатор. Вам может потребоваться изменить способ управления трафиком между сетью.
-
Тестирование: Проведите тесты, отключив временную доступность через прокси или полностью проверив обстановку с вашей локальной сетью.
Заключение
Проблема доступа к внутренним ресурсам через публичный IP адрес связана с конфигурацией вашего Nginx Proxy Manager и маршрутизацией на вашем локальном оборудовании. Убедитесь, что все правила установлены правильно, и проводите регулярные проверки, чтобы избежать подобного поведения. Надеюсь, данная информация была полезна и поможет вам устранить возникшую проблему.