CloudFront-geoblokkering agter 'n VPN: diagnoseer die uitgang

'n Geoblokkade is 'n besluit oor 'n IP-adres, en 'n VPN verander watter adres die diens sien. Daardie enkele sin verduidelik die meeste verwarrende verslae wat by 'n ondersteuningsry uitkom: “die webwerf werk by die huis en faal op die tonnel” en “die webwerf werk op die tonnel maar niemand anders in die kantoor kan dit laai nie” is dieselfde meganisme wat teenoorgestelde uitkomste lewer. Hierdie werkboek stap die diagnose in die volgorde wat oorsake uitskakel, beginnend met wat die rand jou werklik vertel het. Dieselfde uitgangsadres kan een beheer slaag en die volgende faal, want elke beheer evalueer 'n ander eienskap van daardie adres.

Lees die 403 voordat jy enigiets verander

'n Geoblokkade en 'n WAF-blokkade kom albei as 403 aan, en hulle word op verskillende plekke herstel. Vang die reaksiekopskrifte en die eerste reël van die liggaam, want CloudFront sluit 'n kasopskrif en 'n rede-string in wat jou vertel watter laag geantwoord het:

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

Wanneer die verspreiding self die versoek weens geografie geblokkeer het, dra die liggaam 'n boodskap wat die landbeperking noem. Wanneer 'n WAF-reël dit geblokkeer het, is die liggaam gewoonlik 'n generiese verbode bladsy en die verspreidingsversoek-ID in die kopskrifte is wat jy na die WAF-logs neem. Om dit verkeerd te kry, stuur jou na die landtoelaatlys vir 'n probleem met 'n koersgebaseerde reël, wat 'n dag se werk is wat nie kan slaag nie.

Stap 1: bevestig watter adres die verspreiding sien

Vra die netwerk wat die buitewêreld sien, vanaf dieselfde masjien en dieselfde roete wat die falende blaaier gebruik. curl -s https://checkip.amazonaws.com gee die oproeper se publieke adres terug, wat vir 'n VPN-kliënt die uitgang eerder as die intekenaar se tuisverbinding is:

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

As daardie adres aan jou verskaffer se uitgang in 'n ander land behoort, is die geobesluit reeds geneem en niks op die kliënt sal dit verander nie. Skryf die adres in die kaartjie voordat jy aan 'n instelling raak, want dit is die enigste feit in die verslag waaroor jy en die diens dit eens is.

Stap 2: skei land van reputasie

CloudFront bepaal die kyker se ligging uit 'n derdeparty-GeoIP-databasis wat op die versoek se bronadres gesleutel is, en die kartering is benaderd en streeksgebonde eerder as 'n presiese vaststelling. Wanneer die ligging nie bepaal kan word nie, is die gedokumenteerde verstek om die inhoud te lewer. Daar is dus drie moontlike toestande: die uitgang karteer na 'n geblokkeerde land, die uitgang karteer na 'n toegelate land, of die databasis het geen mening nie en die versoek gaan voort.

'n Gebruiker in 'n geblokkeerde land kan voorkom asof hy in 'n toegelate land is as die verskaffer 'n uitgang daar het, en 'n gebruiker in 'n toegelate land kan geblokkeer word omdat die uitgang elders geregistreer is. Nie een van die uitkomste bewys dat die beperking stukkend is nie. Albei is die beperking wat werk op die adres wat dit gegee is, soos die CloudFront-dokumentasie oor geobeperkings beskryf.

Reputasie is die tweede as en dit oorleef die tonnel. Die AWS WAF-bestuurde reëlgroep vir anonieme IP's is gebou om versoeke van VPN's, proxys, Tor-nodes en gasheerverskaffers te blokkeer, so 'n versoek wat die landtoets slaag, kan steeds geweier word weens wat die adres is, nie waar dit is nie. As die blokkade begin het toe jy die tonnel na 'n wolkgasheer geskuif het, is dit waarskynlik die laag.

Stap 3: kyk na die kwotagedrag

Gedeelde uitgange faal op 'n derde manier. Koerslimiete per IP en sessietellings behandel een adres as een kliënt, en 'n verbruikersuitgang dra baie intekenare gelyktydig, so 'n versoekpatroon wat van 'n tuisverbinding onopsigtelik lyk, lyk soos outomatisering vanaf die uitgang. Die simptoom is beperking of 'n tydelike blokkade wat vanself opklaar, nie 'n geografiese foutboodskap nie.

'n Verspreiding kan ook doelbewus sessies per adres tel, byvoorbeeld met 'n Lambda@Edge-funksie wat na DynamoDB skryf. Dit identifiseer nie die persoon agter die uitgang nie, maar dit laat een adres soos een kliënt optree, wat dikwels die werklike bedoeling is. Teken die afsonderlike adresse agter 'n klag aan voordat jy enige drempel verstel, want 'n korporatiewe NAT voor tweehonderd lessenaars lyk van buite presies soos 'n besige uitgang. Verwag vals positiewes van korporatiewe NAT, 'n universiteitsnetwerk of 'n groot huishouding wat almal 'n enkele adres aanbied.

Kyk na die WAF se gesamplede versoeke en koersgebaseerde reëlmaatstaf voordat jy geografie blameer. 'n Reël wat op die uitgang se versoekvolume afvuur, laat 'n duidelike handtekening, en dit vertel jou ook of die oplossing 'n limietaanpassing of 'n ander uitgangspad is.

Wat om te verander, en in watter volgorde

Besluit eers waarvoor die beheer is. Om 'n streekkatalogus te hou, misbruik te beperk en 'n kontrak af te dwing is drie verskillende doelwitte, en slegs die eerste word deur 'n landlys aangespreek. As die doel misbruikbeheer is, is die uitgang die verkeerde eenheid van identiteit, en geen hoeveelheid toelaatlyste sal 'n gedeelde adres betroubaar maak nie.

As 'n stabiele adres werklik vir 'n toelaatlys nodig is, help 'n toegewyde of statiese uitgang omdat die adres geregistreer kan word en nie roteer nie. Dit maak nie die adres residensieel nie, en dit verander nie die land wat 'n GeoIP-databasis daaraan toeken nie. Om uitgange te roteer tot een werk, is 'n tydelike reputasieverandering, nie 'n oplossing vir die beleid nie.

Skryf dan die uitkoms in die terme wat die versoeker gebruik het: hierdie adres word deur land, deur reputasie of deur koers geblokkeer, en dit is die beheer wat sal verander. Enigiets vager nooi dieselfde kaartjie volgende week met 'n ander uitgang uit.