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

Одлучите ко поседује DHCP, DNS и прослеђивање пакета пре него што укључите три помоћника на једном Pi. Дупли власници стварају конкурентне закупе и петље у резолверу.

Телефон се придружује хот-споту Pi, добија адресу, а страница и даље не успева. Pi покреће помоћника за хот-спот, Pi-hole и VPN клијент, и сваки од њих мисли да поседује део путање. Већина ових поставки не пада зато што је компонента покварена, него зато што две компоненте раде исти посао. Доделите једног власника по функцији пре него што било шта од тога подесите.

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

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

FunctionWorkable ownerDuplicate-owner symptom
Client addressesOne DHCP server, such as the hotspot helperCompeting offers and changing leases
DNS receptionPi-hole on port 53Bind failure or queries answered by the wrong process
Forwarding and NATOne firewall managerDouble translation and broken return paths
VPN routingOne client configurationRoute flapping and traffic escaping outside the tunnel

Преклапање обично долази један пакет по један. Помоћник за хот-спот инсталира своју инстанцу 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 још увек може бити одбачен на повратку, а клијент је једино место где је цела путања видљива.

Повезани чланци