AWS Client VPN: o início de sessão funciona, mas a sub-rede mantém-se inacessível

O seu cliente diz Connected, o certificado é válido e a página da intranet continua a terminar em tempo esgotado. Essa diferença quase nunca é autenticação. O AWS Client VPN autoriza os destinos separadamente do início de sessão, e as duas causas habituais são um valor de grupo que não corresponde ao que o fornecedor de identidade enviou e uma regra de destino mais específica que vence a regra ampla. Ambas são visíveis na configuração do endpoint quando se sabe onde olhar.

O início de sessão foi bem-sucedido; a regra não correspondia

A autenticação responde a quem é o utilizador. As regras de autorização respondem a que prefixos de rede essa identidade pode chegar. Um utilizador pode passar a primeira e falhar na segunda, e o cliente dá-lhe pouco mais do que uma ligação que permanece ativa enquanto cada pedido termina em tempo esgotado.

Comece por confirmar que o endpoint tem uma regra de autorização cujo destino contém o endereço que falha. Se não existir nenhuma regra correspondente, a ligação está a comportar-se corretamente; o que falta é a política.

De onde vem realmente o valor do grupo

No Active Directory, o campo access-group contém o SID do grupo, não o nome de apresentação. Na federação SAML, contém o ID ou o nome do grupo que o atributo de grupo SAML configurado realmente transporta. Copie o valor da assertion ou da consulta ao diretório, não de uma página wiki.

Um grupo IAM é outro plano de controlo. A permissão para administrar um endpoint do Client VPN não transforma um grupo IAM no grupo VPN de um utilizador, e colar um nome de grupo IAM no campo access-group não o traduz num SID de AD nem num valor de atributo SAML.

Um grupo com um nome semelhante noutro diretório não prova nada. Verifique o método de autenticação do endpoint e a pertença ou a assertion do utilizador nesse mesmo sistema.

Ganha o prefixo mais longo, incluindo 0.0.0.0/0

A autorização é avaliada pela correspondência de prefixo mais longa, e a regra para todos os destinos é avaliada em último, não em primeiro. Acrescente uma regra 10.46.0.0/16 para Engineering e uma regra 0.0.0.0/0 para todos, e um utilizador fora de Engineering continua sem conseguir chegar a 10.46.20.10 pela regra ampla.

É aqui que uma correção pode correr mal. Apagar a regra estreita restaura o acesso do utilizador e também concede essa sub-rede a todas as identidades abrangidas pela regra ampla. Construa a matriz de grupo para rede antes de apagar seja o que for, e registe que grupos devem chegar a que intervalo. Estas regras apenas permitem; não existe entrada de negação para recortar uma exceção de uma permissão ampla.

As alterações também exigem uma ligação nova para serem julgadas com justiça. Volte a ligar o cliente depois de editar as regras e teste novamente.

Separe a autorização do caminho de dados

Uma regra que corresponde não é uma rota. O endpoint precisa de uma sub-rede associada e de uma entrada na tabela de rotas para o destino, e o grupo de segurança do recurso de destino tem de aceitar o tráfego. O tráfego de retorno e o DNS também têm de funcionar.

Teste um utilizador que devia ter êxito e um utilizador que devia ficar excluído. Ambos podem iniciar sessão enquanto apenas um chega à sub-rede, e essa diferença é a prova que procura.

Se um endereço IP funciona mas um nome de anfitrião não, olhe para o resolver antes de tocar na autorização. Se nenhuma rota cobre o endereço, corrija a associação ou a tabela de rotas. Se o pacote chega e o serviço o recusa, a política desse serviço é a paragem seguinte. Alargar a matriz de autorização a todos os utilizadores esconde qual dessas camadas estava realmente quebrada.

Antes de fechar o ticket, registe a origem de identidade, o valor exato do grupo, os prefixos de destino e a rota que transporta o tráfego. Esse registo transforma o próximo relato de ligado mas sem acesso numa comparação de dois minutos em vez de mais uma ronda de suposições.