Хот-спот Pi с Pi-hole и VPN: назначьте каждой службе свою задачу
Решите, кто владеет DHCP, DNS и пересылкой пакетов, прежде чем включать три помощника на одном Pi. Дублирующиеся владельцы дают конкурирующие аренды и циклы в резолвере.
Телефон подключается к хот-споту Pi, получает адрес, а страница по-прежнему не открывается. На Pi работают помощник хот-спота, Pi-hole и клиент VPN, и каждый считает, что владеет частью пути. Большинство таких сборок ломается не из-за неисправного компонента, а из-за того, что два компонента делают одну и ту же работу. Назначьте одного владельца на каждую функцию, прежде чем что-либо настраивать.
Назначьте одного владельца на каждую функцию
Здесь важны четыре функции, и каждой нужен ровно один владелец. В таблице ниже указаны функция, рабочий владелец и то, что идёт не так, когда на неё претендуют две службы.
| Function | Workable owner | Duplicate-owner symptom |
|---|---|---|
| Client addresses | One DHCP server, such as the hotspot helper | Competing offers and changing leases |
| DNS reception | Pi-hole on port 53 | Bind failure or queries answered by the wrong process |
| Forwarding and NAT | One firewall manager | Double translation and broken return paths |
| VPN routing | One client configuration | Route flapping and traffic escaping outside the tunnel |
Наложение обычно приходит по одному пакету. Помощник хот-спота ставит свой экземпляр dnsmasq, Pi-hole хочет порт 53, а клиент VPN добавляет маршруты. Каждый шаг по отдельности выглядит разумно, а вместе они дают машину, где вторая запущенная служба тихо меняет поведение первой.
Запишите владельцев, прежде чем включать что-то ещё. Короткая таблица в заметках о сборке не даст более поздней установке забрать функцию, у которой уже был владелец.
Выберите один диапазон и держите его подальше от туннеля
Выберите диапазон хот-спота, адрес Pi в нём, пул DHCP и резолвер, который получают клиенты. Держите этот диапазон отдельно от вышестоящей локальной сети и от диапазона туннеля VPN, потому что пересекающиеся подсети превращают проблему маршрутизации в проект трансляции адресов. Диапазон, пересекающийся с туннелем, делает Pi случайным маршрутизатором между двумя одинаковыми префиксами. Запишите диапазон и пул в конфигурацию хот-спота, а не оставляйте их значению по умолчанию.
Если хот-спотом владеет общий режим NetworkManager, изучите действующее подключение, прежде чем добавлять сервер DHCP. Общий режим запускает собственных помощников и включает пересылку, поэтому он уже владелец плана адресов для этого интерфейса. Добавление второго сервера только потому, что он доступен, создаёт конкурирующие предложения, а не резервирование.
Решите вопрос с IPv6 осознанно. Объявления маршрутизатора и DHCPv6 во многих конфигурациях приходят от другого помощника, чем DHCPv4, а если оставить IPv6 включённым, пока политика VPN покрывает только IPv4, клиенты получат путь в обход туннеля. Либо спланируйте сторону IPv6, либо отключите её на интерфейсе хот-спота с записанной причиной.
Кто на самом деле отвечает на порту 53
Перечислите все процессы, слушающие порт 53, прежде чем менять конфигурацию. На Pi, где работают локальная заглушка резолвера, Pi-hole и помощник общего доступа, список слушателей — единственная надёжная карта того, кто отвечает на запросы:
sudo ss -lunpt '( sport = :53 )'
ip -4 addr show
ip routeРуководство по интерфейсам Pi-hole объясняет, что режим приёма, ограниченный одним интерфейсом, всё равно может использовать сокет wildcard и отбрасывать пакеты, пришедшие в другое место. Это не то же самое, что привязка только к выбранным интерфейсам, — именно такой вариант предусмотрен, когда машину должна делить другая служба DNS.
Два процесса обычно не могут привязаться к одному адресу и порту, хотя SO_REUSEPORT может сделать совместную привязку успешной; даже тогда слушатель wildcard может забрать пакеты, предназначенные более узкой службе. Выберите документированный режим для нужной роли и перезапустите службы в задуманном порядке.
Держите страницу администрирования Pi-hole вне сети хот-спота. Клиентам нужен резолвер, а не веб-интерфейс или API, которые могут изменить конфигурацию резолвера.
Две ветви DNS, у каждой своя политика
Запрос клиента идёт с телефона на Pi, а отдельный запрос идёт с Pi к вышестоящему резолверу. Правило маршрутизации, совпадающее с пересылаемым трафиком хот-спота, не применяется автоматически ко второй ветви, потому что Pi создаёт этот трафик локально. Если VPN должен переносить DNS, локальному пути нужна собственная политика.
Следите за циклом. Направление вышестоящего резолвера Pi-hole на адрес, который обслуживает сам Pi, напрямую или через проброс порта, даёт запросы, которые кружатся до истечения времени ожидания. Дайте ему настоящий вышестоящий резолвер или условный форвардер для доменов, на которые он не может ответить.
Решите, что происходит при падении туннеля. Возврат к локальному резолверу сохраняет просмотр, но может утекать имена за пределы VPN; блокировка сохраняет политику нетронутой и превращает сбой в видимую ошибку. Оба варианта защитимы, но их нужно выбирать, а не наследовать от значения по умолчанию.
Докажите путь и поведение при сбое
Проверяйте послойно: клиент получает адрес, клиент разрешает имя через Pi, Pi разрешает через задуманный вышестоящий резолвер, а приложение завершает запрос. Успешный ping ничего не говорит о DNS, а успешное разрешение имени ничего не говорит о пересылке.
dig @192.168.70.1 example.com
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/
ip -4 route get 1.1.1.1Затем остановите туннель и повторите. Задуманное поведение должно появиться в течение нескольких секунд, а не после ручного перезапуска Pi-hole или службы хот-спота. Проверьте настройку резолвера у клиента во время сбоя, потому что вторичный публичный резолвер продолжит отвечать, даже когда политика ожидала отказа.
Держите одного владельца для пересылки и NAT и проверяйте его с клиента, а не с самого Pi. Запрос, который успешно покидает Pi, всё ещё может быть отброшен на обратном пути, и клиент — единственное место, где виден весь путь.