Pi хотспот со Pi-hole и VPN: доделете на секоја служба сопствена задача

Телефон се приклучува на хотспотот на Pi, добива адреса, а страницата уште не успева. Pi извршува помошник за хотспот, Pi-hole и VPN клиент, и секој од нив мисли дека поседува дел од патеката. Повеќето од овие поставки не паѓаат затоа што компонентата е расипана, туку затоа што две компоненти ја вршат истата работа. Доделете еден сопственик по функција пред да подесите било која од нив.

Доделете еден сопственик по функција

Овде се важни четири функции и на секоја ѝ треба точно еден сопственик. Табелата подолу ја наведува функцијата, изводлив сопственик и што тргнува наопаку кога две служби полагаат право на неа.

Преклопувањето обично доаѓа еден пакет по еден. Помошникот за хотспот инсталира сопствена инстанца на dnsmasq, Pi-hole го сака портот 53, а VPN клиентот додава рути. Секој чекор изгледа разумно сам за себе, а заедно даваат машина во која втората служба што ќе стартува тивко го менува однесувањето на првата.

Запишете ги сопствениците пред да вклучите нешто друго. Кратка табела во белешките за изградба спречува подоцнежна инсталација да преземе функција што веќе имала сопственик.

Изберете еден опсег и држете го подалеку од тунелот

Изберете го опсегот на хотспотот, адресата на Pi во него, DHCP базенот и резолверот што го добиваат клиентите. Држете го тој опсег одделен од нагорната LAN мрежа и од опсегот на VPN тунелот, бидејќи подмрежите што се преклопуваат го претвораат проблемот со рутирање во проект за превод на адреси. Опсег што се преклопува со тунелот го прави Pi случаен рутер меѓу два идентични префикси. Запишете ги опсегот и базенот во конфигурацијата на хотспотот наместо да ги препуштите на стандардна вредност.

Ако хотспотот го поседува споделениот режим на NetworkManager, прегледајте ја ефективната врска пред да додадете DHCP сервер. Споделениот режим стартува свои помошници и го вклучува препраќањето, па веќе е сопственик на планот за адреси за тој интерфејс. Додавањето втор сервер затоа што е достапен создава конкурентни понуди наместо резерва.

Одлучете за IPv6 намерно. Најавите на рутерот и DHCPv6 во многу поставки доаѓаат од друг помошник од DHCPv4, а оставањето на IPv6 вклучено додека VPN политиката покрива само IPv4 им дава на клиентите патека што го заобиколува тунелот. Или испланирајте ја страната IPv6 или онеможете ја на интерфејсот на хотспотот со напишана причина.

Кој всушност одговара на портот 53

Наведете го секој процес што слуша на портот 53 пред да смените конфигурација. На Pi што извршува локален резолвер stub, 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, директно или преку port-forward, создава барања што кружат додека не истечат. Дајте му вистински нагорен резолвер или условен forwarder за домените на кои не може да одговори.

Одлучете што се случува кога тунелот ќе падне. Враќањето на локалниот резолвер го одржува прелистувањето живо, но може да протече имиња надвор од 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 може да биде отфрлено на враќање, а клиентот е единственото место каде што се гледа целата патека.