Punto de acceso Pi con Pi-hole e VPN: asigna un traballo a cada servizo

Un teléfono únese ao punto de acceso do Pi, recibe unha dirección e a páxina segue fallando. O Pi executa un axudante de punto de acceso, Pi-hole e un cliente VPN, e cada un cre que é dono dunha parte do camiño. A maioría destas montaxes fallan non porque un compoñente estea roto, senón porque dous compoñentes fan o mesmo traballo. Asigna un dono por función antes de axustar calquera deles.

Asigna un dono por función

Aquí importan catro funcións, e cada unha necesita exactamente un dono. A táboa seguinte indica a función, un dono viable e o que sae mal cando dous servizos a reclaman.

A superposición adoita chegar paquete a paquete. O axudante do punto de acceso instala a súa propia instancia de dnsmasq, Pi-hole quere o porto 53 e o cliente VPN engade rutas. Cada paso parece razoable por separado e, xuntos, producen unha máquina na que o segundo servizo en arrincar cambia en silencio o comportamento do primeiro.

Anota os donos antes de activar calquera outra cousa. Unha táboa curta nas notas da montaxe evita que unha instalación posterior asuma unha función que xa tiña dono.

Escolle un rango e mantelo afastado do túnel

Escolle o rango do punto de acceso, o enderezo do Pi nel, o conxunto DHCP e o resolvedor que reciben os clientes. Mantén ese rango separado da LAN de saída e do rango do túnel VPN, porque as subredes solapadas converten un problema de encamiñamento nun proxecto de tradución de enderezos. Un rango que se solapa co túnel fai que o Pi sexa un router accidental entre dous prefixos idénticos. Escribe o rango e o conxunto na configuración do punto de acceso en vez de deixalos nun valor por defecto.

Se o modo compartido de NetworkManager é o dono do punto de acceso, inspecciona a conexión efectiva antes de engadir un servidor DHCP. O modo compartido inicia os seus propios axudantes e activa o reenvío, así que xa é o dono do plan de enderezos desa interface. Engadir un segundo servidor porque está dispoñible crea ofertas en competencia en lugar de redundancia.

Decide o IPv6 de forma deliberada. Os anuncios de router e o DHCPv6 proveñen dun axudante distinto do de DHCPv4 en moitas configuracións, e deixar o IPv6 activo mentres a política VPN só cobre IPv4 dá aos clientes un camiño que evita o túnel. Ou planificas o lado IPv6 ou o desactivas na interface do punto de acceso cunha razón escrita.

Quen responde realmente no porto 53

Enumera todos os procesos que escoitan no porto 53 antes de cambiar unha configuración. Nun Pi que executa un stub local de resolvedor, Pi-hole e un axudante de compartición, a lista de oíntes é o único mapa fiable de quen responde ás consultas:

sudo ss -lunpt '( sport = :53 )'
ip -4 addr show
ip route

A guía de interfaces de Pi-hole explica que un modo de recepción limitado a unha interface pode aínda usar un socket comodín e descartar as chegadas noutros sitios. Iso non é o mesmo que vincular só as interfaces seleccionadas, que é a disposición prevista cando outro servizo DNS debe compartir a máquina.

Normalmente dous procesos non poden vincular o mesmo enderezo e porto, aínda que SO_REUSEPORT pode facer que unha vinculación compartida teña éxito; aínda así, un oínte comodín pode tomar as chegadas destinadas ao servizo máis restrinxido. Escolle o modo documentado para o papel que queres e reinicia os servizos na orde prevista.

Mantén a páxina de administración de Pi-hole fóra da rede do punto de acceso. Os clientes necesitan un resolvedor, non a interface web ou a API que pode cambiar a configuración do resolvedor.

Dous treitos DNS, unha política para cada un

Unha consulta dun cliente viaxa do teléfono ao Pi, e unha consulta separada viaxa do Pi ao seu resolvedor de saída. Unha regra de encamiñamento que coincide co tráfico reenviado do punto de acceso non se aplica automaticamente ao segundo treito, porque o Pi xera ese tráfico localmente. Se se supón que a VPN transporta o DNS, a ruta local necesita a súa propia política.

Vixía os bucles. Apuntar o resolvedor de saída de Pi-hole a un enderezo que o propio Pi serve, directamente ou mediante un porto reenviado, produce consultas que circulan ata que expiran. Dálle un resolvedor de saída real ou un reenviador condicional para os dominios que non pode responder.

Decide que ocorre cando cae o túnel. Volver ao resolvedor local mantén a navegación viva pero pode filtrar nomes fóra da VPN; bloquear mantén a política intacta e converte a caída nun erro visible. Calquera das dúas opcións é defendible, pero hai que escollela en vez de herdala dun valor por defecto.

Proba o camiño e o comportamento na caída

Proba por capas: o cliente recibe un enderezo, o cliente resolve un nome a través do Pi, o Pi resolve a través do resolvedor de saída previsto e unha aplicación completa unha petición. Un ping correcto non di nada sobre o DNS, e unha consulta correcta non di nada sobre o reenvío.

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

Despois detén o túnel e repite. O comportamento previsto debería aparecer nuns segundos, non tras reiniciar manualmente Pi-hole ou o servizo do punto de acceso. Comproba a configuración do resolvedor do cliente durante a caída, porque un resolvedor público secundario seguirá respondendo aínda que a política esperase un fallo.

Mantén un único dono para o reenvío e o NAT e verifícao desde un cliente, non desde o propio Pi. Unha petición que sae do Pi con éxito pode aínda caer na volta, e o cliente é o único lugar onde se ve todo o camiño.