85. DNS в домашней сети. Pi-hole.

В одной из предыдущих статей уже вкратце упоминались такие важные сетевые механизмы как DNS и DHCP. В этом материале коснёмся работы с ними.

Теория.

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

На любом домашнем раутере, кроме всего прочего всегда работают две службы (сервера) ответственные за работу сети: DHCP и DNS.

Первая отвечает за раздачу внутренних сетевых адресов конечным устройствам (клиентам), и запоминания чей МАК адрес соответствует тому или иному АйПи адресу. Здесь же обычно происходит резервирование адресов, чтобы за одним и тем же МАКом сохранялся один и тот же АйПи.

Т.к. на более низком уровне компьютерное железо общается между собой на уровне МАК адресов, а на более высоком - программном уровне с помощью АйПи, то можно сказать что DHCP это аналог телефонной книги, где каждому имени соответствует номер. С той лишь разницей, что в данном случае именем является АйПи адрес, а номером - МАК.

DNS это точно такая же "телефонная книга" соответствия, только уже не для компьютеров, а для людей. Если бы мы могли запоминать комбинации цифр так же легко как слова, то днс сервера были бы не нужны.

Кстати, адрес днс сервера указывается в настройках раутера и его получают клиенты вместе с остальной информацией от DHCP,

Для чего же нужен DNS в домашней сети?

• Когда количество хостов в сети растёт благодаря появлению новых виртуальных машин и/или контейнеров, легче всё же запоминать по именам, а не по адресам.
• Чтобы сделать сеть безопасной выписав на каждое имя свой SSL сертификат, или использовать один в котором перечислить все локальные днс имена.
• Для блокировки рекламы и возможности открывать вредоносные сайты на уровне всей сети.
• Чтобы менять IP-адреса хостов без перенастройки подключений, сохраняя неизменными привычные имена url.

Какие минусы есть при использовании собственного днс сервера в локальной сети?

• Дополнительная нагрузка на оборудование. Запуск DNS-сервера требует выделения вычислительных ресурсов, что может незначительно снизить производительность базового устройства.

• Необходимость администрирования. Требуется регулярная поддержка и обновление DNS-конфигурации, что увеличивает сложность управления сетевой инфраструктурой.

• Риски неправильной настройки. Некорректная конфигурация может привести к проблемам с резолвингом доменных имен и сетевой связностью.

• Дополнительная точка отказа. DNS-сервер становится критическим компонентом сетевой инфраструктуры, и его выход из строя может нарушить работу всей локальной сети.

• Сложности с внешними доменами. Собственный DNS-сервер может потребовать дополнительной настройки для корректной работы с интернет-ресурсами.

Кстати, само собой разумеющийся факт что использование доменных имён в локальной сети не отменяет использование обращений к серверам и устройствам по их айпи адресу.

Итак, для стабильной работы сети назначаем всем необходимым сервисам статические адреса на уровне DHCP сервера.

А для удобства доступа, к статическим адресам "привязываем" понятные и удобные имена на уровне DNS сервера.

Практика.

Как именно резервировать адреса на DHCP сервере раутера в этой статье описать физически невозможно, по элементарной причине - множество моделей последних. Поэтому гугл в помощь.

Главное не забыть после установки DNS сервера зарезервировать для него подходящий адрес.

Вторая важная деталь - указать в настройках раутера кто является внутренним DNS сервером. Уже по указанной выше причине, дать точные указания для всех моделей раутеров, которые могут быть у читателей - ни у кого нет возможности. Поэтому ищем самостоятельно. 

ДНС серверов существует великое множество, и лагеря сторонников тех или иных продуктов продолжают пополнятся в равной степени.

Рассмотрим для примера установку PiHole - легковесный сервер, как понятно из названия был разработан для работы на одноимённом одноплатном компьютере. Благодаря замечательному Tteck и сообществу поддержавшему его, сервер устанавливается одной командой:

bash -c "$(wget -qLO - https://github.com/community-scripts/ProxmoxVE/raw/main/ct/pihole.sh)"

Она создаст LXC контейнер с 1 одноядерным процессором, 512 Мб оперативной памяти и 2Гб жёсткого диска.

Порт для веб интерфейса по умолчанию - 81

Для сброса пароля администратора необходимо в консоли созданного контейнера выполнить команду: pihole -a -p

Добавление доменов максимально простое и интуитивно понятное.

Интересующиеся остальным функционалом могут почитать официальную документацию.

Кстати, благодаря такому собственному ДНС серверу можно воспользоваться трюком, который используют злоумышленники - подмена адресов. Только на этот раз, такой трюк будет работать во благо.

Допустим у нас есть свой домен для доступа к своему Home Assistant снаружи (ha.bla-bla.com), т.е.через интернет. Однако когда смартфон дома и подключен к домашней беспроводной сети, то обращаться к серверу находящемуся в этой же сети через интернет это... ну мягко говоря не очень грамотная затея.

Поэтому можно сделать ДНС запись такого же вида как и внешний адрес доступа к ХА, и перенаправить его на АйПи виртуальной машины  (к примеру 192.168.1.15).

ha.bla-bla.com = 192.168.1.15

Если происходит доступ по HTTPS снаружи, то в сертификате используемом в самом Home Assistant должен быть указан и его внешний url - ha.bla-bla.com. Ну и другие адреса, если необходимо проделать такой же трюк для других сервисов.

Теперь становится понятно для чего были нужны шаблоны при выпуске сертификатов.

В итоге, тот же ХА будет открываться и по локальному IP адресу, и по локальному DNS имени и по интернет адресу, но без выхода в сам интернет.

Установка самоподписанного сертификата в Pi-Hole.

Используя WinSCP или любой другой удобный способ копируем в пихол файлы сертификатов privkey.pem(ключ) и fullchain.pem(цепочка сертификатов) в папку /etc/lighttpd/ssl

Пользователя, который запускает веб интерфейс, сделаем  владельцем этих файлов:

chown www-data:www-data /etc/lighttpd/ssl/fullchain.pem /etc/lighttpd/ssl/privkey.pem

Ограничим права доступа к ним только для владельца:

sudo chmod 600 /etc/lighttpd/ssl/fullchain.pem /etc/lighttpd/ssl/privkey.pem

Установим модуль для работы с SSL:

apt-get reinstall lighttpd-mod-openssl

Создадим новый конфигурационный файл:

nano /etc/lighttpd/conf-available/20-https.conf

Вставим в него следующее содержимое:

#Loading openssl

server.modules += ( "mod_openssl" )

\$SERVER["socket"] == ":443" {
ssl.engine = "enable"
ssl.pemfile = "/etc/lighttpd/ssl/fullchain.pem"
ssl.privkey = "/etc/lighttpd/ssl/privkey.pem"

ssl.openssl.ssl-conf-cmd = ("MinProtocol" => "TLSv1.3", "Options" => "-ServerPreference")
}

# Redirect HTTP to HTTPS
\$HTTP["scheme"] == "http" {
url.redirect = ("" => "https://\${url.authority}\${url.path}\${qsa}")
url.redirect-code = 308
}

Включим этот файл в конфигурацию используя символическую ссылку:

ln -s ../conf-available/20-https.conf \
/etc/lighttpd/conf-enabled/20-https.conf

Проверим что все изменения будут обработаны как нужно и не вызывают ошибок:

lighttpd -tt -f /etc/lighttpd/lighttpd.conf

Перезапустим сервис веб интерфейса:

service lighttpd restart

Теперь при открытии веб интерфейса будет срабатывать перенаправление с HTTP на HTTPS.

А вот как сделать так, чтобы все сайты домашних серверов работали по протоколу HTTPS - об этом в следующих материалах.