AWS Client VPN ou un bastión para chegar a unha VPC con peering

Un endpoint de Client VPN pode chegar a unha VPC que ten peering coa súa VPC asociada, e non necesita un bastión para facelo lexítimo. A decisión que paga a pena é onde o tráfico cambia de mans: unha ruta de endpoint que aterra na subrede de asociación e cruza a conexión de peering, ou un host na VPC con peering que remata a sesión. Ambos os camiños funcionan e fallan en lugares distintos, así que a decisión é sobre propiedade e auditoría, non sobre o que AWS permite. Velaquí como elixo entre eles, e as catro entradas que fan que o camiño enrutado funcione.

Dous camiños, un endpoint, propietarios distintos

No camiño enrutado, o tráfico do cliente chega ao endpoint, tradúcese á dirección da interface de rede de Client VPN na subrede de asociación e sae desa subrede pola conexión de peering de A a B. A VPC B non remata ningunha sesión de VPN; ve tráfico normal da VPC A, por iso a súa ruta de retorno apunta á VPC A e non ao grupo de clientes.

No camiño do bastión, o cliente chega primeiro a un host. Un bastión en A segue deixando que o último salto cruce a conexión de peering, así que conserva o traballo de peering e engade unha sesión. Un bastión en B tamén necesita un camiño desde o cliente, e cando ese camiño é a mesma ruta de endpoint, ten o deseño enrutado máis un salto. O bastión só quita traballo cando xa existe, xa ten aprobación e o que hai detrás necesita unha fronteira de sesión e non unha de rede.

Catro entradas fan funcionar o camiño enrutado

AWS documenta este escenario na páxina Client VPN how-it-works, e na práctica redúcese a catro entradas que posúen dous ou tres equipos. Os rangos son ilustrativos; o rango con peering debe ser único e o rango de retorno debe coincidir co seu plan.

Ruta e permiso son controis separados. Unha ruta de endpoint correcta sen unha regra de autorización que coincida non lle dá nada ao cliente; unha regra de autorización para un destino que o endpoint non pode enrutar dálle un burato negro. Ambas deben nomear o mesmo rango.

A ruta do endpoint apunta a unha subrede da propia VPC do endpoint, nunca á conexión de peering. As táboas de rutas da VPC apuntan á conexión de peering, nunca a unha instancia nin a unha interface. Copiar un valor entre ambas gárdase sen queixa e non enruta nada.

Como a subrede de asociación traduce a orixe do cliente, B debe enrutar de volta á VPC A, non ao grupo de clientes. Enviar o rango de clientes pola conexión de peering parece simétrico, pasa a revisión e falla en silencio porque B nunca ve un paquete con orixe de cliente.

Grupos de seguridade e o último metro de permiso

O enrutamento mete paquetes en B; B segue decidindo. Para unha conexión de peering activa na mesma rexión, un grupo de seguridade en B pode referenciar o grupo aplicado á asociación de Client VPN, o que mantén a regra estreita e sobrevive aos cambios de dirección. Onde unha referencia de grupo non é viable, permita o rango da subrede de asociación de forma explícita en lugar de amplialo a 0.0.0.0/0, que converte un erro de enrutamento nun tempo de espera sen explicación.

Despois revise o que o enrutamento nunca toca: as ACL de rede de ambas as subredes, a lista de permitidos ou a audiencia do token da aplicación, e o DNS. O peering non copia zonas aloxadas privadas, así que o portátil pode ter unha ruta que funciona cara a unha dirección que non pode resolver, e unha conexión de peering non engade confianza a un certificado. Apunte o endpoint a un resolutor que responda por B e logo confirme que o nome privado e o certificado coinciden.

Cando o bastión é a resposta honesta

Manteño tres disparadores para elixir un bastión a propósito. A VPC con peering pertence a un equipo que non engadirá unha ruta de retorno para o seu rango ou non aceptará unha referencia de grupo. O acceso debe aprobarse ou rexistrarse por sesión e a aplicación non pode cargar con iso. Ou o último salto debe quedar dentro de B porque o servizo só resolve alí e a súa identidade TLS está fixada a un nome interno.

Nada diso é un rodeo ao feito de que o peering non é transitivo. A non transitividade limita o que poden facer os recursos de B: non poden usar A como tránsito cara a unha terceira VPC coa que A ten peering. Nunca significou que un usuario de VPN non poida chegar a unha VPC con peering directo, e un bastión construído para sortear esa mala lectura é un host que se parchea sen motivo.

O erro inverso custa máis co tempo: faga pasar a cada equipo polo único bastión que xa existe e logo descubra que o seu grupo de seguridade, a súa táboa de rutas e a súa xanela de parcheo son a dependencia de produción. Anote que disparador serve o host e retíreo cando o disparador desapareza.

Transit Gateway e varias asociacións cambian a aritmética

Se o endpoint está conectado directamente a un Transit Gateway en lugar de a unha subrede, o modelo cambia: os clientes xa non se traducen a unha dirección de interface nunha subrede de asociación, e as táboas de rutas da pasarela deben levar o rango de clientes máis a conexión que leva á VPC con peering. É máis limpo a escala, pero o traballo trasládase de catro entradas ás táboas de rutas da pasarela.

Varias asociacións multiplican as comprobacións. A ruta do endpoint pertence ao endpoint, pero cada subrede de asociación necesita unha táboa de rutas cun seguinte salto de peering real. Unha sesión pode ter éxito por unha asociación mentres outra non ten camiño de retorno, así que probe cada unha.

Orde de verificación que atopa o fallo rápido

Execúteas en orde; cada paso pode pasar mentres o seguinte falla, e un tempo de espera do cliente case nunca di cal se rompeu.

1. Resolva o nome da aplicación desde o cliente e comprobe que a dirección está dentro do rango con peering.
2. Conéctese e lea o rexistro de conexións do endpoint da asociación que rematou a sesión.
3. Nesa subrede de asociación, confirme que a táboa de rutas apunta o rango con peering a unha conexión de peering activa.
4. Na subrede de recursos de B, confirme unha entrada de retorno para o rango da interface e regras de grupo coincidentes.
5. Probe unha operación permitida e un recurso que debe seguir inalcanzable; o segundo atrapa restos de depuración.
6. Vólvase conectar tras calquera cambio de ruta split-tunnel, porque un túnel en marcha non tomará un conxunto de rutas novo.

Merece a pena memorizar dous síntomas. Un SYN que chega a B sen resposta case sempre é a ruta de retorno que falta. Unha conexión que se completa e logo se reinicia adoita ser o grupo, a ACL ou a aplicación. Ningún aparece no rexistro do endpoint como causa, así que manteña as catro entradas cun propietario xunto a cada unha.

Se non se cumpre ningún dos tres disparadores, termine o camiño enrutado e rexistre esas catro entradas. Se se cumpre un, manteña o bastión só para esa fronteira e deixe a ruta do endpoint para servizos que non necesitan unha sesión diante.