VPN Pi com vários routers: coloque cada rota no dispositivo que decide

Colocar uma caixa Wi-Fi atrás do Pi transforma uma decisão de encaminhamento em quatro, e o plano quebra quando as quatro são tomadas num só dispositivo. A primeira pergunta não é que rota acrescentar. É se a nova caixa faz ponte ou encaminha, porque essa resposta decide quantas sub-redes existem e que dispositivos têm de aprender sobre elas. Escolha primeiro o modelo de ligação; cada rota decorre dele.

Ponte ou encaminhamento: a escolha que fixa a contagem

Uma ponte coloca os novos clientes na mesma sub-rede que o Pi já serve. Uma sub-rede, uma autoridade DHCP e nenhuma passagem para encaminhar. Esta é a disposição mais simples e a correta quando uma rede de clientes separada nunca foi um requisito. Uma ligação encaminhada é um desenho diferente: a caixa mantém a sua própria sub-rede, e esse prefixo tem de ser transportado para todo o lado onde o tráfego vai.

O resto deste plano mantém o router a jusante e preserva os endereços de origem dos clientes. O objetivo é uma rede VPN privada, não uma saída completa para a internet. Escreva o modelo antes dos endereços, porque a lista abaixo é apenas um exemplo de ligação encaminhada.

client subnet       10.41.0.0/24
client gateway      10.41.0.1
router-to-Pi link   192.168.71.2
Pi on that link     192.168.71.1
private target      10.72.9.0/24

Quem decide o quê

Cada dispositivo toma uma decisão, e nenhum pode tomar a de outro no seu lugar. O Pi precisa de duas entradas, não de uma, e o caminho de volta é o que as pessoas esquecem. O tráfego reencaminhado chega corretamente à rede privada e depois morre no caminho de volta, porque o Pi não faz ideia de onde vive 10.41.0.0/24. Isso parece um problema de firewall e na realidade é uma rota em falta.

O lado remoto também precisa da sua própria rota. Se o serviço no extremo remoto não sabe que 10.41.0.0/24 é alcançável pelo seu túnel, as respostas param no primeiro salto sem resposta. Acrescente as duas direções antes de ler filtros de pacotes.

Os próximos saltos vêm da ligação

O próximo salto tem de ser um endereço numa rede que o dispositivo possa realmente alcançar. O endereço público do par VPN não é o próximo salto para uma sub-rede privada, e a rede de serviço remota não é de todo um próximo salto. Uma rota para um gateway inalcançável parece correta numa lista e descarta todos os pacotes. Verifique se o gateway responde antes de culpar o destino.

Mantenha o par VPN exterior do Pi alcançável através da sua própria rota de subcamada. Essa entrada está separada das rotas de carga útil, e misturá-las dá um túnel que não consegue restabelecer-se depois de uma mudança de caminho.

A documentação de rotas estáticas torna clara a distinção entre destino e gateway, embora cada plataforma nomeie os seus menus de forma diferente. Leia a documentação do dispositivo à sua frente em vez de copiar o ecrã de outro fornecedor. Os comandos abaixo mostram a forma das entradas em Linux.

# on the Pi
ip route add 10.41.0.0/24 via 192.168.71.2
ip route add 10.72.9.0/24 dev tun0
# on the downstream router
ip route add 10.72.9.0/24 via 192.168.71.1

O que a tradução faz à origem

Se o router a jusante já traduz os seus clientes para o endereço de trânsito, o Pi vê uma única origem traduzida em vez do endereço próprio de cada cliente. É um desenho diferente do que preserva a origem acima. Altera a política baseada na origem, o registo e que lado pode iniciar ligações. Ambos os desenhos funcionam; respondem a perguntas diferentes.

Quando um serviço VPN a montante recusa encaminhar o prefixo do cliente de volta, uma tradução estreita na saída do túnel do Pi pode ser uma solução legítima. Não é prova de que a rota em falta fosse desnecessária. Registe que endereço a rede remota vê realmente e que caminho de volta resulta.

A seleção de rota, a permissão de reencaminhamento e a tradução de origem continuam a ser três tarefas separadas. Esvaziar uma cadeia NAT partilhada ou permitir todas as interfaces porque um cliente com cabo funciona é como um teste que funciona se torna um reencaminhador aberto.

Provar isso a partir de uma máquina cliente

Envie um pedido a partir de uma máquina na LAN a jusante e depois siga a sua origem para fora e de volta. Um ping emitido pelo Pi nunca exercita a rota de volta a jusante, por isso um ping bem-sucedido prova menos do que parece. Acrescente um segundo teste a partir de um cliente com cabo na própria LAN do Pi para que os dois caminhos possam ser comparados. Repita ambos depois de reiniciar qualquer um dos dispositivos.

As rotas acrescentadas à mão e as traduções que nunca foram guardadas desaparecem juntas. Então o par parece uma avaria nova em vez de trabalho inacabado.

Guarde o modelo de ligação juntamente com as rotas, o serviço privado permitido e qualquer tradução numa só nota. É essa nota que impede a próxima pessoa de tratar a colocação sem fios como uma questão de política de encaminhamento.