Проблема с центром сертификации для unifi.local (домен Cloudflare без прокси).

Проблема с центром сертификации для unifi.local (домен Cloudflare без прокси)., wifiman

Altorvo

Guest

11.02.2025 12:14:00

Привет всем, надеюсь на вашу помощь.

Контекст: я хощу несколько сервисов через Cloudflare домен, некоторые из которых сидят за их прокси, а некоторые только по DNS (из-за типа контента). При переходе на DNS-only сайт падает и выдает: net::ERR_CERT_AUTHORITY_INVALID. При проверке сертификата я вижу: unifi.local — это заставило меня задуматься, нужны ли какие-то настройки UniFi, которые мне нужно настроить, чтобы соединение работало? Сайт подключается нормально, когда я использую Cloudflare прокси, однако я не могу использовать это постоянно из-за их ToS. Настройка DNS-only работала до того, как я добавил роутер Ubiquiti в свою систему, поэтому я и оказался здесь.

Настройка:
* Недавно приобрел UCG UltraPort для перенаправления IP-адресов Cloudflare на мой обратный прокси (NPM)
* Cloudflare домен(ы)
* Nginx Proxy Manager, как обратный прокси с SSL сертификатами
* Веб-сервер работает на локальной машине (разный внутренний IP-адрес по сравнению с обратным прокси, из-за отдельного LXC на proxmox node)

Вопросы:
* Есть ли в UniFi настройка для обработки этого сертификата unifi.local?
* Или способ обойти его?
* Могут ли настройки IDS/IPS каким-то образом повлиять на это? (после некоторых тестов казалось, что нет, но хочу проверить)

Надеюсь, более опытные участники, чем я, смогут указать на то, что, скорее всего, это простая проблема.

Много спасибо заранее.

Alex7021

Guest

17.02.2025 14:41:00

@AltorvoHi. Поскольку я не люблю проигрывать машинам (в конце концов, они существуют благодаря чьему-то интеллекту), я разгадал эту загадку. Всё нужно настроить так (проверено на моей системе, так что гарантирую, что работает):
1) Запись в Cloudflare @mydomain;
2) CNAME запись для каждого поддомена (оставьте прокси включенным без проблем, чтобы скрыть свой IP);
3) UCG DNS должен отображать все записи A для jellyfin.yourdomain.com, wiki.yourdomain.com, mealie.yourdomain.com и т.д… Они все должны указывать на IP-адрес вашего NPM, который будет разрешаться без проблем. Так что вам просто нужно перенаправить порт 443 WAN на 443 IP-адреса NPM (конец). Работает идеально.
Делая это, когда вы запрашиваете адрес внутри сети, он разрешается UCG DNS, когда запрос приходит извне, Cloudflare (с CNAME) заботится о нём и перенаправляет запрос на ваш IP на 443, который, в свою очередь, с переадресацией, передаёт его на 443 NPM.
Повторю, я не говорю это просто так, я протестировал и это отлично работает!
Учитывайте, что при создании CNAME записей может потребоваться несколько минут, чтобы они распространились, так что в худшем случае вы можете получить 522.
P.S. не имеет значения, загружаете ли вы сертификат на роутере.

Altorvo

Guest

13.02.2025 10:42:00

На мой опыт, это будет работать только локально. Дело в том, что когда клиент из локальной сети пытается узнать IP-адрес домена, роутер возвращает локальный IP (NGINX), чтобы направить трафик — и это объясняет, почему у тебя работает, поскольку ты технически находишься внутри своей сети после подключения по VPN. WAN-трафик, достигающий роутера, в моем случае, будет перенаправлен на NPM (через переадресацию портов 80/443), после чего локальный DNS не запрашивается для преобразования домена в IP. Так что, как и в случае с большинством других роутеров, он ДОЛЖЕН быть отправлен на NPM, который затем использует предоставленный(ые) сертификат(ы) для обработки SSL-соединения.

Похоже, вместо этого роутер требует сертификат или что-то подобное для обработки этого "прыжка" между получением WAN и отправкой его на NPM. Вот почему я получал "Cert Authority" и позже "DNS_PROBE_FINISHED_NXDOMAIN" — это ошибка, указывающая на то, что роутер не смог найти окончательный IP-адрес для домена.

Я действительно ценю всю помощь, поддержку и время, которые ты мне предоставил(а) до сих пор. Я просто не в ситуации, в которой возможно, чтобы все мои пользователи имели VPN-клиент для доступа к моим сервисам, а также сервисы не могут работать через Cloudflare tunnel (так как это проксированный метод). Не знаю, как это решить.

Alex7021

Guest

12.02.2025 17:16:00

Появляется ошибка ERR_CERT_AUTHORITY_INVALID или DNS_PROBE_FINISHED_NXDOMAIN, потому что сертификат валиден только если трафик проходит через Cloudflare. Если ты напрямую указываешь на IP-адрес, сертификат больше недействителен! Единственный способ это решить:
1) сгенерировать wildcard сертификат для твоего домена с помощью NPM;
2) загрузить его в роутер;
3) создать записи A в Ultra в разделе routing > DNS, указывающие jellyfin.yourdomain.com, указывая IP-адрес NPM;
4) NPM получает запрос и разрешает его, предоставляя ответ.

Очевидно, что все поддомены, созданные в MPM, будут иметь одинаковый сертификат и будут указывать на правильный порт и IP-адрес, где находится сервис. Так что у тебя нет причин использовать Cloudflare для каждого отдельного сервиса (и, как следствие, быть вынужденным отключать прокси), а используешь только для того, чтобы сообщить ему, где находится твой домен. Неважно, какой поддомен (jellyfin, Wiki, Mealie), каждый запрос из сети с твоим именем домена будет указывать на твой адрес. Роутер и NPM сделают остальное. Очевидно, для HTTPS запросов нужно открыть порт 443, иначе ты не получишь ответа.

У меня всё именно так, и проблем нет, единственное отличие в том, что я не открывал 443, потому что захожу в роутер через VPN. Как только я внутри, DNS роутера перенаправляет мой запрос, например, photo.mydomain.com, на IP-адрес NPM, который находится в Docker на моём NAS, который знает, какой порт спросить, и поэтому предоставляет ответ. Я повторяю, я не знаю, является ли это лучшим решением, но это то, что я использую, и это работает безупречно без проблем. Прости, что не могу помочь тебе лучше.

Altorvo

Guest

12.02.2025 16:03:00

Извините за возможную путаницу. Вот что у меня есть:

Основной локальный компьютер с Proxmox (обрабатывает все сервисы: Wiki, Immich, Jellyfin, управление рецептами, NGINX Proxy Manager, PiHole + основное хранилище) — большинство из них работают в Docker в отдельных LXC.

Вторичный локальный компьютер с TrueNAS (резервное копирование хранилища) — других сервисов здесь не запущено, пока не требуется.

UCG Ultra (маршрутизатор)

1 TLD

Что я хочу добиться:

Чтобы сервисы вроде Jellyfin, Wiki, управления рецептами (Mealie)… и т. д. были доступны вне LAN, не используя VPN/туннель.

Cloudflare ограничивает скорость загрузки/выгрузки на DNS-записях, которые используют их прокси (что раньше противоречило их ToS), что означает, что я не могу использовать их прокси для таких вещей, как Jellyfin, но могу использовать его для HTML-сайтов вроде Wiki или страницы рецептов… и т. д.

Что у меня было настроено:

DDNS (обновляет Cloudflare о публичном IP) > домены разрешаются в публичный IP > UCG перенаправляет порты (IP-адреса Cloudflare) на локальный NGINX, который обрабатывает домен к локальному IP/порту необходимого сервиса + SSL.

Это отлично работает для подключений, где Cloudflare обрабатывает SSL-соединение, т. е. оранжевое облако, в противном случае я получаю net::ERR_CERT_AUTHORITY_INVALID или DNS_PROBE_FINISHED_NXDOMAIN.

У меня были некоторые поддомены, использующие прокси Cloudflare (оранжевое облако), и один поддомен (jellyfin) в режиме DNS-only (серое облако).

Какой правильный способ разрешить подключение от DNS-провайдера к локальному веб-серверу, как описано выше?

Надеюсь, вышеизложенное поможет прояснить мою ситуацию — очень ценю вашу помощь до сих пор!

Alex7021

Guest

12.02.2025 15:19:00

Возможно, теперь я лучше понимаю твою ситуацию, но информации всё равно не хватает. Ты используешь Cloudflare для всех своих сервисов, а не только для разрешения доменного имени. Я использую Cloudflare только как разрешение домена. Поддомены разрешаются внутренним DNS роутера и NGINX каскадно. Все поддомены всегда и только ссылаются на IP NPM, который их разрешает. Ответ на твой вопрос — через прокси, потому что в итоге мне нужно, чтобы мой публичный IP не был виден. Как только домен разрешён и, следовательно, запрос с веб-сайта достигает роутера, он и NPM делают остальное. Таким образом, я также решил ещё одну проблему: мне не пришлось открывать никакие порты, так как я получаю доступ ко всем своим сервисам на NAS через VPN и только если подключён к нему. Скажи мне (если хочешь), что у тебя есть (NAS или другое), где находятся твои сервисы и где NPM. Чётко укажи, что у тебя есть и чего ты хочешь добиться, чтобы больше людей могли тебе помочь.

Altorvo

Guest

12.02.2025 12:56:00

У меня практически та же самая конфигурация. Но запись A в локальном DNS работает только локально (по крайней мере, у меня). Моя конфигурация такая: DDNS обновляет Cloudflare для wildcard домена с публичным IP, который отправляется на открытые порты в Ultra, затем запись A для локального DNS (но это работает только локально), которая указывает на NGINX Proxy Manager -> сервис. А у тебя Cloudflare настроен только на DNS или с прокси? Потому что не все мои сервисы могут работать за Cloudflare прокси (именно с этим у меня проблемы).

Alex7021

Guest

12.02.2025 12:21:00

Расскажу, как я это сделал. В Cloudflare у меня есть A-запись для корневого домена, которая указывает на мой публичный IP (у меня статический IP от провайдера). Поэтому любой запрос, сделанный в сети для этого домена, например, "pluto.com", разрешается и указывает на мой публичный IP. На этом этапе вступает в игру роутер, в котором ты будешь регистрировать все свои сервисы в A-записях, например, photo.pluto.com, с указанием IP твоего NGINX, готового их разрешать и предоставлять тебе запрашиваемый сервис. То есть, если пользователь в сети вводит https://photo.pluto.com, Cloudflare знает, что для достижения этого домена ему нужно указать на IP 224.123.222.1, а роутер разрешает с внутренним DNS photo.pluto.com, который указывает на IP NGINX, который в свою очередь разрешает имя и предоставляет тебе сервис. Возможно, есть лучший способ сделать всё это, но мне так отлично работает, и пока что меня всё устраивает.

Altorvo

Guest

12.02.2025 11:53:00

Спасибо за быстрый ответ! Я всю ночь пытался заставить это работать — в итоге получаю либо DNS_PROBE_FINISHED_NXDOMAIN, либо ошибку 504 gateway timeout. Работает только тогда, когда Cloudflare обрабатывает SSL-соединение, в остальных случаях кажется, что UniFi берет wildcard-сертификат, но не может найти IP-адрес для разрешения домена. Я даже пробовал перенаправлять на DNS-сервер Pi-Hole с локальным DNS, указывающим на IP-адрес NGINX, но, как вы понимаете, это работает только локально. Если я не перенаправляю никаких DNS-маршрутов, домен возвращает меня на страницу входа UniFi OS (локально — иначе время ожидания истекает). Думаю, это какая-то проблема с DNS-конфигурацией? Но не уверен, в чем именно ошибка. Есть какие-нибудь идеи?

Alex7021 Guest	#10 11.02.2025 14:32:00 Nginx Proxy Manager, как обратный прокси с SSL-сертификатами. Импортируй свой wildcard-сертификат на Ultra. Затем во внутреннем DNS перенаправляй все запросы на IP-адрес NGINX, и всё готово.

Читают тему (гостей: 1)