Una restrizione geografica è una decisione su un indirizzo IP, e una VPN cambia quale indirizzo vede il servizio. Quella singola frase spiega la maggior parte delle segnalazioni confuse che arrivano a una coda di supporto: «il sito funziona a casa e fallisce sul tunnel» e «il sito funziona sul tunnel ma nessun altro in ufficio riesce a caricarlo» sono lo stesso meccanismo che produce esiti opposti. Questo manuale percorre la diagnosi nell'ordine che esclude le cause, partendo da ciò che l'edge vi ha realmente detto. Lo stesso indirizzo di uscita può superare un controllo e fallire il successivo, perché ogni controllo valuta una proprietà diversa di quell'indirizzo.

Leggete il 403 prima di cambiare qualsiasi cosa

Un blocco geografico e un blocco WAF arrivano entrambi come 403, e si correggono in luoghi diversi. Catturate le intestazioni della risposta e la prima riga del corpo, perché CloudFront include un'intestazione della cache e una stringa di motivo che vi dicono quale livello ha risposto:

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 la distribuzione stessa ha bloccato la richiesta per geografia, il corpo porta un messaggio che nomina la restrizione del paese. Quando l'ha bloccata una regola WAF, il corpo è di solito una pagina generica di divieto e l'ID richiesta della distribuzione nelle intestazioni è ciò che portate nei log WAF. Sbagliare qui vi manda all'elenco dei paesi consentiti per un problema di regola basata sul tasso, che è una giornata di lavoro che non può riuscire.

Passo 1: confermate quale indirizzo vede la distribuzione

Chiedete alla rete cosa vede il mondo esterno, dalla stessa macchina e dalla stessa rotta usata dal browser che fallisce. curl -s https://checkip.amazonaws.com restituisce l'indirizzo pubblico del chiamante, che per un client VPN è l'uscita invece della connessione domestica dell'abbonato:

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

Se quell'indirizzo appartiene all'uscita del vostro provider in un altro paese, la decisione geografica è già presa e nulla sul client la cambierà. Scrivete l'indirizzo nel ticket prima di toccare un'impostazione, perché è l'unico fatto del rapporto su cui voi e il servizio siete d'accordo.

Passo 2: separate il paese dalla reputazione

CloudFront determina la posizione dello spettatore da un database GeoIP di terze parti basato sull'indirizzo di origine della richiesta, e la corrispondenza è approssimativa e regionale, non una localizzazione precisa. Quando la posizione non può essere determinata, il valore predefinito documentato è servire il contenuto. Ci sono quindi tre stati possibili: l'uscita è associata a un paese bloccato, a un paese consentito, oppure il database non ha un'opinione e la richiesta procede.

Un utente in un paese bloccato può sembrare in uno consentito se il provider ha un'uscita lì, e un utente in un paese consentito può essere bloccato perché l'uscita è registrata altrove. Nessuno dei due esiti dimostra che la restrizione sia rotta. Entrambi sono la restrizione che agisce sull'indirizzo che le è stato dato, come descrive la documentazione CloudFront sulle restrizioni geografiche.

La reputazione è il secondo asse e sopravvive al tunnel. Il gruppo di regole gestite AWS WAF per IP anonimi è costruito per bloccare richieste da VPN, proxy, nodi Tor e provider di hosting, quindi una richiesta che supera il controllo del paese può ancora essere rifiutata per ciò che l'indirizzo è, non per dove si trova. Se il blocco è iniziato quando avete spostato il tunnel su un host cloud, questo è probabilmente il livello.

Passo 3: controllate il comportamento della quota

Le uscite condivise falliscono in un terzo modo. I limiti di frequenza per IP e i conteggi delle sessioni trattano un indirizzo come un solo client, e un'uscita consumer porta molti abbonati insieme, quindi un modello di richieste insignificante da una connessione domestica sembra automazione dall'uscita. Il sintomo è una limitazione o un blocco temporaneo che si dissolve da solo, non un messaggio di errore geografico.

Una distribuzione può anche contare deliberatamente le sessioni per indirizzo, per esempio con una funzione Lambda@Edge che scrive su DynamoDB. Questo non identifica la persona dietro l'uscita, ma fa comportare un indirizzo come un solo client, che spesso è l'intento reale. Registrate gli indirizzi distinti dietro un reclamo prima di regolare qualsiasi soglia, perché un NAT aziendale davanti a duecento scrivanie sembra esattamente un'uscita occupata dall'esterno. Aspettatevi falsi positivi da NAT aziendale, una rete universitaria o una grande famiglia che presentano tutti un solo indirizzo.

Guardate le richieste campionate del WAF e le metriche delle regole basate sul tasso prima di incolpare la geografia. Una regola che scatta sul volume di richieste dell'uscita lascia una firma chiara, e vi dice anche se la correzione è una regolazione del limite o un percorso di uscita diverso.

Cosa cambiare, e in quale ordine

Decidete prima a cosa serve il controllo. Mantenere un catalogo regionale, limitare gli abusi e far rispettare un contratto sono tre obiettivi diversi, e solo il primo è affrontato da un elenco di paesi. Se l'obiettivo è il controllo degli abusi, l'uscita è l'unità di identità sbagliata, e nessuna quantità di elenchi consentiti renderà affidabile un indirizzo condiviso.

Se serve davvero un indirizzo stabile per un elenco consentito, un'uscita dedicata o statica aiuta perché l'indirizzo può essere registrato e non ruota. Non rende l'indirizzo residenziale, e non cambia il paese che un database GeoIP gli assegna. Ruotare le uscite finché una funziona è un cambiamento temporaneo di reputazione, non una correzione della politica.

Poi scrivete l'esito con i termini usati dal richiedente: questo indirizzo è bloccato per paese, per reputazione o per tasso, e questo è il controllo che cambierà. Qualsiasi cosa più vaga invita lo stesso ticket la settimana prossima con un'uscita diversa.

Articoli correlati