LAN atrás de uma sessão do AWS Client VPN: o que é encaminhado

O portátil liga-se ao endpoint do AWS Client VPN, chega à sub-rede privada e tudo parece saudável. O desktop na mesma LAN não chega a nada, embora o host Linux também tenha uma interface de ponte e ambas as máquinas estejam no mesmo cabo. Nada está mal configurado no túnel; a peça em falta é o encaminhamento, e a ponte é uma pista falsa.

Estender uma sessão de Client VPN a uma LAN é um papel de gateway. Não é um segmento Ethernet esticado para dentro de um serviço gerido.

O host funciona e a LAN não

A interface de túnel da máquina Linux tem um endereço dentro do CIDR do cliente de Client VPN, e o endpoint enviou rotas para os intervalos da VPC. Um pedido feito nessa máquina é tráfego gerado localmente: escolhe uma rota, sai pelo túnel e recebe uma resposta. Esse caminho nunca toca no código de encaminhamento, na interface LAN nem em qualquer regra de firewall que governe o trânsito.

O tráfego de outro dispositivo da LAN é um fluxo diferente. Chega à interface LAN, precisa de uma rota que aponte para o túnel, precisa do encaminhamento ativo, precisa de uma firewall que o permita e precisa que a resposta volte pelo mesmo host. Quatro requisitos, e o teste que funciona no portátil não prova nenhum. Do desktop a falha parece estranha: o túnel está ativo, as credenciais são válidas e o destino simplesmente nunca responde. O defeito é local ao caminho de encaminhamento do gateway, não ao serviço.

Nem todo cliente pode ser um gateway

A AWS afirma que a sua aplicação de desktop Client VPN não suporta encaminhamento IP, e que outros clientes podem suportar. Essa restrição decide a arquitetura antes de qualquer comando ser escrito. Se o único cliente disponível for a aplicação oficial de desktop, um gateway Linux que encaminha para a LAN não é uma configuração que possa terminar, e nenhuma quantidade de masquerading o mudará.

O cliente substituto também tem de corresponder ao método de autenticação do endpoint e à política que pretende aplicar. Endpoints baseados em certificados, em diretório e com SAML não aceitam as mesmas configurações de cliente, e um cliente de terceiros que se autentica mas ignora as rotas enviadas não é uma melhoria.

Trate a escolha do cliente como parte da revisão do desenho. Determina se o padrão de encaminhamento de LAN está disponível e determina que identidade o endpoint vê para cada dispositivo atrás do gateway. Registe o cliente e a configuração do endpoint contra a qual foi testado. Uma troca de cliente seis meses depois pode remover silenciosamente a capacidade que o desenho assumia.

Encaminhe a LAN para o túnel e traduza-a

Com um cliente suportado no lugar, o resto é trabalho normal de gateway. Os dispositivos da LAN precisam de uma rota para o intervalo da VPC que aponte para o host Linux, e o host precisa do encaminhamento ativo. Se quiser que a VPC veja o tráfego como o cliente ligado e não como um endereço LAN arbitrário, traduza a origem à saída.

LAN: 10.24.11.0/24
Linux LAN gateway: 10.24.11.15
VPN interface: tun0
Target VPC range: 10.2.0.0/16

iptables -t nat -A POSTROUTING -s 10.24.11.0/24 -d 10.2.0.0/16 -o tun0 -j MASQUERADE

Limite a regra à interface de túnel e ao intervalo da VPC, como acima, em vez de fazer masquerading de tudo o que o host encaminha. A regra mais estreita é mais fácil de raciocinar e não altera silenciosamente tráfego que devia manter o seu endereço de origem original.

Faça com que a rota da LAN chegue automaticamente se puder: uma opção DHCP, um anúncio de router ou uma rota estática empurrada por aquilo que gere a LAN. Uma rota que só existe numa máquina de teste fará o desenho parecer avariado no momento em que outra pessoa o experimentar.

A resposta também precisa de um caminho

Assim que o pedido chega à VPC, a resposta tem de voltar pelos mesmos estados de tradução e encontrar a rota da LAN no gateway. Essa parte costuma funcionar quando a regra de masquerading está no lugar, porque o mapeamento vive no host que o executou. Rompe-se quando o lado da VPC tem uma rota que envia a resposta para outro sítio, e é por isso que tanto a rota do CIDR do cliente como a associação de sub-rede no endpoint importam.

Olhe para os contadores, não apenas para o ping. Uma regra de masquerading com zero pacotes diz-lhe que o pedido nunca chegou à interface de túnel, o que aponta de volta para a rota da LAN ou para a própria tabela de encaminhamento do cliente. Uma regra com pacotes mas sem respostas aponta para o lado da VPC, para as regras de autorização ou para um grupo de segurança que não aceita a origem traduzida. Leia as duas direções antes de mudar algo, porque uma contagem que só cresce num lado é um caminho de sentido único, não um caminho lento.

Lembre-se de que o endpoint é um serviço gerido. Não há ficheiro de configuração do servidor para editar nem diretiva client-config para acrescentar, por isso as instruções escritas para um servidor OpenVPN autogerido com rotas personalizadas de sub-rede de cliente não se transferem. Na AWS as alavancas são a associação de sub-rede, as regras de autorização e as tabelas de encaminhamento da VPC.

A identidade partilhada é a parte a que a política tem de responder

Cada dispositivo atrás do gateway usa a sessão VPN do gateway. As regras de autorização do endpoint concedem acesso a um utilizador ou a um grupo, e do ponto de vista do serviço há exatamente um utilizador nessa sessão. O encaminhamento local não multiplica essa identidade em autenticação por dispositivo, nem estende as verificações de postura do dispositivo à impressora do canto.

Isso pode ser aceitável, ou pode ser a razão pela qual o desenho é rejeitado. Depende do que os recursos da VPC assumem sobre quem está a chamar. Uma identidade partilhada que encaixa no modelo de autorização está bem; uma que converte silenciosamente uma única sessão autenticada em acesso a toda a LAN é uma constatação à espera de ser escrita.

Se o requisito é realmente ligar um site inteiro a uma VPC, compare um desenho suportado site-a-site antes de estender um cliente de acesso remoto. A semântica é diferente, e uma sessão de cliente com NAT é um mau substituto de uma ligação de site quando a VPC precisa de iniciar ligações para a LAN.

Decida o cliente, a rota, a tradução e a história de identidade nessa ordem. Cada um limita o seguinte, e a ordem explica porque é que o host funciona enquanto a LAN não.