88. Доменные имена в домашней сети. Nginx proxy manager
Создание собственной доменной зоны и управление доменными именами даёт полную свободу в выборе имен и полный контроль над вашей сетевой экосистемой. Именно здесь на помощь приходит связка из Nginx Proxy Manager и уже знакомого из предыдущей статьи Pi-Hole.
Тот самый Pi-Hole, конечно же должен быть настроен со статическим айпи адресом, и конечно же прописан в конфигурации раутера, в качестве DNS сервера для всей локальной сети. Тогда все устройства и сервисы будут обращаться к нему для получения соответствия имён и айпи адресов.
NPM (Nginx Proxy Manager) - будет инструментом, который перераспределяет трафик на разные сокеты. Или говоря профессиональным языком - обратный прокси (reverse proxy). Он, как и любой другой сервер в сети, должен иметь статический адрес.
Теоретическая часть.
- DNS сервер позволяет выставить соответствие между айпи адресом и доменным именем.
При использовании днс сервера, запрос перенаправляется на тот хост, к которому привязано имя. Но если у сервис, работающий на этом хосте, использует нестандартный веб порт (не 80 или не 443), то для соединения с этим сервисом, номер порта нужно будет обязательно указать после доменного имени.
- Reverse proxy перенаправляет соединение на конкретный порт указанного айпи, к которому привязано доменное имя.
Т.е. если в домашней сети имеются сервисы, доступ к которым происходит не по стандартным HTTP или HTTPS протоколам, а необходимо указывать какой-то свой порт, то связка DNS + Reverse proxy решает эту проблему.
Сколько бы ни было в сети сервисов и на каких бы адресах они не находились, для каждого из них можно создать произвольное доменное имя и в качестве его конечной точки для DNS резолвинга указать адрес обратного прокси.
В свою очередь, на уровне обратного прокси создать соответствие доменного имени и реального сокета.
Это позволит использовать стандартные HTTP или HTTPS протоколы при обращении к сервису, проще говоря не указывать номер порта после доменного имени.
По сути, обратный прокси позволяет иметь красивые адреса для сервисов внутри сети, не меняя их внутренние настройки IP и портов, и централизованно управлять доступом к ним.
Кроме того, обеспечивается шифрование трафика, даже внутри вашей домашней сети с помощью SSL сертификатов.
Зачем?
- Конфиденциальность: Данные, передаваемые по Wi-Fi без шифрования (по HTTP), могут быть перехвачены. Это касается паролей, личных сообщений и другой чувствительной информации. HTTPS шифрует эти данные.
- Совместимость с браузерами: Современные браузеры всё активнее настаивают на использовании HTTPS и могут показывать предупреждения или блокировать некоторые функции на HTTP-сайтах.
- Хорошая практика: Вы привыкаете к безопасным конфигурациям.
- Требования приложений: Некоторые приложения или их функции могут работать некорректно или вообще не работать без HTTPS.
Важное замечание о шифровании:
Два этапа 🔒⬅️➡️🔒⬅️➡️ 🔒... или 🔒⬅️➡️🔒⬅️➡️🔓
После настройки HTTPS для локального сервиса, важно понимать, какая именно часть пути шифруется.
Как работает шифрование в связке:
Клиент (браузер) ↔ Nginx Proxy Manager (NPM):
- Соединение защищено по HTTPS (TLS/SSL) с валидным сертификатом.
- Браузер видит "зеленый замочек", трафик шифруется. Это решает проблему предупреждений и обеспечивает конфиденциальность на пути до NPM.
Nginx Proxy Manager (NPM) ↔ Целевой сервис (Plex, Home Assistant и т.д.):
- По умолчанию, соединение обычно НЕ шифруется (http). NPM выступает как "доверенный посредник" внутри вашей предположительно безопасной локальной сети.
- NPM получает запрос от клиента по HTTPS, "расшифровывает" его, понимает, куда нужно обратиться (например, к 192.168.1.25:8096), и создает новый HTTP-запрос к этому внутреннему сервису.
- Ответ от сервиса NPM получает по HTTP, затем заново шифрует его и отправляет обратно клиенту по HTTPS.
Почему так происходит (и почему это часто приемлемо дома):
- Производительность: Шифрование/расшифровка трафика — ресурсоёмкая операция. Передача данных внутри локальной сети по HTTP обычно происходит очень быстро и без нагрузки на CPU сервисов.
- Простота настройки: Многие внутренние сервисы (особенно в контейнерах или на виртуальных машинах) не имеют встроенного HTTPS или требуют сложной настройки собственных сертификатов. NPM берет эту задачу на себя.
- Доверенная среда: В идеале, ваша домашняя сеть — это контролируемая среда. Риск перехвата трафика между NPM и сервисом (например, злоумышленником внутри вашей Wi-Fi сети) считается низким по сравнению с риском в открытом интернете. Хотя это предположение не всегда верно на 100%!
- Централизованное управление сертификатами: NPM легко управляет SSL для всех ваших доменов в одном месте. Обновлять сертификат нужно только на NPM, а не на каждом сервисе.
Когда и зачем шифровать трафик "до конца" (NPM ↔ Сервис)?
Повышенные требования к безопасности:
- Если вы обрабатываете очень конфиденциальные данные (пароли, финансы, личные документы) даже внутри сети.
- Если вы не доверяете всем устройствам в своей локальной сети (например, есть гостевой Wi-Fi без изоляции).
- Если ваш сервис доступен из интернета через NPM. Шифрование до сервиса добавляет еще один рубеж защиты.
Требования самого сервиса:
Некоторые современные сервисы (особенно веб-приложения) могут требовать HTTPS-соединения для корректной работы определенных функций (например, Service Workers, Geolocation API).
Как реализовать сквозное шифрование (End-to-End HTTPS)?
Вариант 1. Настроить HTTPS на самом целевом сервисе:
- Установить на сервис валидный или самоподписанный сертификат.
- Scheme: https
- Forward Hostname/IP: IP или домен сервиса (если у него есть свой DNS)
- Forward Port: Порт HTTPS сервиса (обычно 443).
Плюсы: Максимальная безопасность.
Минусы: Сложнее настраивать и обновлять сертификаты на каждом сервисе. Самоподписанные сертификаты на сервисах могут требовать дополнительных действий (добавление в доверенные в системе или браузере).
Вариант 2. Использовать HTTPS в NPM с игнорированием ошибок сертификата (не рекомендуется для безопасности):
- В NPM указать Scheme: https.
- На вкладке SSL -> Advanced добавить директиву: proxy_ssl_verify off; (Это отключает проверку валидности сертификата целевого сервиса NPM'ом).
Плюсы: Простота, трафик формально идет по HTTPS.
Минусы: Опасный подход! Трафик шифруется, но NPM не проверяет подлинность сервиса. Вы уязвимы к атакам MITM (Man-in-the-Middle) внутри вашей сети, если злоумышленник подменит IP или порт вашего сервиса. Используйте только если полностью доверяете сети и понимаете риски!
Вараинт 3. Туннелирование (stunnel, haproxy) или VPN:
- Поставить между NPM и сервисом еще один легкий прокси (например, stunnel), который будет шифровать трафик на последнем участке.
Минусы: Значительное усложнение архитектуры и настройки.
Итог и рекомендации:
Стандартная схема (NPM: HTTPS -> Сервис: HTTP): Идеально подходит для большинства домашних лабораторий. Она дает удобство, централизованное управление SSL и решает главную проблему — предупреждения браузера и базовое шифрование до "входа" в вашу инфраструктуру. Риски внутри доверенной локальной сети обычно минимальны.
Сквозное шифрование (NPM: HTTPS -> Сервис: HTTPS): Нужно для сервисов с критически важными данными или доступных из интернета. Требует дополнительных усилий по настройке и поддержке HTTPS на каждом сервисе.
Никогда не используйте proxy_ssl_verify off; без крайней необходимости — это создает ложное чувство безопасности.
Практика.
Т.к. описание установки ДНС сервиса в виде Pi-Hole уже было упомянуто в отдельной статье, то перейдём к установке обратного прокси в виде Nginx Proxy Manager.
На сайте Community Scripts есть страничка посвящённая этой установке. Мы же возьмём оттуда только команду для установки LXC контейнера для Proxmox.
bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/nginxproxymanager.sh)"
Она создаст контейнер с двухъядерным процессором, 1 Гб оперативной памяти и диском на 4 Гб.
Юзер и пароль по умолчанию:
admin@example.com
changeme
Излишне говорить что как минимум пароль стоит сменить на новый и сохранить его.
После того как контейнер создан и настроен (ему назначен статический адрес), можно переходить к конфигурации.
В интерфейсе NPM жмём на Proxy Hosts
и там на Add Proxy Host.
Допустим мы хотим сделать подключение к Home Assistant (который в домашней сети имеет сокет со статичным айпи 192.168.1.28:8123) с использованием доменного имени ha.lab
- тогда в Domain Names указываем доменное имя по которому хотим к нему обращаться - ha.lab
- Scheme оставляем http если в самом ХА не настроен самоподписанный сертификат. Соответственно, если сертификат установлен то, выбираем https.
- Forward Hostname / IP - собственно реальный айпи сервера 192.168.1.28
- Port - тот самый 8123
- желательно включить поддержку Websockets
Сохраняемся, запись готова. Половина дела сделана.
Теперь топаем в интерфейс ДНС сервера где переходим в System -> Settings -> Local DNS Records
В поле домена указываем всё то же доменное имя, по которорму хотим попадать в ХА (ha.lab), а в качестве айпи адреса указываем адрес обратного прокси и плюсуем.
Т.к. браузер не "знает" о существовании такого частного домена, то для первого захода по только что созданному адресу, необходимо в адресной строке указать и протокол соединения. Опять таки в зависимости от того, что было настроено в обратном прокси http://ha.lab или же https://ha.lab. Это необходимо для того, чтобы браузер запомнил этот адрес, а не начал искать это сочетание букв (ha.lab) в поисковике.
Применение сертификатов.
Допустим что благодаря статье по работe с XCA уже есть заготовленная цепочка сертификатов.
Поэтому остаётся добавить её в NPM.
Для этого идём в раздел SSL Certificates и там выбираем добавление кастомного сертификата.
В открывшемся окне указываем произвольное имя этого сертификата.
Certificate Key - Ключ итогового сертификата
Certificate - Итоговый сертификат
Intermediate Certificate - Промежуточный ЦС - не обязательно
После чего сохраняемся.
Теперь, при редактировании уже имеющейся записи домена и сокета в NPM или добавлении новой, можно выбрать и применить к ней сохранённый набор сертификата и ключа.
Итог.
Связка Pi-Hole (локальный DNS) и Nginx Proxy Manager (обратный прокси + SSL) – превращает хаотичный набор IP-адресов и портов в организованную, удобную и безопасную систему доменных имён. Это шаг на пути к профессиональному и комфортному управлению домашними сервисами.
Краткое резюме и советы
- Pi-Hole – делает «телефонный справочник» (DNS) внутри дома. Сопоставляет «plex.home → 192.168.1.20», «gitlab.home → 192.168.1.30» и т.д.
- Nginx Proxy Manager – делает «главную стойку ресепшн», куда направляются все запросы с красивыми именами, а он дальше уже раздаёт трафик нужным внутренним сервисам.
- Статический IP гарантирует, что адреса внутри сети не поменяются после перезагрузки.
- Сертификаты SSL/TLS нужны, чтобы все соединения шли по HTTPS, а данные (пароли, файлы) передавались зашифрованными.
- Если используется несколько устройств (ноутбук, телефон) для доступа к домашним сервисам, следует убедиться, что они все используют Pi-Hole как DNS (либо прописать вручную, либо задать DNS-сервер на уровне роутера).
Такая система не только удобнее в использовании, но и помогает лучше понять, как работает интернет в целом. Ведь в глобальной сети действуют те же принципы, только в гораздо большем масштабе!
Ну и напоследок. Конечно же Pi-Hole далеко не единственный ДНС менеджер, равно как и NPM далеко не единственный обратный прокси, даже из бесплатных. Но для статьи и знакомства были выбраны именно они как наиболее простые в использовании и при этом одни из самых надёжных продуктов.
Комментарии
Отправить комментарий