Clientes do hotspot num Pi não alcançam a LAN de casa por uma VPN TUN

Os clientes Wi-Fi e Ethernet locais ligam-se ao hotspot do Pi, obtêm um endereço do seu âmbito DHCP e carregam páginas de internet sem queixas. Os mesmos clientes depois esgotam o tempo quando abrem uma partilha de ficheiros ou uma interface web na LAN de casa, enquanto o próprio Pi alcança essa LAN pelo túnel. Nada na camada sem fios está quebrado. O que falta é um contrato encaminhado: o prefixo do hotspot tem de ser transportado para a interface TUN, e algo do lado de casa tem de saber como enviar as respostas de volta. As duas metades têm de existir antes de um único pacote conseguir completar a viagem de ida e volta.

Três ligações com três tarefas diferentes

Uma ponte Ethernet Linux reencaminha tramas pelo endereço MAC de destino. OpenVPN em modo TUN transporta pacotes IP e não tem camada MAC nenhuma, por isso acrescentar uma ponte local nunca regista o túnel como porta. A documentação do kernel sobre TUN/TAP explica essa separação: um dispositivo TAP parece uma interface Ethernet, um dispositivo TUN não. Um desenho que liga duas portas locais em ponte e depois encaminha é um router, diga o que disserem os nomes das interfaces.

Essa distinção decide a propriedade. A sub-rede dos clientes, o gateway predefinido e a autoridade DHCP desse âmbito pertencem ao plano local do Pi. As difusões DHCP de casa não atravessam um túnel encaminhado, e nenhum ajuste de ponte muda isso; apontar os clientes para um servidor DHCP de casa é um desenho de relay separado e deliberado, com os seus próprios modos de falha.

Mantenha também o modem fora da ponte de clientes. Uma ligação PPP não é um dispositivo Ethernet com outra etiqueta, e a lógica documentada de rota predefinida do pppd corre após a negociação IPCP e retira a sua rota quando essa ligação cai. Copiar um modelo DHCP e renomear cada usb0 para ppp0 não prova nada sobre gateway, métrica ou ciclo de vida.

Escolha os prefixos antes de editar qualquer configuração

Prefixos sobrepostos gastam mais noites do que regras de firewall, porque uma sobreposição envia a procura de rota para a interface errada mesmo quando o túnel está saudável. Comece por listar o que já existe no Pi e depois leia o resultado como quatro reservatórios separados.

ip -4 addr show scope global
ip -4 route show table main
ip -4 route get 192.168.77.10

O primeiro reservatório é o endereço underlay que o operador deu ao modem; tem de ficar fora de todo o plano virado para os clientes. O segundo é a sub-rede do túnel que o servidor escolheu, muitas vezes uma /24 privada sua. O terceiro é a ponte do hotspot, e o quarto é o prefixo de casa que quer alcançar. Neste percurso o hotspot recebe 172.28.90.0/24 com a ponte em 172.28.90.1, e a LAN de serviços de casa mantém 192.168.77.0/24, o que evita as predefinições 192.168.1.0/24 e 10.0.0.0/24 que os routers de consumo trazem e o intervalo de operador 100.64.0.0/10.

Anuncie o endereço da ponte como gateway no âmbito DHCP do hotspot e nada mais. Nunca dê aos clientes do hotspot um endereço de casa como gateway; não têm caminho ao nível da ligação para esse segmento.

Encaminhe cada direção no lado que a possui

O Pi precisa de uma rota para o prefixo de casa através do túnel. Os servidores em modo servidor normalmente empurram essa rota, por isso confirme primeiro que o reencaminhamento está ativo e que o kernel resolve um endereço de casa a partir de tun0.

sysctl net.ipv4.ip_forward
ip route add 192.168.77.0/24 dev tun0
ip -4 route get 192.168.77.10

Se ip route get ainda reporta a interface underlay, pare aí; nada mais à frente no caminho pode reparar uma procura errada.

Os dispositivos de casa não têm rota para 172.28.90.0/24, por isso as suas respostas seguem o gateway predefinido e morrem no router. Existem duas reparações suportadas. Ou acrescenta uma rota estática no router de casa que aponta o prefixo do hotspot para o endereço LAN do servidor VPN, ou, quando o servidor é ele próprio o gateway, registra o prefixo do cliente na tabela de encaminhamento do próprio servidor. No modo multi-cliente do OpenVPN o diretório específico do cliente transporta essa associação: um ficheiro com o nome comum do certificado do cliente, contendo iroute 172.28.90.0 255.255.255.0 mais a linha route correspondente que a instala no kernel do servidor. Uma rota de kernel adivinhada no servidor não é a mesma declaração que dizer ao servidor qual cliente possui o prefixo.

Não mova o serviço DHCP da rede de casa para o servidor VPN para fazer isto funcionar. Substituir o gateway predefinido de uma casa inteira é uma mudança muito maior do que acrescentar uma rota de retorno privada, e arrasta DNS, reservas de endereços e todos os dispositivos que ignoram o novo aluguer para a falha.

Abra o reencaminhamento sem adivinhar a firewall

O reencaminhamento ativo não significa que o pacote tenha permissão para passar. O tráfego da ponte para o túnel continua a bater nas regras de filtragem, e uma política de reencaminhamento predefinida drop descarta o tráfego do hotspot enquanto o tráfego do próprio Pi continua a funcionar, o que produz exatamente o sintoma dividido acima.

iptables -S FORWARD
iptables -t nat -S POSTROUTING
nft list ruleset

Procure uma regra de aceitação de br0 para tun0 e a direção de resposta correspondente, e uma regra postrouting que possa reescrever a origem. Se a política da cadeia for drop e nenhuma regra corresponder, acrescente as aceitações estreitas e volte a testar em vez de virar a política para accept.

A tradução é uma escolha de política, não um requisito. O NAT de origem para a LAN de casa faz cada cliente do hotspot parecer o endereço do túnel do Pi, o que perde a atribuição por cliente nos registos de casa e quebra serviços que esperam a origem original. O encaminhamento sem NAT mantém os endereços dos clientes visíveis mas depende da rota de retorno acima. Escolha uma e trate DNS e IPv6 da mesma forma, porque um caminho IPv4 a funcionar ao lado de um caminho IPv6 quebrado continua a ler-se como meio quebrado no navegador.

Verifique a viagem de ida e volta e depois quebre-a de propósito

Teste a partir de um cliente do hotspot, nunca a partir do Pi, porque o tráfego do próprio Pi evita tanto o caminho de ida como o de volta. Observe as duas interfaces enquanto um cliente tenta alcançar um serviço de casa.

tcpdump -ni br0 host 192.168.77.10
tcpdump -ni tun0 host 192.168.77.10
ping -c 3 192.168.77.10

Leia as duas capturas em conjunto. Os pedidos em br0 que nunca aparecem em tun0 significam que o Pi não reencaminha ou que a rota aponta para outro sítio. Os pedidos em tun0 sem respostas significam que o lado de casa não tem rota de retorno ou que o servidor filtrou o pacote. As respostas em tun0 que nunca reaparecem em br0 significam que falta a regra de filtragem inversa, onde o túnel parece perfeito e o cliente continua a não ver nada.

Depois quebre o caminho deliberadamente. Desligue a ligação do modem e volte a ligá-la e execute de novo as verificações de rota e captura; uma rota que sobrevive ao túnel mas desaparece ao reconectar pertence ao perfil de ligação, não a um comando pontual. Confirme que o transporte do túnel continua a sair pelo underlay e não por si mesmo, o ciclo clássico quando uma rota predefinida empurrada é aceite sem uma rota de host para o par.

Aceite o desenho só quando um cliente do hotspot conseguir resolver um nome de casa, abrir um serviço TCP e manter uma sessão viva ao longo de uma reconexão do modem. Se uma aplicação exigir mesmo descoberta ao nível Ethernet no segmento de casa, escolha um desenho Layer 2 suportado em vez de descrever a ponte local como ligada em ponte e esperar que a difusão apareça.