Хот-спот 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, усе ще може бути відкинутий на зворотному шляху, і клієнт — єдине місце, де видно весь шлях.