Accés intermitent amb AWS Client VPN: auditeu cada subxarxa associada

Un usuari es connecta, obre l’aplicació interna i obté resposta; un company al mateix punt final rep un temps d’espera des d’un portàtil idèntic a la mateixa Wi-Fi. Aquest patró és la signatura d’un punt final de client VPN amb més d’una subxarxa associada, on els camins no són equivalents. Ho recorro des de la consola cap enfora, perquè dues pestanyes decideixen si la resta de la investigació val la pena. Res de la configuració del client ho explica.

Comenceu pel punt final i lliste les associacions

A la consola de la VPC, obriu Client VPN endpoints, trieu el punt final i llegiu la pestanya Associations. Cada associació és una subxarxa en una zona de disponibilitat, i el client aterra a la que tria el servei quan es construeix la connexió. Anoteu els identificadors de subxarxa i la taula de rutes que realment fa servir cadascuna, perquè aquestes dues llistes són la comparació que esteu a punt de fer.

Si el punt final mostra una sola associació, aquesta teoria és falsa i el client és el millor sospitós.

Compareu la taula de rutes del punt final amb cada associació

Obriu la pestanya Route table al mateix punt final. Cada CIDR de destinació té un objectiu, i en un client VPN l’objectiu és una associació i no una passarel·la. AWS exigeix una entrada de destinació per a cada subxarxa associada, de manera que una ruta que només n’apunta una fa que l’accés depengui d’on ha aterrat la sessió. Reviseu la destinació que realment us importa i després la seva regla d’autorització, perquè la ruta dona el camí i la regla decideix qui el pot fer servir.

Quan tabuleu les dues capes, la fallada és difícil de no veure.

La segona fila és tot el problema en la majoria de tiquets. La ruta del punt final hi és, així que ningú mira més enllà, i el paquet mor un salt després dins de la VPC.

Seguiu cada subxarxa fins a la seva taula de rutes efectiva

Una subxarxa sense associació explícita a una taula de rutes hereta la taula principal de la VPC. Llegiu la taula que realment està en vigor, no la que sembla que té el nom correcte, i compareu destinació i objectiu en lloc de l’etiqueta de la fila.

La guia d’AWS sobre accés intermitent ho planteja com a cobertura de rutes entre associacions, que és el model correcte. El punt final porta el paquet a una subxarxa, i la taula d’aquesta subxarxa encara ha de saber on viu la xarxa de l’aplicació.

Corregiu la fila que falta a la taula que la posseeix. Copiar tota una taula de rutes d’una subxarxa que funciona també copia decisions d’internet, aparells i aïllament que mai no estaven pensades per a aquesta, i aquest intercanvi sol ser pitjor que la caiguda amb què vau començar.

Reviseu les regles d’autorització i després el camí de tornada

Les regles d’autorització són per destinació i per grup, i s’avaluen per separat de les rutes. Una destinació amb rutes pertot arreu però sense regla per al grup de l’usuari es comporta com un forat negre amb una taula de rutes que sembla sana.

El camí de tornada mereix la mateixa atenció. Una connexió de peering necessita una ruta a la VPC de l’aplicació que apunti cap al CIDR del client, regles de grup de seguretat que permetin el trànsit als dos extrems i ACL de xarxa que no el descartin. L’abast unilateral, on ping funciona i l’apretada de mans TCP no, sol apuntar a una ACL o un grup de seguretat i no a la VPN.

Els grups de seguretat del propi punt final seuen sobre les interfícies de xarxa elàstiques de l’associació, així que una regla que permeti el port de l’aplicació des del CIDR del client s’ha d’adjuntar a l’associació, no només a la instància.

Verifiqueu amb una reconnexió, no amb una petició afortunada

Amb túnel dividit, les rutes del punt final s’empenyen quan s’estableix la connexió, així que un conjunt de rutes canviat mai arriba a un client que es queda connectat. Desconnecteu i torneu a connectar amb el client suportat, i després confirmeu que les rutes noves són a la màquina.

Finalment, correlacioneu el registre de connexions amb l’adreça que va rebre el client i repetiu la prova prou vegades per topar amb més d’una associació. Una sola petició correcta després d’una correcció demostra que un camí funciona, i el tiquet era sobre l’altre.