Bloqueo geográfico de CloudFront tras una VPN: diagnosticar la salida

Una restricción geográfica es una decisión sobre una dirección IP, y una VPN cambia qué dirección ve el servicio. Esa sola frase explica la mayoría de los informes confusos que llegan a una cola de soporte: «el sitio funciona en casa y falla en el túnel» y «el sitio funciona en el túnel pero nadie más en la oficina puede cargarlo» son el mismo mecanismo produciendo resultados opuestos. Este manual recorre el diagnóstico en el orden que descarta causas, empezando por lo que el edge realmente le dijo. La misma dirección de salida puede superar un control y fallar el siguiente, porque cada control evalúa una propiedad distinta de esa dirección.

Lea el 403 antes de cambiar nada

Un bloqueo geográfico y un bloqueo de WAF llegan ambos como 403, y se corrigen en lugares distintos. Capture las cabeceras de respuesta y la primera línea del cuerpo, porque CloudFront incluye una cabecera de caché y una cadena de motivo que le dicen qué capa respondió:

curl -sS -o /tmp/body.txt -D /tmp/headers.txt https://d111111abcdef8.cloudfront.net/
grep -i "x-cache\|via" /tmp/headers.txt
head -c 300 /tmp/body.txt

Cuando la propia distribución bloqueó la petición por geografía, el cuerpo lleva un mensaje que nombra la restricción de país. Cuando la bloqueó una regla de WAF, el cuerpo suele ser una página genérica de prohibido y el identificador de petición de la distribución en las cabeceras es lo que lleva a los registros de WAF. Equivocarse aquí le envía a la lista de países permitidos por un problema de regla basada en tasa, que es un día de trabajo que no puede tener éxito.

Paso 1: confirme qué dirección ve la distribución

Pregunte a la red qué ve el mundo exterior, desde la misma máquina y la misma ruta que usa el navegador que falla. curl -s https://checkip.amazonaws.com devuelve la dirección pública del llamante, que para un cliente VPN es la salida en lugar de la conexión doméstica del suscriptor:

curl -s https://checkip.amazonaws.com
nslookup d111111abcdef8.cloudfront.net

Si esa dirección pertenece a la salida de su proveedor en otro país, la decisión geográfica ya está tomada y nada en el cliente la cambiará. Escriba la dirección en el ticket antes de tocar un ajuste, porque es el único hecho del informe en el que usted y el servicio coinciden.

Paso 2: separe el país de la reputación

CloudFront resuelve la ubicación del espectador a partir de una base de datos GeoIP de terceros basada en la dirección de origen de la petición, y la correspondencia es aproximada y regional, no una fijación precisa. Cuando no se puede determinar la ubicación, el valor predeterminado documentado es servir el contenido. Así que hay tres estados posibles: la salida se asigna a un país bloqueado, a un país permitido, o la base de datos no tiene opinión y la petición continúa.

Un usuario en un país bloqueado puede parecer estar en uno permitido si el proveedor tiene una salida allí, y un usuario en un país permitido puede ser bloqueado porque la salida está registrada en otro lugar. Ninguno de los resultados demuestra que la restricción esté rota. Ambos son la restricción funcionando sobre la dirección que se le dio, como describe la documentación de restricciones geográficas de CloudFront.

La reputación es el segundo eje y sobrevive al túnel. El grupo de reglas gestionadas de IP anónimas de AWS WAF está hecho para bloquear peticiones de VPN, proxies, nodos de Tor y proveedores de alojamiento, así que una petición que pasa la comprobación de país aún puede ser rechazada por lo que es la dirección, no por dónde está. Si el bloqueo empezó cuando movió el túnel a un host en la nube, esta es probablemente la capa.

Paso 3: compruebe el comportamiento de la cuota

Las salidas compartidas fallan de una tercera manera. Los límites de tasa por IP y los recuentos de sesión tratan una dirección como un cliente, y una salida de consumidor lleva muchos suscriptores a la vez, así que un patrón de peticiones que resulta anodino desde una conexión doméstica parece automatización desde la salida. El síntoma es una limitación o un bloqueo temporal que se despeja solo, no un mensaje de error geográfico.

Una distribución también puede contar sesiones por dirección a propósito, por ejemplo con una función Lambda@Edge que escribe en DynamoDB. Eso no identifica a la persona tras la salida, pero hace que una dirección se comporte como un cliente, que a menudo es la intención real. Registre las direcciones distintas tras una queja antes de ajustar cualquier umbral, porque un NAT corporativo frente a doscientas mesas parece exactamente una salida ocupada desde fuera. Espere falsos positivos de NAT corporativo, una red universitaria o un hogar grande que todos presentan una sola dirección.

Mire las peticiones muestreadas del WAF y las métricas de reglas basadas en tasa antes de culpar a la geografía. Una regla que se activa con el volumen de peticiones de la salida deja una firma clara, y también le dice si la corrección es un ajuste de límite o una ruta de salida distinta.

Qué cambiar y en qué orden

Primero decida para qué sirve el control. Mantener un catálogo regional, limitar el abuso e imponer un contrato son tres objetivos distintos, y solo el primero se aborda con una lista de países. Si el objetivo es el control de abuso, la salida es la unidad de identidad equivocada, y ninguna cantidad de listas permitidas hará fiable una dirección compartida.

Si de verdad se necesita una dirección estable para una lista permitida, una salida dedicada o estática ayuda porque la dirección se puede registrar y no rota. No hace que la dirección sea residencial, ni cambia el país que una base de datos GeoIP le asigna. Rotar salidas hasta que una funcione es un cambio temporal de reputación, no una solución para la política.

Luego escriba el resultado con los términos que usó el solicitante: esta dirección está bloqueada por país, por reputación o por tasa, y este es el control que cambiará. Cualquier cosa más vaga invita al mismo ticket la próxima semana con una salida distinta.