hostapd e OpenVPN num só Pi: de quem é a rota padrão?

hostapd e um cliente OpenVPN podem partilhar um Pi quando a bridge mantém a sua própria rota padrão e o túnel mantém um caminho até ao seu servidor. Comandos e reversão.

Os telefones associam-se ao ponto de acesso, recebem um endereço e depois não alcançam nada assim que o túnel sobe. O hostapd costuma estar saudável nesse estado, e o OpenVPN também; o que se parte é a rota padrão, que ou nunca existiu na bridge ou foi substituída pelo túnel sem deixar um caminho para o próprio servidor VPN. Este guia devolve essa rota ao seu lugar e prova o resultado a partir de um cliente e não do Pi. Cada passo é reversível, e nada aqui altera a configuração do túnel até saber que tráfego quer dentro dele.

Inventarie as interfaces antes de editar seja o que for

A disposição habitual coloca a rádio sem fios e a porta com fios dentro de br0, inicia o hostapd contra a bridge e distribui concessões a partir do dnsmasq, enquanto um cliente OpenVPN cria tun0. Então três requisitos separados parecem um só: os clientes do ponto de acesso precisam do Pi como gateway, o Pi precisa de uma rota para a internet para alcançar o seu servidor, e a bridge precisa de um endereço de gateway que esses clientes possam usar.

Leia o estado atual antes de o alterar, porque estes quatro comandos separam um problema de interface de um problema de encaminhamento.

ip -br addr
ip route show
ip link show master br0
bridge link show

Se br0 tem um endereço mas nenhuma rota padrão, os clientes chegam ao Pi e a nada para lá dele. Se a rota padrão aponta para tun0 enquanto o túnel está em baixo, o Pi não tem caminho nenhum a funcionar, e o sintoma do cliente parece exatamente igual. Os dois casos parecem idênticos a partir de um telefone, por isso a tabela de rotas tem de ser lida diretamente.

Dê à bridge uma rota padrão que lhe pertença

O Raspberry Pi OS deixa muitas vezes a bridge sem rota padrão quando a bridge surgiu depois de o ficheiro de interface ter sido escrito. O bloco pertence a /etc/dhcpcd.conf, e deve nomear o router a montante em vez do Pi.

interface br0
static ip_address=192.168.50.2/24
static routers=192.168.50.1
static domain_name_servers=192.168.50.1

Nesse exemplo 192.168.50.1 é o router existente e 192.168.50.2 é o endereço da bridge do Pi na mesma sub-rede, por isso substitua pelo seu próprio plano em vez de copiar os números. Os membros da bridge também não devem pedir routers, ou o Pi fica com rotas padrão concorrentes cujo vencedor depende da métrica e do momento e não da intenção.

Depois de systemctl restart dhcpcd, ip route show default deve listar br0 uma vez e nenhum duplicado da porta com fios. Confirme a consulta e não a tabela, porque uma entrada antiga pode ficar ao lado de uma vencedora: ip -4 route get 203.0.113.10 tem de nomear br0. Esse endereço vem do intervalo de documentação TEST-NET-3, por isso não pode colidir com um servidor real enquanto lê isto.

Impeça o túnel de raptar o caminho para o seu próprio servidor

Um cliente OpenVPN que aceita redirect-gateway toma a rota padrão e aponta-a para dentro do túnel. Isso está certo quando todos os clientes do ponto de acesso devem usar a VPN, e errado quando só alguns destinos devem. De qualquer forma, a ligação do próprio Pi ao servidor não pode viajar dentro do túnel que ainda está a construir. O OpenVPN acrescenta uma rota de host até ao remoto através do gateway original quando redireciona a rota padrão, e é exatamente esse comportamento que mantém o transporte vivo; se essa rota faltar, o túnel colapsa assim que se estabelece.

Uma comparação rápida desse caminho de transporte antes e depois da ligação vale os dez segundos. ip -4 route get 203.0.113.10 deve nomear o dispositivo subjacente nos dois estados, com apenas a métrica a mudar. Se nomear tun0 depois de o túnel subir, a rota de host nunca foi instalada e a próxima reconexão falhará.

Quando só prefixos selecionados devem atravessar o túnel, use route-nopull e acrescente as rotas que quiser à mão, ou envie um conjunto mais estreito a partir do servidor. A bridge conserva a rota padrão nesse desenho, e o DNS passa a ser a decisão seguinte: o encaminhamento do dnsmasq para um resolver de casa só faz sentido para os nomes que realmente vivem lá.

Decida a história do encaminhamento e do NAT

Um túnel completo exige o encaminhamento ativado no Pi e um gateway do lado remoto disposto a encaminhar a sub-rede do ponto de acesso. Verifique o encaminhamento antes de tudo o resto, porque um zero torna qualquer mudança de rota irrelevante.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADE

A regra NAT é o atalho que funciona quando o servidor não aceita o prefixo do ponto de acesso, ao custo de cada cliente aparecer como o endereço do túnel do Pi nos registos do lado remoto. Encaminhar o prefixo sem NAT mantém os endereços visíveis e depende de uma rota de retorno para 192.168.50.0/24 do lado de casa.

Anote a escolha junto às regras da firewall, porque uma regra NAT invisível no desenho torna-se inexplicável seis meses depois. Mantenha o IPv6 na mesma decisão; um caminho IPv4 a funcionar ao lado de um caminho IPv6 quebrado continua a ler-se como meio quebrado num navegador.

Verifique a partir de um cliente e depois reverta de forma limpa

Teste nesta ordem a partir de um telefone ou portátil no ponto de acesso: uma concessão do dnsmasq, um ping ao endereço da bridge, e depois um destino do outro lado do túnel. Cada passo isola uma camada em vez de produzir uma única falha inútil.

ip -4 route get 203.0.113.10
ping -c 3 -I br0 203.0.113.10

Depois confirme que o Pi continua a ter a sua própria saída: ip route get 203.0.113.10 deve nomear o dispositivo subjacente, e ping -c 3 -I br0 203.0.113.10 deve responder se o servidor permitir ICMP. Se os dois primeiros passos do cliente passarem e o terceiro falhar, a falha está no encaminhamento ou no NAT. Se o segundo passo falhar, a bridge ou o DHCP ainda estão incompletos.

A reversão é uma edição de ficheiro e dois comandos: remova o bloco, reinicie o dhcpcd e substitua a rota padrão explicitamente por ip route replace default via 192.168.50.1 dev br0. Faça-o antes de a janela de manutenção fechar e não depois, porque um Pi que perdeu a rota padrão é inalcançável a partir da rede que usaria para o reparar.

Artigos relacionados