AWS Client VPN conectado, pero EC2 segue sen responder

O meu portátil dicía conectado. O cliente de AWS Client VPN mostraba o seu estado verde, o punto de acceso rexistraba unha sesión e aínda así non podía abrir un porto de MongoDB nunha instancia EC2 nunha subrede privada. Nada estaba obviamente roto: o certificado era válido, o perfil viña da consola e o túnel transportaba tráfico. O erro era meu, porque lía conectado como autorizado.

O inicio de sesión responde exactamente a unha pregunta: pode esta identidade establecer unha sesión? Todo o que vén despois decídeno regras separadas que nunca ven o teu certificado. Unha sesión que se autentica e un paquete que chega son dous éxitos distintos, e a fenda entre ambos é onde viven a maioría dos avisos do tipo a VPN está levantada pero o host non é accesible.

As comprobacións seguintes son a orde que uso agora.

Que demostra realmente unha sesión conectada

Durante o handshake, o punto de acceso valida o certificado do cliente contra o seu almacén de confianza, ou redirixe o navegador ao teu provedor de identidade cando SAML está configurado. Se iso pasa, o cliente recibe un enderezo do CIDR de cliente do punto de acceso e a consola mostra unha conexión activa. En ningún momento dese intercambio se pregunta se podes chegar a 10.0.4.17 no porto 27017.

O permiso cara a un destino é un obxecto aparte no punto de acceso. Cada fluxo compárase coas regras de autorización, e cada unha emparexa un CIDR de destino co grupo ao que se concede a regra. Cando ningunha regra cobre o destino, o punto de acceso acepta a sesión e descarta o tráfico. Non hai banner, nin bucle de reconexión, nin nada na interface do cliente que diga denegado.

Compare a regra de autorización co recurso, non coa VPC

Enumere as regras e póñaas xunto ao enderezo que a instancia ten de verdade:

aws ec2 describe-client-vpn-authorization-rules \
  --client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8

A saída mostra un CIDR de destino e un id de grupo por regra. Dentro esconden dous fallos. A regra pode autorizar 10.0.0.0/16 mentres a instancia está nunha VPC emparellada en 10.1.0.0/16; a ruta de peering existe, pero ninguén escribiu unha regra de autorización para o segundo rango. Ou a regra apunta a un grupo do directorio ao que o usuario pertence no directorio, pero non no grupo que avalía o punto de acceso.

Escriba a regra máis estreita que cubra o destino, e engada unha segunda só cando de verdade sexa necesario un segundo CIDR. Unha regra ampla 0.0.0.0/0 dun inicio rápido funciona, e por iso sobrevive ata produción e esconde o modelo.

Dúas táboas de rutas deciden se o paquete se move

Unha ruta do punto de acceso asigna un CIDR de destino a unha das subredes coas que está asociado o punto de acceso. Iso é medio camiño. A táboa de rutas propia da subrede aínda ten que saber como reenviar o paquete, e iso importa no momento en que o destino está detrás dunha conexión de peering, unha pasarela de tránsito ou un rango local accesible por un túnel de sitio a sitio.

aws ec2 describe-client-vpn-routes \
  --client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8

Busque unha ruta cuxo destino coincida co CIDR do recurso e cuxo obxectivo sexa unha subrede asociada. Se falta a ruta, engádaa. Se está presente e o host segue mudo, a fenda está do lado da VPC, así que compare coa táboa de rutas da subrede de asociación.

Un axuste do lado do cliente rompe o encamiñamento sen romper o túnel: un perfil que contén route-nopull. A directiva díxelle a un cliente baseado en OpenVPN que ignore as rutas que empuxa o servidor, así que a interface sobe só co enderezo propio do punto de acceso e o destino simplemente non ten ruta. Comprobe con ip route show en Linux ou netstat -rn en macOS se existe unha ruta pola interface tun. Se non existe, quite route-nopull do perfil exportado e volva conectarse para que se apliquen as rutas empuxadas.

Os grupos de seguridade non ven o enderezo do teu cliente

Esta é a parte que tiven mal durante unha tarde enteira. Para un punto de acceso IPv4 asociado a unha subrede, o servizo traduce o enderezo de orixe do cliente ao enderezo da interface de rede do punto de acceso nesa subrede. O paquete que chega á instancia non leva o enderezo que mostraba o teu cliente, así que unha regra de grupo de seguridade que permita o conxunto de clientes, digamos 172.16.0.0/22, non coincide con nada.

Permita o porto desde o grupo de seguridade do punto de acceso, que vai unido á interface da asociación, e non desde o CIDR de cliente. Referenciar o grupo é máis duradeiro que codificar un enderezo en duro, porque o enderezo da interface non é teu para controlalo. As ACL de rede non gardan estado, así que onde existan entradas personalizadas, tanto a dirección de entrada como a de saída deben permitir o fluxo.

Conéctate tamén ao enderezo privado da instancia. Unha IP pública saca o paquete da VPC e volve metelo por outro camiño con outras regras, así que unha proba polo enderezo público non di nada do camiño privado.

Unha orde de illamento que se detén no primeiro fallo

Percórreos en orde e detente onde un falle. Cada paso descarta unha capa en lugar de todas.

1. Confirme que identidade usou a sesión e que grupo avalía o punto de acceso. Un certificado dun almacén de confianza non é o mesmo principal que unha aserción SAML do directorio.
2. Confirme que unha regra de autorización cobre o CIDR do recurso para ese grupo.
3. Confirme que existe unha ruta do punto de acceso e apunta a unha subrede asociada, e despois que a táboa de rutas da subrede pode reenviar máis aló.
4. Confirme que o grupo de seguridade permite o porto desde a interface do punto de acceso e non desde o conxunto de clientes.
5. Probe desde dentro da VPC, cunha sesión SSM noutra instancia da mesma subrede, para separar un problema de aplicación dun problema do camiño do cliente.

Cando os pasos non son concluíntes, esta táboa é o meu recurso:

Dous detalles da conta producen síntomas que parecen fallos de permisos. Cada usuario necesita un certificado de cliente distinto; compartir un entre dúas máquinas fai que as sesións se despracen mutuamente, e o resultado é un bucle de reconexión en lugar dunha denegación. Cando se crea un punto de acceso novo, a consola mostra un nome DNS que algunhas versións do cliente só aceptan co prefixo aleatorio que aparece na páxina do punto de acceso, así que copie o nome completo en lugar de reconstruílo.

Se o quinto paso te deixa atascado, saca o rexistro de conexións do punto de acceso e le as entradas de autorización antes de cambiar nada. O rexistro nomea o destino que se comprobou e a regra que coincidiu ou non, o que reduce a pregunta de catro capas a unha soa resposta.