Clientes a jusante atrás de uma VPN a montante: rota ou NAT?

Um gateway executa WireGuard para os seus próprios dispositivos e um cliente OpenVPN para a rede de outra pessoa. O encaminhamento entre as duas interfaces internas funciona, e é fácil concluir que a sub-rede a jusante passou a fazer parte do serviço a montante. Não é o caso. A rota obtida pelo cliente diz ao seu gateway para onde enviar os pedidos; não diz nada sobre como a rede remota devolve o tráfego a dispositivos de que nunca ouviu falar. Escolha um modelo de retorno que o serviço a montante suporte de facto antes de acrescentar uma única regra.

Decida o modelo de retorno antes de mexer no encaminhamento

Neste guia, os clientes a jusante utilizam 10.90.0.0/24, o endereço do túnel a montante atribuído ao gateway é 10.80.0.6 e o recurso remoto aprovado é 172.20.0.30. Dois modelos encaixam nesta forma: preservar a origem a jusante e conseguir que o lado remoto a encaminhe, ou traduzir a origem para o endereço do túnel do próprio gateway. Tudo o que vem depois desta decisão é mecânico, e a decisão em si exige o proprietário do serviço. Uma das linhas acima é um acordo de encaminhamento com o lado remoto; a outra é uma alteração de política local que pode fazer sozinho. Confundir as duas é o que transforma uma alteração de dez minutos numa negociação.

preserved:  10.90.0.23 -> 172.20.0.30
translated: 10.80.0.6  -> 172.20.0.30

Escolha uma linha e assuma-a. As linhas são alternativas, não passos, e misturá-las produz um desenho que ninguém consegue explicar na revisão.

Preservação da origem com encaminhamento

O lado remoto recebe um pedido de um endereço a jusante, por isso precisa de uma rota suportada e da propriedade do peer para essa sub-rede, além de autorização para a aceitar. São definições remotas, e nenhuma rota local do Linux as cria. Peça-as de forma explícita e por escrito, com o prefixo e o peer do túnel que a vai transportar, e conte com uma resposta que depende de o serviço suportar ou não arranjos site-to-site.

Se a resposta for sim, a configuração local é pequena: encaminhamento ativo, os allowed-ips do peer WireGuard que cobrem o intervalo a jusante, e uma política de firewall que permite a travessia nos dois sentidos.

Tradução de origem deliberada

Se o serviço só devolve tráfego ao endereço do cliente ligado, traduza a origem para esse endereço à saída e mantenha o estado conntrack que a inverte para as respostas. Limite a regra às origens a jusante pretendidas, aos destinos remotos pretendidos e à interface a montante. Uma regra que traduz tudo o que sai de cada interface é uma política muito maior do que este requisito, e vai surpreendê-lo mais tarde.

O IPv6 precisa de um desenho próprio; copiar uma linha masquerade de IPv4 não é arquitetura. Teste o caminho traduzido com uma ligação nova em vez de uma em cache.

O caminho de dados local continua a ter de funcionar

A tradução não elimina o trabalho local: o gateway continua a precisar de uma rota para os destinos a jusante, da propriedade correta da origem do peer WireGuard, do encaminhamento ativo e de uma política de firewall estreita entre interfaces. Um pedido gerado no próprio gateway não exercita nenhuma dessas permissões, e é por isso que os testes locais no gateway passam e os dispositivos a jusante continuam a falhar.

Teste a partir de um dispositivo a jusante real, não do gateway. O endereço de origem é todo o sentido do exercício.

Uma origem significa uma identidade de sessão

O serviço remoto vê a sessão autenticada do gateway e o seu endereço traduzido, não uma autenticação independente para cada dispositivo a jusante. Mantenha explícitas as permissões por dispositivo e as identidades das aplicações, e confirme com o proprietário do serviço que um gateway a atuar por vários dispositivos é sequer permitido. A tradução não é forma de contornar um requisito de registo por dispositivo; se o serviço exigir que cada dispositivo se registe, use esse modelo ou negoceie um arranjo site-to-site.

Escreva essa confirmação no runbook ao lado da regra, porque o próximo revisor vai perguntar se o desenho foi aprovado ou apenas conveniente.

Defina o estado desligado e depois teste três pedidos

Decida o que acontece quando o túnel a montante cai. O tráfego remoto autorizado não deve seguir em silêncio um recurso WAN comum onde isso é proibido, pelo que a política de firewall que permite a travessia também deve falhar fechada. Depois teste três casos a partir de um dispositivo a jusante real: um pedido permitido que funciona, um pedido não permitido que falha, e uma falha a montante que trava o permitido.

Registe a reversão numa linha por regra, para que a alteração possa ser desfeita sem reconstruir a intenção.