CloudFront-geoblockering bakom en VPN: diagnostisera utgången

En geografisk begränsning är ett beslut om en IP-adress, och en VPN ändrar vilken adress tjänsten ser. Den enda meningen förklarar de flesta förvirrande rapporterna som når en supportkö: «sajten fungerar hemma och misslyckas på tunneln» och «sajten fungerar på tunneln men ingen annan på kontoret kan ladda den» är samma mekanism med motsatta resultat. Den här runbooken går igenom diagnostiken i den ordning som utesluter orsaker, med början i vad edge:n faktiskt berättade för dig. Samma utgångsadress kan klara en kontroll och misslyckas i nästa, eftersom varje kontroll bedömer en annan egenskap hos den adressen.

Läs 403:an innan du ändrar något

En geoblockering och en WAF-blockering kommer båda som 403, och de åtgärdas på olika ställen. Spara svarshuvudena och första raden i brödtexten, eftersom CloudFront lägger till ett cachehuvud och en orsakssträng som berättar vilket lager som svarade:

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

När distributionen själv blockerade begäran på grund av geografi bär kroppen ett meddelande som namnger landbegränsningen. När en WAF-regel blockerade den är kroppen vanligtvis en generisk förbjuden-sida och distributionens begärande-ID i huvudena är det du tar med till WAF-loggarna. Ett misstag här skickar dig till ländernas allowlist för ett problem med en hastighetsbaserad regel, vilket är en arbetsdag som inte kan lyckas.

Steg 1: bekräfta vilken adress distributionen ser

Fråga nätverket vad omvärlden ser, från samma maskin och samma rutt som den misslyckade webbläsaren använder. curl -s https://checkip.amazonaws.com returnerar anroparens offentliga adress, som för en VPN-klient är utgången snarare än abonnentens hemanslutning:

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

Om den adressen tillhör leverantörens utgång i ett annat land är det geografiska beslutet redan fattat och ingenting på klienten kommer att ändra det. Skriv adressen i ärendet innan du rör en inställning, eftersom det är det enda faktum i rapporten som du och tjänsten är överens om.

Steg 2: skilj land från rykte

CloudFront bestämmer tittarens plats från en tredjeparts GeoIP-databas som är nycklad till begärans källadress, och mappningen är ungefärlig och regional snarare än en exakt bestämning. När platsen inte kan bestämmas är den dokumenterade standarden att ändå leverera innehållet. Det finns alltså tre möjliga tillstånd: utgången mappas till ett blockerat land, till ett tillåtet land, eller databasen har ingen åsikt och begäran fortsätter.

En användare i ett blockerat land kan se ut att vara i ett tillåtet land om leverantören har en utgång där, och en användare i ett tillåtet land kan blockeras eftersom utgången är registrerad någon annanstans. Ingen av utgångarna bevisar att begränsningen är trasig. Båda är begränsningen som verkar på den adress den fick, som CloudFront-dokumentationen om geografiska begränsningar beskriver.

Rykte är den andra axeln och det överlever tunneln. Den hanterade AWS WAF-regelgruppen för anonyma IP-adresser är byggd för att blockera begäranden från VPN:er, proxyservrar, Tor-noder och hostingleverantörer, så en begäran som klarar landskontrollen kan ändå avvisas på grund av vad adressen är, inte var den är. Om blockeringen började när du flyttade tunneln till en molnvärd är det förmodligen det lagret.

Steg 3: undersök kvotbeteendet

Delade utgångar misslyckas på ett tredje sätt. Hastighetsgränser per IP och sessionsräkningar behandlar en adress som en klient, och en konsumentutgång bär många abonnenter samtidigt, så ett begärandemönster som är oansenligt från en hemanslutning ser ut som automatisering från utgången. Symtomet är begränsning eller en tillfällig blockering som försvinner av sig själv, inte ett geografiskt felmeddelande.

En distribution kan också medvetet räkna sessioner per adress, till exempel med en Lambda@Edge-funktion som skriver till DynamoDB. Det identifierar inte personen bakom utgången, men får en adress att bete sig som en klient, vilket ofta är den egentliga avsikten. Logga de olika adresserna bakom ett klagomål innan du justerar någon tröskel, eftersom ett företags-NAT framför tvåhundra skrivbord utifrån ser precis ut som en upptagen utgång. Förvänta dig falska positiva från företags-NAT, ett universitetsnätverk eller ett stort hushåll som alla presenterar en enda adress.

Titta på WAF:ens samplade begäranden och mätvärden för hastighetsbaserade regler innan du skyller på geografin. En regel som utlöses av utgångens begärandevolym lämnar en tydlig signatur, och den berättar också om åtgärden är en gränsjustering eller en annan utgångsväg.

Vad som ska ändras, och i vilken ordning

Bestäm först vad kontrollen är till för. Att upprätthålla en regional katalog, begränsa missbruk och genomdriva ett avtal är tre olika mål, och bara det första hanteras av en landslista. Om målet är missbrukskontroll är utgången fel identitetsenhet, och ingen mängd allowlistor kommer att göra en delad adress pålitlig.

Om en stabil adress verkligen behövs för en allowlist hjälper en dedikerad eller statisk utgång eftersom adressen kan registreras och inte roterar. Det gör inte adressen bostadsmässig, och det ändrar inte det land som en GeoIP-databas tilldelar den. Att rotera utgångar tills en fungerar är en tillfällig ryktesförändring, inte en åtgärd för policyn.

Skriv sedan resultatet med de termer som ärendets ägare använde: den här adressen är blockerad efter land, efter rykte eller efter hastighet, och det här är kontrollen som kommer att ändras. Något mer vagt bjuder in samma ärende igen nästa vecka med en annan utgång.