Bloqueio geográfico do CloudFront atrás de uma VPN: diagnosticar a saída

Uma restrição geográfica é uma decisão sobre um endereço IP, e uma VPN muda qual endereço o serviço vê. Essa única frase explica a maioria dos relatos confusos que chegam a uma fila de suporte: «o site funciona em casa e falha no túnel» e «o site funciona no túnel mas ninguém mais no escritório consegue carregá-lo» são o mesmo mecanismo a produzir resultados opostos. Este manual percorre o diagnóstico na ordem que exclui causas, começando pelo que a edge realmente lhe disse. O mesmo endereço de saída pode passar um controlo e falhar o seguinte, porque cada controlo avalia uma propriedade diferente desse endereço.

Leia o 403 antes de mudar qualquer coisa

Um bloqueio geográfico e um bloqueio de WAF chegam ambos como 403, e são corrigidos em locais diferentes. Capture os cabeçalhos da resposta e a primeira linha do corpo, porque o CloudFront inclui um cabeçalho de cache e uma cadeia de motivo que lhe dizem que camada 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

Quando a própria distribuição bloqueou o pedido por geografia, o corpo traz uma mensagem que nomeia a restrição do país. Quando foi uma regra de WAF a bloquear, o corpo é normalmente uma página genérica de proibido e o ID do pedido da distribuição nos cabeçalhos é o que leva para os registos de WAF. Enganar-se aqui envia-o para a lista de países permitidos por um problema de regra baseada em taxa, o que é um dia de trabalho que não pode ter sucesso.

Passo 1: confirme que endereço a distribuição vê

Pergunte à rede o que o mundo exterior vê, a partir da mesma máquina e da mesma rota que o navegador que falha usa. curl -s https://checkip.amazonaws.com devolve o endereço público do chamador, que para um cliente VPN é a saída em vez da ligação doméstica do subscritor:

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

Se esse endereço pertence à saída do seu fornecedor noutro país, a decisão geográfica já está tomada e nada no cliente a mudará. Escreva o endereço no ticket antes de tocar numa definição, porque é o único facto do relatório em que você e o serviço concordam.

Passo 2: separe o país da reputação

O CloudFront determina a localização do espectador a partir de uma base de dados GeoIP de terceiros baseada no endereço de origem do pedido, e a correspondência é aproximada e regional, não uma determinação precisa. Quando a localização não pode ser determinada, o valor por omissão documentado é servir o conteúdo. Existem, portanto, três estados possíveis: a saída é mapeada para um país bloqueado, para um país permitido, ou a base de dados não tem opinião e o pedido segue.

Um utilizador num país bloqueado pode parecer estar num permitido se o fornecedor tiver uma saída lá, e um utilizador num país permitido pode ser bloqueado porque a saída está registada noutro lugar. Nenhum dos resultados prova que a restrição está avariada. Ambos são a restrição a funcionar sobre o endereço que lhe foi dado, como descreve a documentação de restrições geográficas do CloudFront.

A reputação é o segundo eixo e sobrevive ao túnel. O grupo de regras geridas da AWS WAF para IP anónimos foi criado para bloquear pedidos de VPN, proxies, nós Tor e fornecedores de alojamento, pelo que um pedido que passa a verificação de país ainda pode ser recusado pelo que o endereço é, não por onde está. Se o bloqueio começou quando moveu o túnel para um anfitrião na nuvem, é provavelmente essa camada.

Passo 3: verifique o comportamento da quota

As saídas partilhadas falham de uma terceira forma. Os limites de taxa por IP e as contagens de sessão tratam um endereço como um cliente, e uma saída de consumidor transporta muitos subscritores ao mesmo tempo, pelo que um padrão de pedidos banal numa ligação doméstica parece automação vista da saída. O sintoma é limitação ou um bloqueio temporário que desaparece sozinho, não uma mensagem de erro geográfico.

Uma distribuição também pode contar sessões por endereço deliberadamente, por exemplo com uma função Lambda@Edge que escreve no DynamoDB. Isso não identifica a pessoa atrás da saída, mas faz um endereço comportar-se como um cliente, o que muitas vezes é a intenção real. Registe os endereços distintos por trás de uma reclamação antes de ajustar qualquer limite, porque um NAT empresarial à frente de duzentas secretárias parece exatamente uma saída ocupada visto de fora. Espere falsos positivos de NAT empresarial, uma rede universitária ou uma casa grande que apresentam todos um único endereço.

Veja os pedidos amostrados da WAF e as métricas das regras baseadas em taxa antes de culpar a geografia. Uma regra que dispara com o volume de pedidos da saída deixa uma assinatura clara, e também lhe diz se a correção é um ajuste de limite ou um caminho de saída diferente.

O que mudar, e em que ordem

Primeiro decida para que serve o controlo. Manter um catálogo regional, limitar abusos e fazer cumprir um contrato são três objetivos diferentes, e só o primeiro é tratado por uma lista de países. Se o objetivo é o controlo de abusos, a saída é a unidade de identidade errada, e nenhuma quantidade de listas permitidas tornará um endereço partilhado fiável.

Se for realmente necessário um endereço estável para uma lista permitida, uma saída dedicada ou estática ajuda porque o endereço pode ser registado e não roda. Não torna o endereço residencial, nem muda o país que uma base de dados GeoIP lhe atribui. Rodar saídas até uma funcionar é uma mudança temporária de reputação, não uma correção da política.

Depois escreva o resultado nos termos usados pelo requerente: este endereço está bloqueado por país, por reputação ou por taxa, e é este o controlo que vai mudar. Qualquer coisa mais vaga convida o mesmo ticket na próxima semana com uma saída diferente.