Acesso intermitente com AWS Client VPN: audite cada sub-rede associada

Um utilizador liga-se, abre a aplicação interna e recebe resposta; um colega no mesmo endpoint recebe um tempo limite a partir de um portátil idêntico na mesma Wi-Fi. Esse padrão é a assinatura de um endpoint de client VPN com mais de uma sub-rede associada, onde os caminhos não são equivalentes. Eu percorro isto da consola para fora, porque dois separadores decidem se o resto da investigação vale a pena. Nada na configuração do cliente o explica.

Comece pelo endpoint e liste as associações

Na consola da VPC, abra Client VPN endpoints, escolha o endpoint e leia o separador Associations. Cada associação é uma sub-rede numa zona de disponibilidade, e o cliente aterra na que o serviço escolher quando a ligação é construída. Anote os ID das sub-redes e a tabela de rotas que cada uma usa realmente, porque essas duas listas são a comparação que vai fazer.

Se o endpoint mostrar apenas uma associação, esta teoria está errada e o cliente é o melhor suspeito.

Compare a tabela de rotas do endpoint com cada associação

Abra o separador Route table no mesmo endpoint. Cada CIDR de destino tem ali um alvo, e num client VPN o alvo é uma associação e não um gateway. A AWS exige uma entrada de destino para cada sub-rede associada, por isso uma rota que aponte apenas para uma delas torna o acesso dependente de onde a sessão aterrou. Verifique o destino que realmente lhe importa e depois a respetiva regra de autorização, porque a rota fornece o caminho e a regra decide quem o pode usar.

Assim que tabular as duas camadas, a falha é difícil de não ver.

A segunda linha é todo o erro na maioria dos pedidos. A rota do endpoint está lá, por isso ninguém olha mais longe, e o pacote morre um salto depois dentro da VPC.

Siga cada sub-rede até à sua tabela de rotas efetiva

Uma sub-rede sem associação explícita a uma tabela de rotas herda a tabela principal da VPC. Leia a tabela que está realmente em vigor, não a que parece ter o nome certo, e compare destino e alvo em vez do rótulo na linha.

O guia da AWS sobre acesso intermitente enquadra isto como cobertura de rotas entre associações, que é o modelo correto. O endpoint leva o pacote a uma sub-rede, e a tabela dessa sub-rede ainda tem de saber onde vive a rede da aplicação.

Corrija a linha em falta na tabela que a possui. Copiar uma tabela de rotas inteira de uma sub-rede que funciona também copia escolhas de internet, equipamento e isolamento que nunca foram pensadas para esta, e essa troca costuma ser pior do que a falha com que começou.

Verifique as regras de autorização e depois o caminho de volta

As regras de autorização são por destino e por grupo, e são avaliadas separadamente das rotas. Um destino com rotas em todo o lado mas sem regra para o grupo do utilizador comporta-se como um buraco negro com uma tabela de rotas de aparência saudável.

O caminho de volta merece a mesma atenção. Uma ligação peering precisa de uma rota na VPC da aplicação que aponte de volta para o CIDR do cliente, de regras de grupo de segurança que permitam o tráfego nas duas pontas e de ACL de rede que não o descartem. A alcançabilidade num só sentido, em que o ping funciona e o aperto de mão TCP não, costuma apontar para uma ACL ou um grupo de segurança e não para a VPN.

Os grupos de segurança do próprio endpoint ficam nas interfaces de rede elásticas da associação, por isso uma regra que permita a porta da aplicação a partir do CIDR do cliente tem de ser anexada à associação, não apenas à instância.

Verifique com uma reconexão, não com um pedido com sorte

Com túnel dividido, as rotas do endpoint são enviadas quando a ligação é estabelecida, por isso um conjunto de rotas alterado nunca chega a um cliente que permanece ligado. Desligue e volte a ligar através do cliente suportado, e depois confirme que as novas rotas estão na máquina.

Por fim, correlacione o registo de ligações com o endereço que o cliente recebeu, e repita o teste vezes suficientes para atingir mais do que uma associação. Um único pedido bem-sucedido após uma correção prova que um caminho funciona, e o pedido era sobre o outro.