AWS Client VPN ou um bastion para chegar a uma VPC com peering

Um endpoint de Client VPN pode chegar a uma VPC que tem peering com a VPC associada, e você não precisa de um bastion para tornar isso legítimo. A escolha que vale a pena é onde o tráfego troca de mãos: uma rota de endpoint que aterrissa na sub-rede de associação e cruza a conexão de peering, ou um host na VPC com peering que encerra a sessão. Os dois caminhos funcionam e falham em pontos diferentes, então a decisão é sobre propriedade e auditoria, não sobre o que a AWS permite. Aqui está como escolho entre eles, e as quatro entradas que fazem o caminho roteado funcionar.

Dois caminhos, um endpoint, donos diferentes

No caminho roteado, o tráfego do cliente chega ao endpoint, é traduzido para o endereço da interface de rede do Client VPN na sub-rede de associação e sai dessa sub-rede pela conexão de peering de A para B. A VPC B não encerra nenhuma sessão de VPN; vê tráfego comum vindo da VPC A, por isso sua rota de retorno aponta para a VPC A, e não para o pool de clientes.

No caminho do bastion, o cliente chega primeiro a um host. Um bastion em A ainda deixa o último salto cruzar a conexão de peering, então você mantém o trabalho de peering e acrescenta uma sessão. Um bastion em B também precisa de um caminho a partir do cliente, e quando esse caminho é a mesma rota de endpoint, você tem o desenho roteado mais um salto. O bastion só remove trabalho quando já existe, já está aprovado, e o que está atrás precisa de uma fronteira de sessão e não de uma fronteira de rede.

Quatro entradas fazem o caminho roteado funcionar

A AWS documenta este cenário na página Client VPN how-it-works, e na prática resume-se a quatro entradas que pertencem a duas ou três equipes. Os intervalos são ilustrativos; o intervalo com peering precisa ser único e o intervalo de retorno precisa bater com o seu plano.

Rota e permissão são controles separados. Uma rota de endpoint correta sem a regra de autorização correspondente não dá nada ao cliente; uma regra de autorização para um destino que o endpoint não consegue rotear dá a ele um buraco negro. As duas precisam nomear o mesmo intervalo.

A rota do endpoint aponta para uma sub-rede dentro da própria VPC do endpoint, nunca para a conexão de peering. As tabelas de rotas da VPC apontam para a conexão de peering, nunca para uma instância ou uma interface. Copiar um valor entre as duas é salvo sem reclamação e não roteia nada.

Como a sub-rede de associação traduz a origem do cliente, B precisa rotear de volta para a VPC A, não para o pool de clientes. Enviar o intervalo de clientes pela conexão de peering parece simétrico, passa na revisão e falha silenciosamente porque B nunca vê um pacote com origem de cliente.

Grupos de segurança e o último metro de permissão

O roteamento leva pacotes até B; B ainda decide. Para uma conexão de peering ativa na mesma região, um grupo de segurança em B pode referenciar o grupo aplicado à associação do Client VPN, o que mantém a regra estreita e sobrevive a mudanças de endereço. Onde uma referência de grupo não é viável, permita o intervalo da sub-rede de associação explicitamente em vez de ampliar para 0.0.0.0/0, o que transforma um erro de roteamento em um tempo esgotado sem explicação.

Depois verifique o que o roteamento nunca toca: as ACLs de rede nas duas sub-redes, a lista de permitidos ou a audiência do token da aplicação, e o DNS. O peering não copia zonas hospedadas privadas, então o notebook pode manter uma rota que funciona para um endereço que não consegue resolver, e uma conexão de peering não acrescenta confiança a um certificado. Aponte o endpoint para um resolvedor que responda por B e então confirme que o nome privado e o certificado coincidem.

Quando o bastion é a resposta honesta

Mantenho três gatilhos para escolher um bastion de propósito. A VPC com peering pertence a uma equipe que não vai adicionar uma rota de retorno para o seu intervalo ou não vai aceitar uma referência de grupo. O acesso precisa ser aprovado ou registrado por sessão e a aplicação não consegue carregar isso sozinha. Ou o último salto precisa ficar dentro de B porque o serviço só resolve ali e sua identidade TLS está fixada a um nome interno.

Nada disso é um contorno do fato de que o peering não é transitivo. A não transitividade limita o que os recursos em B podem fazer: eles não podem usar A como trânsito para uma terceira VPC com a qual A tem peering. Nunca significou que um usuário de VPN não possa chegar a uma VPC com peering direto, e um bastion construído para contornar essa leitura errada é um host que se corrige sem motivo.

O erro inverso custa mais com o tempo: faça cada equipe passar pelo único bastion que já existe e depois descubra que seu grupo de segurança, sua tabela de rotas e sua janela de correções são a dependência de produção. Anote qual gatilho o host serve, e aposente-o quando o gatilho desaparecer.

Transit Gateway e várias associações mudam a aritmética

Se o endpoint estiver conectado diretamente a um Transit Gateway em vez de a uma sub-rede, o modelo muda: os clientes não são mais traduzidos para um endereço de interface numa sub-rede de associação, e as tabelas de rotas do gateway precisam carregar o intervalo de clientes mais a conexão que leva à VPC com peering. Isso é mais limpo em escala, mas o trabalho passa de quatro entradas para as tabelas de rotas do gateway.

Várias associações multiplicam as verificações. A rota do endpoint pertence ao endpoint, mas cada sub-rede de associação precisa de uma tabela de rotas com um próximo salto de peering real. Uma sessão pode ter sucesso por uma associação enquanto outra não tem caminho de retorno, então teste cada uma.

Ordem de verificação que encontra a falha rápido

Execute estas em ordem; cada passo pode passar enquanto o seguinte falha, e um tempo esgotado do cliente quase nunca diz qual quebrou.

1. Resolva o nome da aplicação a partir do cliente e verifique se o endereço está dentro do intervalo com peering.
2. Conecte-se e depois leia o registro de conexões do endpoint para a associação que encerrou a sessão.
3. Nessa sub-rede de associação, confirme que a tabela de rotas aponta o intervalo com peering para uma conexão de peering ativa.
4. Na sub-rede de recursos em B, confirme uma entrada de retorno para o intervalo da interface e regras de grupo correspondentes.
5. Teste uma operação permitida e um recurso que deve permanecer inalcançável; o segundo pega restos de depuração.
6. Reconecte após qualquer mudança de rota split-tunnel, porque um túnel em execução não vai pegar um novo conjunto de rotas.

Dois sintomas merecem ser memorizados. Um SYN que chega a B sem resposta é quase sempre a rota de retorno que falta. Uma conexão que se completa e depois é reiniciada é normalmente o grupo, a ACL ou a aplicação. Nenhum dos dois aparece no registro do endpoint como causa, então mantenha as quatro entradas com um dono ao lado de cada uma.

Se nenhum dos três gatilhos se aplica, conclua o caminho roteado e registre essas quatro entradas. Se um se aplica, mantenha o bastion apenas para essa fronteira e deixe a rota do endpoint para serviços que não precisam de uma sessão na frente.