Hotspot VPN em bridge: qual rota padrão o telemóvel usa?

O telemóvel no seu hotspot em bridge obtém o endereço e o gateway de algum lugar, e essa não é a rota padrão do Pi. Alterar a rota padrão do Pi muda para onde o Pi envia o seu próprio tráfego. O telemóvel continua a usar o gateway que lhe foi indicado, e quando esse gateway está na LAN remota, as suas tramas atravessam simplesmente a bridge. Dois consumidores, duas decisões. Separá-las explica a maioria dos relatos de um hotspot sem internet enquanto o próprio Pi está bem.

Dois dispositivos, duas decisões de gateway diferentes

O Pi tem a sua própria pilha IP e a sua própria rota padrão. O telemóvel tem a sua própria pilha IP e a sua própria rota padrão.

Essa tabela é todo o modelo. O gateway do telemóvel é um endereço na LAN remota, e as suas tramas são encaminhadas na camada 2 para esse router. A rota padrão do Pi diz respeito ao seu próprio transporte exterior, que tem de alcançar o par VPN pelo uplink de viagem.

Uma bridge encaminha tramas, não encaminha pacotes

Uma bridge Linux encaminha tramas Ethernet pelo MAC de destino, e é tudo o que faz entre as suas portas. A trama do telemóvel endereçada ao MAC do router remoto é comutada para a porta TAP e atravessa o túnel sem tocar na tabela de routing do Pi. É por isso que uma rota padrão avariada do Pi pode deixar o telemóvel a funcionar, e é por isso que uma correta não consegue reparar um telemóvel que recebeu o gateway errado.

TAP transporta tramas Ethernet e pode ser uma porta de bridge. TUN transporta pacotes IP e não pode. Se o seu desenho substituiu um pelo outro, a bridge não é uma bridge e o resto disto não se aplica.

Decida quem distribui o lease do telemóvel

A opção 3 do DHCP é a opção de router, e diz ao cliente que gateway usar para a sua sub-rede. Quando o servidor DHCP da LAN remota é o único distribuidor, o telemóvel obtém um gateway remoto e o desenho é coerente. Quando outra coisa do lado da viagem responde primeiro, o telemóvel obtém um gateway local, o seu tráfego de internet sai pelo uplink de viagem e o seu tráfego para a LAN remota não tem caminho nenhum.

Execute um único distribuidor para esse domínio de difusão, e registe o que distribui.

O Pi é um caso à parte mesmo quando obtém um endereço do mesmo lease. Decida deliberadamente se deve instalar as rotas que o lease oferece, porque uma rota padrão remota importada pode arrastar o transporte VPN do próprio Pi para o túnel que está a tentar manter vivo. Com systemd-networkd essa decisão é UseRoutes= na secção DHCP; com dhclient é a opção routers na lista de pedidos.

Mantenha o uplink fora da LAN em bridge

A interface que transporta a ligação VPN exterior do Pi não deve tornar-se uma porta de bridge. Se se tornar, o transporte cifrado é comutado para a LAN estendida e o túnel acaba por transportar os seus próprios pacotes exteriores, o que falha de uma forma que parece perda de pacotes em vez de um ciclo. Mantenha também explícitas a capacidade de AP e o suporte de bridge. Uma interface sem fios em modo station normalmente não pode ser porta de bridge, porque o cabeçalho 802.11 não tem espaço para o segundo endereço MAC de que uma bridge precisa.

Defina o domínio de difusão estendido, um plano de endereços e a filtragem de tramas que realmente quer. Permitir o ouvinte VPN no Pi não dá a cada cliente em bridge acesso aos serviços de gestão do Pi. São regras separadas, e tratá-las como uma só é como um hotspot se transforma silenciosamente numa porta aberta.

Teste as quatro coisas separadamente quando falha

Quando o telemóvel não consegue alcançar a LAN remota, quatro observações separam as causas. Execute-as nesta ordem e pare na primeira que falhar.

ip route show default
bridge link show
ip -4 neigh show dev br0
tcpdump -ni br0 arp or icmp

Comece pelo lease: o telemóvel tem um endereço e um gateway na sub-rede remota? Depois veja a bridge e confirme que a porta AP e a porta TAP ambas encaminham. Depois leia a tabela de vizinhos, porque uma entrada não resolvida para o router remoto significa que as tramas saem e nada responde. Por fim observe as tramas na bridge enquanto o telemóvel faz ping, o que lhe diz se a avaria está abaixo de IP ou não.

Registe qual dispositivo é dono de cada rota padrão quando terminar. Uma linha de documentação transforma a saída local versus remota numa decisão consciente do cliente, e a referência da bridge merece ficar ao lado.