Это продолжение заметки DNS вообще и дома.
DNS
В роутере делаю IP стабильным для всех серверов, просто чтобы не искать их если что.
localhost
Все знают, что localhost – это текущий компьютер.
В современных ОС (как минимум macOS), *.localhost – это тоже текущий компьютер автоматически.
Так можно через caddy выставлять несколько сайтов на стандартных портах: myproject.localhost и api.myproject.localhost.
Есть программы (например, https://portless.sh/), которые автоматически позволяют самоподписывать такие домены (и вообще локально caddy не нужен с ними). Понятно, что извне недоступно, но локально полностью удобно работает.
local
*.local – это специальный домен от mDNS (aka Zeroconf / Rendezvous). Компьютер сам анонсирует свое имя.
Основной сценарий: принесли новый программно-аппаратный комплекс домой, воткнули его в ethernet-розетку, включили, он получил по DHCP IP-адрес, а сам рассказал, что готов отвечать на nas.local. Вы посмотрели на нам наклейку и не заходят в роутер просто в браузере вбили nas.local.
Аналогично с WiFi, только устройство создает свою WiFi и свой DHCP, а вы к нему подключаетесь, чтобы дать пароль от домашней WiFI-сети.
Выглядит прикольно, но не всегда работает из-за VPN и прочих вещей (VPN обычно позволяет напрямую общаться с внутренними ресурсами, но может блокировать внутренние широковещательные сообщения – тогда домены local не работают).
Одна из проблем: только самоподписанные сертификаты для SSL можно использовать (или вообще без SSL). А это уже ограничивает удобство и безопасность использования.
В целом, я имею это в виду, но реально использую обычно только для первоначальной настройки устройств.
Раздельный (split) DNS
Это разные значения внутри сети и снаружи. Например, nas.myhome123.ru внутри идет на 192.168.1.10, а снаружи на 1.2.3.4 (публичный ip, обычно роутера).
Такой подход обязателен для нормальной работы внутренних сервисов, открытых наружу, изнутри. Сложно, но так и есть. Есть способ это все правильно без DNS настроить, но сложно и мало кто делает (через отдельные таблицы роутинга).
Подход может использоваться, чтобы получить SSL сертификат через публичный IP, а затем его же использовать внутри (публично может вообще выставляться пустая страница, для сертификата этого достаточно).
Плохо работает с разными DNS-настройками у разных внутренних клиентов (когда они настроены не на роутер, а еще на что-то). Для пример DNS от Яндекса для показа только детских ресурсов. Такие клиенты не увидят внутренние ресурсы, что не хотелось бы.
Так что долго думал, даже пробовал, но в итоге отказался от такого подхода.
Публичный или внутренний DNS
Публичный доступен для всех в интернете. Внутренний доступен только через DNS роутера.
По той же причине, что и раздельный DNS, использую публичный: работает со всеми клиентами.
Это немного плохо, что потенциально хакер может понять внутренние IP, но, в целом, ничего страшного.
Это же приводит к тому, что использую свои публичные зарегистрированные домены, а не nas.home, nas.loc (внутренние незарегистрированные домены).
SSL
SSL для внутренних IP
Caddy прекрасно регистрирует домены для внешних IP-адресов. Если же нужно зарегистировать сертификат для внутренних IP-адресов (публичная запись для этого есть), то нужно применять подтверждение владения доменом через DNS (DNS Challenge).
Немного изучив вопрос понравился вариант через https://github.com/acme-dns/acme-dns – маленький сервис на своем сервере, зато не нужно пересобирать Caddy под разные DNS провайдеры.
Второй вариант найти плагин для Caddy для вашего DNS провайдера и собрать Caddy с ним.
В целом, рабочий вариант, но решил сделать попроще.
tls internal
Caddy позволяет создавать самоподписанные сертификаты. Но это не все. Еще позволяет другим Caddy использовать тот же сертификат.
В итоге, ставим центральный Caddy на Keenetic (acme_server и tls internal), а остальные Caddy настраиваем на него (tls ca https://router/acme/local/directory и tls ca_root /etc/ssl/certs/root.crt).
Т.о., нужно будет добавить только 1 сертификат. На десктопах я добавляю в Firefox, т.к. это не на всю систему, а только на него.
Итог
Вводные данные:
- разные клиенты используют разные (в том числе публичные) DNS-сервера
- публичных сервисов из домашней сети нет (при необходимости доступа извне используется VPN/Tailscale)
Решения:
- IP внутренние: фиксированны на роутере
- домены: зарегистрированные публичные на внутренние IP и *.local
- SSL: самоподписанные для внутренних сервисов (включая *.local)
- центральный Caddy для единого внутреннего самоподписанного сертификата, но индивидуальные Caddy на каждой машине, чтобы не было центральной зависимости