Хотспот на Pi с Pi-hole и VPN: дайте на всяка услуга своя задача

Телефон се свързва с хотспота на Pi, получава адрес, а страницата все още не се отваря. На Pi работят помощник за хотспота, Pi-hole и VPN клиент и всеки от тях смята, че притежава част от пътя. Повечето такива конфигурации се провалят не защото компонент е счупен, а защото два компонента вършат една и съща работа. Определете един собственик на функция, преди да настройвате която и да е от тях.

Определете един собственик на функция

Тук имат значение четири функции и всяка се нуждае от точно един собственик. Таблицата по-долу изброява функцията, подходящ собственик и какво се обърква, когато две услуги претендират за нея.

Припокриването обикновено идва по един пакет наведнъж. Помощникът на хотспота инсталира свой екземпляр на 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 за интерфейсите обяснява, че режим на приемане, ограничен до един интерфейс, все пак може да използва универсален сокет и да отхвърля пристигания другаде. Това не е същото като обвързване само към избрани интерфейси, което е схемата, предвидена, когато друга DNS услуга трябва да дели машината.

Два процеса обикновено не могат да се обвържат с един и същ адрес и порт, въпреки че SO_REUSEPORT може да направи споделеното обвързване успешно; дори тогава универсален слушател може да поеме пристигания, предназначени за по-тясната услуга. Изберете документирания режим за ролята, която искате, и рестартирайте услугите в предвидения ред.

Дръжте административната страница на 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, все пак може да бъде изхвърлена по обратния път, и клиентът е единственото място, където целият път се вижда.