AWS Client VPN connectat, però EC2 encara no respon

El meu portàtil deia connectat. El client d’AWS Client VPN mostrava el seu estat verd, el punt de terminació registrava una sessió i tot i així no podia obrir un port de MongoDB en una instància EC2 en una subxarxa privada. Res no era òbviament trencat: el certificat era vàlid, el perfil venia de la consola i el túnel portava trànsit. L’error era meu, perquè llegia connectat com a autoritzat.

L’inici de sessió respon exactament una pregunta: pot aquesta identitat establir una sessió? Tot el que ve després ho decideixen regles separades que mai no veuen el vostre certificat. Una sessió que s’autentica i un paquet que arriba són dos èxits diferents, i l’escletxa entre tots dos és on viuen la majoria d’avisos del tipus la VPN està aixecada però l’amfitrió no és abastable.

Les comprovacions següents són l’ordre que faig servir ara.

Què demostra realment una sessió connectada

Durant el handshake, el punt de terminació valida el certificat del client contra el seu magatzem de confiança, o redirigeix el navegador al vostre proveïdor d’identitat quan SAML està configurat. Si això passa, el client rep una adreça del CIDR de client del punt de terminació i la consola mostra una connexió activa. En cap moment d’aquest intercanvi res no pregunta si podeu arribar a 10.0.4.17 pel port 27017.

El permís cap a una destinació és un objecte separat al punt de terminació. Cada flux es compara amb les regles d’autorització, i cadascuna aparella un CIDR de destinació amb el grup al qual es concedeix la regla. Quan cap regla no cobreix la destinació, el punt de terminació accepta la sessió i descarta el trànsit. No hi ha cap bàner, cap bucle de reconnexió ni res a la interfície del client que digui denegat.

Compareu la regla d’autorització amb el recurs, no amb la VPC

Lliste les regles i poseu-les al costat de l’adreça que la instància té realment:

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

La sortida mostra un CIDR de destinació i un identificador de grup per regla. Hi ha dos errors amagats. La regla pot autoritzar 10.0.0.0/16 mentre la instància és en una VPC aparellada a 10.1.0.0/16; la ruta de peering existeix, però ningú no ha escrit una regla d’autorització per al segon rang. O la regla apunta a un grup de directori al qual l’usuari pertany al directori, però no al grup que avalua el punt de terminació.

Escriviu la regla més estreta que cobreixi la destinació, i afegiu-ne una segona només quan un segon CIDR sigui realment necessari. Una regla àmplia 0.0.0.0/0 vinguda d’un inici ràpid funciona, i per això sobreviu fins a producció i amaga el model.

Dues taules de rutes decideixen si el paquet es mou

Una ruta del punt de terminació assigna un CIDR de destinació a una de les subxarxes amb què el punt de terminació està associat. Això és mig camí. La taula de rutes pròpia de la subxarxa encara ha de saber com reenviar el paquet, i això compta en el moment que la destinació és darrere d’una connexió de peering, una passarel·la de trànsit o un rang local abastable per un túnel de lloc a lloc.

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

Cerqueu una ruta la destinació de la qual coincideixi amb el CIDR del recurs i el destí de la qual sigui una subxarxa associada. Si la ruta falta, afegiu-la. Si hi és i l’amfitrió continua mut, l’escletxa és al costat de la VPC, així que compareu amb la taula de rutes de la subxarxa d’associació.

Un paràmetre del costat client trenca l’encaminament sense trencar el túnel: un perfil que conté route-nopull. La directiva diu a un client basat en OpenVPN que ignori les rutes que empeny el servidor, de manera que la interfície puja només amb l’adreça pròpia del punt de terminació i la destinació simplement no té ruta. Comproveu amb ip route show a Linux o netstat -rn a macOS si existeix una ruta per la interfície tun. Si no existeix, traieu route-nopull del perfil exportat i torneu-vos a connectar perquè s’apliquin les rutes empenyudes.

Els grups de seguretat no veuen l’adreça del vostre client

Aquesta és la part que vaig tenir malament tota una tarda. Per a un punt de terminació IPv4 associat a una subxarxa, el servei tradueix l’adreça d’origen del client a l’adreça de la interfície de xarxa del punt de terminació en aquesta subxarxa. El paquet que arriba a la instància no porta l’adreça que mostrava el vostre client, així que una regla de grup de seguretat que permeti el pool de clients, poseu 172.16.0.0/22, no coincideix amb res.

Permeteu el port des del grup de seguretat del punt de terminació, que va enganxat a la interfície de l’associació, i no des del CIDR de client. Referenciar el grup és més durador que codificar una adreça en ferm, perquè l’adreça de la interfície no és vostra per controlar-la. Les ACL de xarxa no guarden estat, així que on hi ha entrades personalitzades, tant la direcció d’entrada com la de sortida han de permetre el flux.

Connecteu-vos també a l’adreça privada de la instància. Una IP pública treu el paquet de la VPC i el torna a fer entrar per un camí diferent amb regles diferents, així que una prova per l’adreça pública no diu res del camí privat.

Un ordre d’aïllament que s’atura a la primera fallada

Recorreu-los en ordre i atureu-vos on una falli. Cada pas descarta una capa en lloc de totes.

1. Confirmeu quina identitat ha fet servir la sessió i quin grup avalua el punt de terminació. Un certificat d’un magatzem de confiança no és el mateix principal que una asserció SAML del directori.
2. Confirmeu que una regla d’autorització cobreix el CIDR del recurs per a aquest grup.
3. Confirmeu que existeix una ruta del punt de terminació i apunta a una subxarxa associada, i després que la taula de rutes de la subxarxa pot reenviar més enllà.
4. Confirmeu que el grup de seguretat permet el port des de la interfície del punt de terminació i no des del pool de clients.
5. Proveu des de dins de la VPC, amb una sessió SSM en una altra instància de la mateixa subxarxa, per separar un problema d’aplicació d’un problema del camí del client.

Quan els passos no són decisius, aquesta taula és el meu recurs:

Dos detalls del compte produeixen símptomes que semblen fallades de permisos. Cada usuari necessita un certificat de client diferent; compartir-ne un entre dues màquines fa que les sessions es desplacin mútuament, i el resultat és un bucle de reconnexió en lloc d’una denegació. Quan es crea un punt de terminació nou, la consola mostra un nom DNS que algunes versions del client només accepten amb el prefix aleatori que apareix a la pàgina del punt de terminació, així que copieu el nom complet en lloc de reconstruir-lo.

Si el cinquè pas us bloqueja, baixeu el registre de connexions del punt de terminació i llegiu les entrades d’autorització abans de canviar res. El registre anomena la destinació comprovada i la regla que hi va coincidir o no, cosa que redueix la pregunta de quatre capes a una sola resposta.