Bloqueo xeográfico de CloudFront tras unha VPN: diagnosticar a saída

Unha restrición xeográfica é unha decisión sobre un enderezo IP, e unha VPN cambia que enderezo ve o servizo. Esa soa frase explica a maioría dos informes confusos que chegan a unha cola de soporte: «o sitio funciona na casa e falla no túnel» e «o sitio funciona no túnel pero ninguén máis na oficina pode cargalo» son o mesmo mecanismo producindo resultados opostos. Este manual percorre o diagnóstico na orde que descarta causas, comezando polo que o edge realmente che dixo. O mesmo enderezo de saída pode superar un control e fallar o seguinte, porque cada control avalía unha propiedade distinta dese enderezo.

Le o 403 antes de cambiar nada

Un bloqueo xeográfico e un bloqueo de WAF chegan ambos como 403, e corrixense en lugares distintos. Captura as cabeceiras de resposta e a primeira liña do corpo, porque CloudFront inclúe unha cabeceira de caché e unha cadea de motivo que che din que capa respondeu:

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

Cando a propia distribución bloqueou a petición por xeografía, o corpo leva unha mensaxe que nomea a restrición de país. Cando a bloqueou unha regra de WAF, o corpo adoita ser unha páxina xenérica de prohibido e o identificador de petición da distribución nas cabeceiras é o que levas aos rexistros de WAF. Equivocarse aquí envíate á lista de países permitidos por un problema de regra baseada en taxa, que é un día de traballo que non pode ter éxito.

Paso 1: confirma que enderezo ve a distribución

Pregunta á rede que ve o mundo exterior, desde a mesma máquina e a mesma ruta que usa o navegador que falla. curl -s https://checkip.amazonaws.com devolve o enderezo público do chamante, que para un cliente VPN é a saída en lugar da conexión doméstica do subscritor:

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

Se ese enderezo pertence á saída do teu provedor noutro país, a decisión xeográfica xa está tomada e nada no cliente a cambiará. Escribe o enderezo no tícket antes de tocar un axuste, porque é o único feito do informe no que ti e o servizo coincidides.

Paso 2: separa o país da reputación

CloudFront resolve a localización do espectador a partir dunha base de datos GeoIP de terceiros baseada no enderezo de orixe da petición, e a correspondencia é aproximada e rexional, non unha fixación precisa. Cando non se pode determinar a localización, o valor predeterminado documentado é servir o contido. Así que hai tres estados posibles: a saída mapéase a un país bloqueado, a un país permitido, ou a base de datos non ten opinión e a petición continúa.

Un usuario nun país bloqueado pode parecer estar nun permitido se o provedor ten unha saída alí, e un usuario nun país permitido pode ser bloqueado porque a saída está rexistrada noutro lugar. Ningún dos resultados demostra que a restrición estea rota. Ambos son a restrición funcionando sobre o enderezo que se lle deu, como describe a documentación de restricións xeográficas de CloudFront.

A reputación é o segundo eixe e sobrevive ao túnel. O grupo de regras xestionadas de IP anónimas de AWS WAF está feito para bloquear peticións de VPN, proxies, nodos de Tor e provedores de aloxamento, así que unha petición que pasa a comprobación de país aínda pode ser rexeitada polo que é o enderezo, non por onde está. Se o bloqueo empezou cando moviches o túnel a un host na nube, esta é probablemente a capa.

Paso 3: comproba o comportamento da cota

As saídas compartidas fallan dunha terceira maneira. Os límites de taxa por IP e as contas de sesión tratan un enderezo como un cliente, e unha saída de consumidor leva moitos subscritores á vez, así que un patrón de peticións que resulta anodino desde unha conexión doméstica parece automatización desde a saída. O síntoma é unha limitación ou un bloqueo temporal que se despexa só, non unha mensaxe de erro xeográfico.

Unha distribución tamén pode contar sesións por enderezo deliberadamente, por exemplo cunha función Lambda@Edge que escribe en DynamoDB. Iso non identifica a persoa tras a saída, pero fai que un enderezo se comporte como un cliente, que adoita ser a intención real. Rexistra os enderezos distintos tras unha queixa antes de axustar calquera limiar, porque un NAT corporativo diante de douscentos escritorios parece exactamente unha saída ocupada desde fóra. Espera falsos positivos de NAT corporativo, unha rede universitaria ou un fogar grande que todos presentan un único enderezo.

Mira as peticións mostreadas do WAF e as métricas de regras baseadas en taxa antes de culpar a xeografía. Unha regra que se activa co volume de peticións da saída deixa unha sinatura clara, e tamén che di se a corrección é un axuste de límite ou unha ruta de saída distinta.

Que cambiar e en que orde

Primeiro decide para que serve o control. Manter un catálogo rexional, limitar o abuso e facer cumprir un contrato son tres obxectivos distintos, e só o primeiro se aborda cunha lista de países. Se o obxectivo é o control de abuso, a saída é a unidade de identidade equivocada, e ningunha cantidade de listas permitidas fará fiable un enderezo compartido.

Se de verdade se necesita un enderezo estable para unha lista permitida, unha saída dedicada ou estática axuda porque o enderezo se pode rexistrar e non rota. Non fai que o enderezo sexa residencial, nin cambia o país que unha base de datos GeoIP lle asigna. Rotar saídas ata que unha funcione é un cambio temporal de reputación, non unha solución para a política.

Despois escribe o resultado cos termos que usou o solicitante: este enderezo está bloqueado por país, por reputación ou por taxa, e este é o control que cambiará. Calquera cousa máis vaga invita o mesmo tícket a próxima semana cunha saída distinta.