Многие пользователи настраивают домашние DNS-серверы для блокировки рекламы и трекеров, однако такие решения часто остаются привязанными к локальной сети. При переключении на мобильный интернет или общественные Wi-Fi точки устройства начинают использовать сторонние DNS-резолверы, что сводит на нет все усилия по фильтрации трафика. Использование Tailscale позволяет объединить устройства в единую частную сеть и централизованно маршрутизировать DNS-запросы.
Ограничения локальной DNS-фильтрации
По своей архитектуре DNS является локально-зависимой технологией. В домашних условиях роутер автоматически назначает устройствам IP-адреса DNS-серверов, но вне дома эта конфигурация перестает работать. Традиционные методы решения, такие как открытие DNS-порта в интернет, использование DNS-over-HTTPS или покупка облачных сервисов фильтрации, имеют свои недостатки: от рисков безопасности до проблем с CGNAT.
Для создания отказоустойчивой системы автор использовал пару контейнеров Technitium, объединенных в кластер с виртуальным IP-адресом через Keepalived. Это решение эффективно работает внутри домашней сети, но требует интеграции с VPN-сеткой для доступа снаружи.
Развертывание маршрутизатора подсети через Tailscale
Вместо установки клиента Tailscale на каждый DNS-контейнер, что потребовало бы настройки TUN-устройств и сложной обработки отказоустойчивости, автор выбрал создание маршрутизатора подсети (subnet router). Это позволяет анонсировать определенные домашние IP-адреса остальной части сети Tailscale.
Настройка контейнера на Proxmox
Для реализации схемы была использована легковесная виртуальная машина Debian 13 (LXC) на платформе Proxmox с одним ядром и 256 МБ ОЗУ. В контейнере выполнены следующие шаги:
- Настройка перенаправления IP (IP forwarding).
- Подключение устройства /dev/net/tun через команду pct set 107 -dev0 /dev/net/tun.
- Установка Tailscale с анонсированием только двух необходимых адресов: виртуального IP DNS-сервера и обратного прокси Caddy.
Такой подход обеспечивает доступ к ресурсам через MagicDNS без необходимости открывать доступ ко всей локальной сети. Для автоматизации процесса при пересоздании контейнера была добавлена политика autoApprovers в консоли администратора Tailscale.
Централизованное управление DNS-трафиком
После настройки маршрутов интеграция завершается двумя действиями в панели управления Tailscale:
- Добавление Keepalived VIP в качестве глобального сервера имен (nameserver).
- Активация опции «Override DNS servers», которая принуждает все клиенты Tailscale игнорировать настройки локальной сети и использовать указанный домашний сервер.
Теперь DNS-запросы направляются на встроенный резолвер Tailscale (100.100.100.100) и далее через зашифрованный туннель поступают на домашнюю систему фильтрации. Это позволяет использовать привычные локальные доменные имена и HTTPS-защиту за пределами дома.
Важные нюансы настройки
Необходимо учитывать, что некоторые приложения могут обходить фильтры. В частности, функция «Private DNS» в Android или «Secure DNS» в браузерах могут использовать протокол DNS-over-HTTPS, игнорируя настройки сети. В таких случаях рекомендуется переключить параметры в положение «Automatic» или «Off». Пользователям Linux-клиентов для корректной работы маршрутов подсети также требуется выполнить команду tailscale set —accept-routes.
Главным техническим компромиссом стало изменение исходных IP-адресов в логах Technitium: из-за работы маршрутизатора подсети все запросы отображаются с IP-адресом этого маршрутизатора. Для задач блокировки рекламы этот фактор является несущественным, однако позволяет обеспечить защиту мобильных устройств без установки дополнительного программного обеспечения.
Технические детали настройки Technitium и кластеризация
Важным этапом при настройке системы было обеспечение корректной работы блокировщиков рекламы. В Technitium версии 15 произошли изменения в интерфейсе управления: URL-адреса для списков блокировки (blocklist URLs) теперь находятся в общих настройках кластера, а не на индивидуальных страницах конфигурации каждого сервера. Это решение позволило синхронизировать списки на обоих узлах, что критически важно при использовании Keepalived: теперь не имеет значения, какой из серверов в данный момент удерживает виртуальный IP-адрес — оба узла оперируют идентичными наборами данных.
Отказ от прямого доступа и риски «публичного» DNS
Автор статьи подчеркивает, что выбор в пользу Tailscale был продиктован стремлением избежать типичных ошибок при попытке «вынести» DNS-фильтрацию за пределы дома. Прямое открытие портов DNS (порт 53) в интернет является серьезной угрозой безопасности, а попытки проброса портов при использовании соединения через CGNAT часто оказываются технически невыполнимыми. Использование же коммерческих облачных сервисов фильтрации рассматривалось как избыточная трата средств, поскольку аналогичная инфраструктура уже была построена на базе собственных серверов.
Особенности выбора маршрутизатора подсети
Решение использовать subnet router вместо установки Tailscale непосредственно внутрь DNS-контейнеров было принято исходя из простоты масштабирования и отсутствия необходимости дважды настраивать отказоустойчивость. Прямая установка Tailscale на каждый DNS-сервер потребовала бы передачи TUN-устройств в каждый контейнер и запуска дополнительного демона в каждом из них. При этом виртуальный IP, управляемый через Keepalived, не переносился бы в Tailscale автоматически, что привело бы к дублированию логики переключения при сбоях. Использование subnet router на базе LXC-контейнера позволило оставить существующую инфраструктуру (Technitium, Keepalived и Caddy) в неизменном виде.
Тонкости маршрутизации и безопасности
Хотя была возможность анонсировать всю домашнюю сеть целиком через Tailscale, автор намеренно ограничил список только двумя конкретными IP: виртуальным адресом DNS-пары и адресом обратного прокси Caddy. Принцип минимально необходимого доступа (principle of least privilege) был соблюден, так как для взаимодействия с остальными устройствами в сети вполне достаточно функций MagicDNS. Для стабильности системы в консоли управления Tailscale была отключена опция истечения срока действия ключей (key expiry), а в политике tailnet был прописан блок autoApprovers, который автоматически одобряет маршруты при пересоздании контейнера маршрутизатора.
Неожиданные преимущества и нюансы работы
Помимо решения основной задачи, переход на такую схему принес неожиданный бонус: устройства системы Eero (mesh-система), которые обычно «захватывают» DNS-трафик, не видят трафик, проходящий через туннель Tailscale. Это позволило использовать локальные доменные имена без сложных обходных путей, которые требовались ранее.
Однако стоит учитывать специфику работы маршрутизатора подсети как «бутылочного горлышка»:
- Единая точка отказа: Маршрутизатор подсети стал единственным узлом, отвечающим за удаленный DNS. Впрочем, при необходимости этот риск легко нивелируется настройкой второго резервного subnet router, на что уходит всего пара минут.
- Детализация логов: Из-за того, что маршрутизатор подсети переписывает исходный адрес запроса на свой IP, логи Technitium теряют информацию о том, какое именно клиентское устройство инициировало DNS-запрос. Для автора, использующего фильтрацию лишь для блокировки рекламы, это приемлемая цена, но при потребности в настройке профилей для отдельных пользователей потребуется установка клиента Tailscale на каждый отдельный хост.
Таким образом, использование проверенной связки Keepalived и Technitium в сочетании с одним легковесным маршрутизатором подсети позволило превратить локальное решение для фильтрации в персональный защищенный сервис, доступный повсеместно, без необходимости переписывать существующую инфраструктуру домашней лаборатории.
