AWS Client VPN connectat però sense accés a internet: comprovació de rutes

Esteu connectat a l’endpoint d’AWS Client VPN, la subxarxa privada respon i, tot i així, cada pàgina pública acaba en temps d’espera esgotat. Aquesta combinació redueix el problema a un dels tres objectes del costat gestionat: la ruta que instal·la el client, la ruta de l’endpoint juntament amb la seva regla d’autorització, o el següent salt de la subxarxa associada. Les comprovo en aquest ordre perquè cada fallada es veu diferent des del client. Aquest manual cobreix l’endpoint gestionat associat a la VPC, no un servidor OpenVPN en una instància EC2 ni una associació de Cloud WAN o Transit Gateway.

Comenceu pel que el client encamina realment

L’estat connectat demostra la sessió TLS i l’assignació de CIDR al client, res més. Pregunteu al sistema operatiu on aniria una adreça pública mentre el túnel és actiu. A Linux, ip route get 1.1.1.1 ha de nomenar la interfície del túnel; a macOS, netstat -rn -f inet | head -5 mostra l’entrada per defecte; a Windows, Find-NetRoute -RemoteIPAddress 1.1.1.1 imprimeix la interfície triada i el següent salt.

Després llegiu el senyalador de túnel dividit, perquè decideix si les rutes publicades per l’endpoint són les úniques destinacions que el client envia al túnel:

aws ec2 describe-client-vpn-endpoints \
  --client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 \
  --query 'ClientVpnEndpoints[0].SplitTunnel'

Amb SplitTunnel a true, una destinació pública fa servir el túnel només quan l’endpoint publica una ruta que la cobreix, així que una 0.0.0.0/0 absent deixa aquest trànsit a la interfície local. Amb el valor a false, el client captura el trànsit, però l’endpoint encara l’ha d’encaminar i autoritzar; si no, els paquets entren al túnel i s’hi aturen. Torneu a connectar el client després de canviar qualsevol dels dos paràmetres, perquè les rutes i els servidors DNS es lliuren en el moment de la connexió i un client en marxa pot conservar el conjunt antic.

Llegiu la ruta de l’endpoint i la regla d’autorització per separat

Són dos objectes, i crear-ne un no crea l’altre. Lliste les rutes de l’endpoint i busqueu una ruta per defecte el destí de la qual sigui una subxarxa associada:

aws ec2 describe-client-vpn-routes \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0

Cada ruta té exactament una subxarxa de destí, així que tres associacions necessiten una ruta per defecte corresponent per a cadascuna. AWS documenta aquest requisit de cobertura, i el símptoma pràctic d’una mancança és un usuari que treballa des d’una subxarxa i s’encalla des d’una altra, cosa que es llegeix com una fallada intermitent en lloc d’una ruta absent. La documentació oficial de l’escenari de Client VPN descriu la disposició de subxarxa pública a què pertanyen aquestes rutes.

L’autorització és el segon objecte. Quan cap regla no cobreix la destinació pública, el túnel porta el paquet i el servei el descarta, així que els recursos privats continuen funcionant mentre internet no ho fa:

aws ec2 describe-client-vpn-authorization-rules \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0

Una regla per al CIDR de la VPC no diu res sobre 0.0.0.0/0. Afegir les peces que falten per a un túnel complet vol dir una ruta per subxarxa associada més una regla d’autorització que pugueu auditar després:

aws ec2 create-client-vpn-route \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --target-vpc-subnet-id subnet-0a1b2c3d4e5f67890
aws ec2 create-client-vpn-authorization-rule \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --access-all \
  --description "internet egress for full tunnel"

--access-all concedeix la destinació a cada client de l’endpoint, així que manteniu-lo només mentre el túnel hagi de ser complet; una regla lligada a un grup de directori és preferible quan teniu grups on lligar-la.

Seguiu el paquet fora de la subxarxa associada

La ruta de l’endpoint decideix que AWS lliura el paquet a aquesta subxarxa. No decideix el següent salt més enllà, que viu a la taula de rutes VPC pròpia de la subxarxa:

aws ec2 describe-route-tables \
  --filters Name=association.subnet-id,Values=subnet-0a1b2c3d4e5f67890 \
  --query 'RouteTables[].Routes[?DestinationCidrBlock==`0.0.0.0/0`]'

Una ruta per defecte utilitzable apunta a una internet gateway per a una subxarxa pública, o a una NAT gateway per a una de privada, i un estat blackhole significa que la destinació s’ha eliminat i el camí ara mor en silenci. Són taules diferents de la llista de rutes de l’endpoint, i reparar-ne una no repara l’altra.

En aquest salt hi ha dos filtres. El grup de seguretat aplicat a l’associació de xarxa de destí ha de permetre el trànsit de sortida cap a la destinació pública, i qualsevol ACL de xarxa aplicable ha de permetre la sol·licitud i el trànsit de tornada en ports efímers. Un grup de seguretat d’associació restrictiu és una causa habitual que l’accés privat funcioni i el públic no.

Trieu la primera capa a partir del símptoma en lloc de canviar les tres alhora:

Separeu la fallada de DNS d’una ruta morta

La resolució de noms falla de manera diferent de l’encaminament, i el túnel complet fa que la diferència importi perquè ara s’arriba al resolutor empès a través del túnel. Si l’endpoint especifica servidors DNS de la VPC, les seves adreces necessiten cobertura de ruta i autorització com qualsevol altra destinació. Consulteu el resolutor directament per veure quina fallada teniu: dig +short example.com @10.0.0.2, o nslookup example.com 10.0.0.2 a Windows.

Quan un URL numèric respon i un de nomenat no, deixeu d’editar la ruta per defecte i treballeu el DNS. Una sol·licitud a una adreça IP no demostra res sobre un host virtual nomenat i el seu certificat, així que manteniu una prova nomenada a la comprovació final.

El temps ajuda. Una connexió TCP que no rep resposta en uns quants segons apunta a l’encaminament o a un filtre, mentre que una sol·licitud que es penja dins de la cerca de nom apunta al resolutor. Canviar la ruta per defecte mentre el resolutor és inaccessible sol convertir una fallada en dues.

Revertiu net, i després verifiqueu el camí de sortida

Tots dos objectes eren additius, així que la reversió és esborrar i no reparar:

aws ec2 delete-client-vpn-route \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --target-vpc-subnet-id subnet-0a1b2c3d4e5f67890
aws ec2 delete-client-vpn-authorization-rule \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --access-all

Torneu a connectar-vos i confirmeu per quin camí surt el trànsit. Compareu l’adreça pública observada amb l’adreça IP elàstica de la NAT gateway, o amb la internet gateway que volíeu utilitzar, i comproveu que un recurs privat encara respon a la mateixa sessió.

Acabeu amb una llista curta i tracteu l’últim element com a part del canvi i no com a documentació:

• Una 0.0.0.0/0 ruta d’endpoint per a cada subxarxa associada.
• Una regla d’autorització que cobreixi 0.0.0.0/0 per als clients que voleu atendre.
• Una ruta per defecte de VPC que no estigui en estat blackhole a cada subxarxa associada.
• Sortida del grup de seguretat de l’associació, més el trànsit de tornada de l’ACL.
• Adreces del resolutor encaminades i autoritzades, verificades amb una sol·licitud nomenada.
• Una reversió registrada per a la ruta i la regla.

Una nota d’abast: aquest és un camí IPv4. Un client de doble pila conserva la connectivitat IPv6 que ja tingui, així que una ruta per defecte IPv6 és una decisió separada amb la seva pròpia autorització i no un efecte secundari d’aquesta.