Hotspot Pi com Pi-hole e VPN: atribua uma tarefa a cada serviço

Um telemóvel liga-se ao hotspot do Pi, recebe um endereço e a página continua a falhar. O Pi está a executar um auxiliar de hotspot, o Pi-hole e um cliente VPN, e cada um acredita ser dono de uma parte do caminho. A maioria destas montagens falha não porque um componente esteja avariado, mas porque dois componentes fazem o mesmo trabalho. Atribua um dono por função antes de ajustar qualquer um deles.

Atribua um dono por função

Aqui importam quatro funções, e cada uma precisa exatamente de um dono. A tabela abaixo indica a função, um dono viável e o que corre mal quando dois serviços a reclamam.

A sobreposição costuma chegar um pacote de cada vez. O auxiliar do hotspot instala a sua própria instância de dnsmasq, o Pi-hole quer a porta 53 e o cliente VPN acrescenta rotas. Cada passo parece razoável isolado e, em conjunto, produzem uma máquina em que o segundo serviço a arrancar altera silenciosamente o comportamento do primeiro.

Anote os donos antes de ativar qualquer outra coisa. Uma tabela curta nas notas da montagem evita que uma instalação posterior assuma uma função que já tinha dono.

Escolha um intervalo e mantenha-o longe do túnel

Escolha o intervalo do hotspot, o endereço do Pi nele, o pool DHCP e o resolvedor que os clientes recebem. Mantenha esse intervalo separado da LAN a montante e do intervalo do túnel VPN, porque sub-redes sobrepostas transformam um problema de encaminhamento num projeto de tradução de endereços. Um intervalo que se sobrepõe ao túnel torna o Pi um router acidental entre dois prefixos idênticos. Escreva o intervalo e o pool na configuração do hotspot em vez de os deixar num valor predefinido.

Se o modo partilhado do NetworkManager é o dono do hotspot, inspecione a ligação efetiva antes de acrescentar um servidor DHCP. O modo partilhado inicia os seus próprios auxiliares e ativa o encaminhamento, por isso já é o dono do plano de endereços dessa interface. Acrescentar um segundo servidor por estar disponível cria ofertas em competição em vez de redundância.

Decida o IPv6 de forma deliberada. Os anúncios de router e o DHCPv6 vêm, em muitas configurações, de um auxiliar diferente do de DHCPv4, e deixar o IPv6 ligado enquanto a política VPN só cobre IPv4 dá aos clientes um caminho que contorna o túnel. Ou planeia o lado IPv6 ou desativa-o na interface do hotspot com uma razão escrita.

Quem responde realmente na porta 53

Liste todos os processos à escuta na porta 53 antes de alterar uma configuração. Num Pi que executa um stub de resolvedor local, o Pi-hole e um auxiliar de partilha, a lista de ouvintes é o único mapa fiável de quem responde às consultas:

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

O guia de interfaces do Pi-hole explica que um modo de receção limitado a uma interface pode ainda usar um socket wildcard e descartar as chegadas noutros locais. Isso não é o mesmo que ligar apenas as interfaces selecionadas, que é a disposição prevista quando outro serviço DNS tem de partilhar a máquina.

Normalmente, dois processos não podem ligar-se ao mesmo endereço e porta, embora SO_REUSEPORT possa fazer com que uma ligação partilhada tenha êxito; mesmo assim, um ouvinte wildcard pode apanhar as chegadas destinadas ao serviço mais restrito. Escolha o modo documentado para o papel que pretende e reinicie os serviços pela ordem prevista.

Mantenha a página de administração do Pi-hole fora da rede do hotspot. Os clientes precisam de um resolvedor, não da interface web ou da API que pode alterar a configuração do resolvedor.

Dois troços DNS, uma política para cada

Uma consulta de um cliente viaja do telemóvel até ao Pi, e uma consulta separada viaja do Pi até ao seu resolvedor a montante. Uma regra de encaminhamento que corresponde ao tráfego reencaminhado do hotspot não se aplica automaticamente ao segundo troço, porque o Pi gera esse tráfego localmente. Se a VPN deve transportar o DNS, o caminho local precisa da sua própria política.

Esteja atento a ciclos. Apontar o upstream do Pi-hole para um endereço servido pelo próprio Pi, diretamente ou através de um port-forward, produz consultas que circulam até expirarem. Dê-lhe um upstream real ou um forwarder condicional para os domínios a que não consegue responder.

Decida o que acontece quando o túnel cai. Recuar para o resolvedor local mantém a navegação viva mas pode deixar escapar nomes para fora da VPN; bloquear mantém a política intacta e transforma a falha num erro visível. Qualquer das escolhas é defensável, mas tem de ser escolhida em vez de herdada de um valor predefinido.

Comprove o caminho e o comportamento em caso de falha

Teste por camadas: o cliente recebe um endereço, o cliente resolve um nome através do Pi, o Pi resolve através do upstream previsto e uma aplicação conclui um pedido. Um ping bem-sucedido não diz nada sobre DNS, e uma consulta bem-sucedida não diz nada sobre encaminhamento.

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

Depois pare o túnel e repita. O comportamento previsto deve aparecer dentro de poucos segundos, não após um reinício manual do Pi-hole ou do serviço de hotspot. Verifique a definição do resolvedor do cliente durante a falha, porque um resolvedor público secundário continuará a responder mesmo quando a política esperava uma falha.

Mantenha um único dono para o encaminhamento e o NAT e verifique-o a partir de um cliente, não do próprio Pi. Um pedido que sai do Pi com sucesso pode ainda ser descartado no regresso, e o cliente é o único local onde todo o caminho é visível.