As regras do AWS Client VPN pertencem ao recurso, não à sub-rede

A equipa precisa de chegar a uma aplicação na VPC e não deve chegar ao listener de base de dados na mesma instância, por isso alguém acrescenta uma segunda sub-rede pública para o endpoint de VPN e declara o requisito cumprido. A localização da sub-rede altera o encaminhamento e a disponibilidade. Não concede nem recusa uma única porta. A permissão que exprime o requisito vive no destino, no grupo de segurança do recurso, e a fronteira da VPN fornece a pega a que essa regra se refere.

A localização da sub-rede é encaminhamento, não autorização

Onde fica a associação de rede do endpoint decide que tabela de rotas transporta o tráfego dos clientes e que zonas de disponibilidade sobrevivem a uma falha. Não diz nada sobre que porta, em que instância, esse tráfego pode alcançar. Dois clientes associados à mesma sub-rede chegam na mesma com a mesma identidade de origem, e o recurso não os consegue distinguir pelo nome da sub-rede.

Comece antes pelo requisito: quem chama, que recurso, que porta de serviço e em que direção. Depois escolha o modelo de regra que consegue exprimir essas quatro coisas no destino. Essa abordagem remove normalmente a sub-rede adicional do desenho por completo.

O grupo de associação do Client VPN é a pega

Para um endpoint do AWS Client VPN associado a uma sub-rede, a disposição documentada é concreta. Aplique o grupo de segurança pretendido às associações de rede de destino do endpoint e, em seguida, permita o tráfego necessário no grupo de segurança do recurso usando esse grupo do Client VPN como origem.

Concretamente, o grupo da instância da aplicação permite a porta da aplicação a partir do grupo de associação, e nada mais. O procedimento de acesso ao recurso da AWS descreve essa relação, e vale a pena manter a mesma política de grupo em cada sub-rede a que o endpoint se associa, porque uma associação antiga com outro grupo alarga a fronteira sem aviso.

Essa regra não autentica ninguém. O início de sessão é um controlo separado, e a rota até ao recurso é um terceiro. Os três têm de se verificar antes de chegar um pedido. O que falhar determina qual correção está certa, e alterar a regra é a resposta correta apenas para o primeiro.

O que um único grupo de associação não distingue

Cada cliente atrás do mesmo grupo de associação chega ao recurso como a mesma origem de grupo de segurança. Dois utilizadores com funções diferentes são indistinguíveis nessa camada, independentemente do nome ou das etiquetas do grupo. A autorização de grupos externos do Client VPN limita o acesso por prefixo de destino para um grupo de diretório ou SAML, o que é mais grosseiro do que uma função de recurso e deve ser tratado como fronteira de rede, não como sistema de identidade.

As distinções mais finas pertencem à aplicação. Um listener de base de dados que tem de permanecer fechado à maioria do pessoal fica melhor protegido por não ser alcançável de todo no prefixo permitido do que por se esperar que a pertença ao grupo se mantenha arrumada.

Mudar o nome do grupo não cria uma identidade, e duplicá-lo por equipa apenas multiplica as associações a auditar.

Não copie essa regra para todos os desenhos de VPN

Um gateway EC2 VPN auto-gerido, um equipamento de inspeção encaminhado e um Client VPN gerido são três caminhos de pacotes diferentes. Estabeleça que endereço de origem chega realmente ao recurso, se ocorre tradução pelo meio e que mecanismos de referência o serviço suporta nesse caminho.

Encaminhar tráfego através de um dispositivo intermédio não preserva uma referência ao grupo de segurança de origem como o faz o tráfego direto entre instâncias. A AWS documenta que tais desenhos podem precisar dos endereços privados de origem ou dos CIDR adequados em vez de uma referência de grupo. O procedimento do Client VPN gerido não é prova de que o grupo ligado de cada gateway funcione como um token de identidade universal para pacotes reencaminhados.

Um único salto NAT no caminho basta para quebrar a suposição, e a falha parece uma regra que existe mas nunca corresponde.

Reveja a fronteira efetiva

Leia cada grupo de segurança ligado ao recurso, porque as regras de permissão se combinam e uma regra estreita não anula uma mais ampla noutro grupo. Depois verifique a ACL de rede, a firewall do anfitrião e a autorização própria da aplicação, que são camadas separadas com erros separados.

Termine com um pedido permitido e um pedido deliberadamente excluído contra o mesmo recurso. O par prova a fronteira, enquanto uma única ligação bem-sucedida prova apenas que algo está aberto. Confirme a rota, a origem efetiva e a porta de serviço pretendida, e não a sub-rede que contém o endpoint.

Ordem de trabalho: escreva o requisito em quatro partes, ligue o grupo às associações, limite a regra do recurso à porta, verifique uma permissão e uma recusa, e só depois considere dividir sub-redes por razões de encaminhamento.