DNS

DNS – сервис для преобразования понятных человеку строк (panel.example.com) в IP-адрес (127.0.0.2). Как правило, записи в нем изменяются довольно медленно (до нескольких дней). Добавляются заметно быстрее (до часов).

DDNS

DDNS – динамический DNS – предназначен для случая когда запись изменяется часто, может по несколько раз в день. На практике нужно для домашних серверов, т.к. провайдер может выдавать “динамические IP-адреса”, которые в любой момент могут поменяться. Многие роутеры содержат упрощенные настройки подобных серверов.

Основная проблема в том, что сейчас провайдеры в большинстве своем перестали выдавать настоящие динамические IP-адреса (т.к. уже нет свободных IPv4 адресов), а выдают “серые ip”. Он делится с еще несколькими абонентами, и поэтому извне особо доступ не получишь. В этом случае нужно заказывать услугу “постоянного IP-адреса”, а тогда DDNS не нужен. Так что это скорее устаревшая технология.

Отдельная история, что провайдеры могут блокировать определенные порты для всех типов IP-адресов или для определенных типов. Например, обычно блокируется порт 25. Так что невозможно поднять свой сервер электронной почты дома. Мотивируется тем, что у многих пользователей вирусы и они рассылают спам, а за это вся сеть попадает в черные списки.

Скрещиваем DNS CNAME и DDNS

DDNS часто предоставляют достаточно некрасивый домен (something.no-ip.org) на бесплатном тарифе. Если есть свой домен, то можно сделать ссылку в DNS (используя запись типа CNAME):

cloud.example.com СNAME something.no-ip.org

Достаточно интересно, но в связи с умиранием DDNS не особо нужно.

mDNS

mDNS – многоадресный DNS – технология для локальных сетей. Каждый компьютер сам рассылает на какое имя он хочет отвечать и какие сервисы предоставляет. Как правило, используется домен “.local”.

Так, например, работает автообнаружение сетевых принтеров. Или NAS-устройств.

Весьма удобная штука.

Что это значит для домашнего облака?

Если нужен доступ извне, то:

  • нужно уточнить у провайдера какой IP-адрес выдается (серый или полноценный динамический). Скорее всего серый. Тогда заказать услугу постоянного IP-адреса. На роутере настроить проброс портов (скорее всего 80 и 443) на нужный домашний сервер.
  • использовать какой-то сервис к которому сервер/роутер присоединяется, а он перенаправляет траффик к вам. Есть в роутерах Keenetic (только для их админки), Tailscale, ngrok, возможно какие-то другие.
  • использовать VPN на роутере, чтобы войти в домашнюю сеть.

Дома рекомендуется использовать домен .lan по умолчанию. Например, у компьютера с именем cloud полное имя будет cloud.lan. Это требует какой-то настройки на роутере (как минимум указать локальный домен).

Так же рекомендуется использовать mDNS. Тогда у компьютера с именем cloud полное имя будет еще и cloud.local. Это настраивается на самом компьютере cloud и не требует централизованных настроек.

Представим, что у нас к контейнере запущено приложение Nextcloud и оно доступно по порту 30002. Так же у нас на портах 80 и 443 запущен веб-сервер как балансировщик нагрузки (LB): он берет на себя шифрование и доступ к разным приложениям по разным доменным именам, а не по разным портам (порты полегче, чем IP-адреса, но люди их все равно не любят).

Тогда внутри сети к этому приложению можно получить доступ следующими способами:

  1. https://nextclout.example.com (через LB используя публичный домен, https-сертификат от Let’s Encypt)
  2. https://nextclout.example.com:9443 (через LB используя публичный домен, https-сертификат от Let’s Encypt; порт отличается от по умолчанию, чтобы на него пробрасывать траффик с роутера и наружу смотрело не все, а только то, что должно)
  3. https://nextcloud.local (через LB используя mDNS, самоподписанный https-сертификат)
  4. https://nextcloud.lan (через LB используя внутренний DNS, самоподписанный https-сертификат)
  5. https://nextcloud.lan.mydomain.com (через LB используя внутренний и/или внешний DNS, https-сертификат от Let’s Encypt)
  6. http://nextcloud.local:30002 (напрямую используя mDNS, без шифрования)
  7. http://nextcloud.lan:30002 (напрямую используя внутренний DNS, без шифрования)
  8. http://cloud.local:30002 (напрямую используя mDNS-имя сервера, без шифрования)
  9. http://cloud.lan:30002 (напрямую используя внутреннее DNS-имя сервера, без шифрования)
  10. http://192.168.2.5:30002 (напрямую используя IP-адрес сервера, без шифрования)

В целом, лучше использовать варианты с шифрованием. Доступ без шифрования можно ограничивать либо в самом приложении (добавляются заголовки для браузера), либо на уровне firewall (на сервере или на сетевом устройстве).

Так же возможно каждому приложению в домашней сети выделить свой IP-адрес, чтобы не связываться с портами типа 30002, но особого смысла в этом нет: добавляет время на настройки, а плюсов все равно мало – мало кто в итоге будет использовать IP-адрес, отдельно настраивать https-сертификат для каждого приложения и т.п.

Чтобы не пользоваться самоподписанными https-сертификатами можно получить wildcard-сертификат (*.lan.example.com или *.example.com) от Let’s Encypt (бесплатно). wildcard-сертификат сертификаты нужны, чтобы не было видно какие сервисы запущены (т.к. список всех сертификатов – это публичная информация). Это несколько сложнее, т.к. требуется проверка через DNS (либо вручную делать раз в 3 месяца (мой вариант), либо интегрироваться с API вашего провайдера DNS, если у него такое есть), но все равно выглядит привлекательно. Пока что настроил у себя вручную.