Геоблокиране на CloudFront зад VPN: диагностика на изхода
Ръбът решава по адреса, който вижда, а споделеният изход променя едновременно държавата и репутацията. Тествайте всяка проверка отделно, преди да сменяте изходни възли.
Географското ограничение е решение за IP адрес, а VPN променя адреса, който услугата вижда. Това едно изречение обяснява повечето объркващи сигнали, които стигат до опашката за поддръжка: „сайтът работи вкъщи и се проваля през тунела“ и „сайтът работи през тунела, но никой друг в офиса не може да го зареди“ са един и същ механизъм с противоположни резултати. Това ръководство води диагностиката в реда, който изключва причини, започвайки с това, което ръбът действително ви е казал. Същият изходен адрес може да мине една проверка и да се провали на следващата, защото всяка проверка оценява различно свойство на този адрес.
Прочетете 403, преди да променяте каквото и да е
Геоблокирането и блокирането от WAF пристигат и двете като 403 и се поправят на различни места. Запишете заглавките на отговора и първия ред от тялото, защото CloudFront включва заглавка за кеша и низ за причина, които ви казват кой слой е отговорил:
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
Когато самото разпределение е блокирало заявката по география, тялото носи съобщение, което посочва ограничението за държавата. Когато правило на WAF я е блокирало, тялото обикновено е обща забранена страница, а идентификаторът на заявката към разпределението в заглавките е това, което носите в дневниците на WAF. Грешка тук ви изпраща към списъка с разрешени държави за проблем с правило, базирано на честота, което е ден работа, който не може да успее.
Стъпка 1: потвърдете кой адрес вижда разпределението
Попитайте мрежата какво вижда външният свят, от същата машина и по същия маршрут, който използва неуспешният браузър. curl -s https://checkip.amazonaws.com връща публичния адрес на извикващия, който за VPN клиент е изходът, а не домашната връзка на абоната:
curl -s https://checkip.amazonaws.com
nslookup d111111abcdef8.cloudfront.net
Ако този адрес принадлежи на изхода на вашия доставчик в друга държава, географското решение вече е взето и нищо на клиента няма да го промени. Запишете адреса в тикета, преди да пипате настройка, защото това е единственият факт в доклада, по който вие и услугата сте съгласни.
Стъпка 2: отделете държавата от репутацията
CloudFront определя местоположението на зрителя от база данни GeoIP на трета страна, ключована по адреса на източника на заявката, и съответствието е приблизително и регионално, а не точно определение. Когато местоположението не може да бъде определено, документираното поведение по подразбиране е да се предостави съдържанието. Така има три възможни състояния: изходът се съпоставя на блокирана държава, на разрешена държава, или базата няма мнение и заявката продължава.
Потребител в блокирана държава може да изглежда като в разрешена, ако доставчикът има изход там, а потребител в разрешена държава може да бъде блокиран, защото изходът е регистриран другаде. Нито един от резултатите не доказва, че ограничението е счупено. И двата са ограничението, работещо върху адреса, който му е даден, както описва документацията на CloudFront за географски ограничения.
Репутацията е втората ос и тя оцелява след тунела. Управляваната група правила на AWS WAF за анонимни IP е създадена да блокира заявки от VPN, проксита, възли на Tor и хостинг доставчици, така че заявка, преминала проверката за държава, все още може да бъде отказана заради това какъв е адресът, а не къде е. Ако блокирането е започнало, когато преместихте тунела на облачен хост, това е вероятният слой.
Стъпка 3: проверете поведението на квотата
Споделените изходи се провалят по трети начин. Ограниченията на честотата за IP и броят на сесиите третират един адрес като един клиент, а потребителският изход носи много абонати наведнъж, така че модел на заявки, незабележим от домашна връзка, изглежда като автоматизация от изхода. Симптомът е ограничаване или временно блокиране, което се изчиства само, а не географско съобщение за грешка.
Разпределението може също умишлено да брои сесии на адрес, например с функция Lambda@Edge, която пише в DynamoDB. Това не идентифицира човека зад изхода, но кара един адрес да се държи като един клиент, което често е действителното намерение. Запишете различните адреси зад оплакване, преди да настройвате праг, защото корпоративен NAT пред двеста бюра изглежда отвън точно като натоварен изход. Очаквайте фалшиви положителни резултати от корпоративен NAT, университетска мрежа или голямо домакинство, които всички представят един адрес.
Погледнете извадковите заявки на WAF и показателите на правилата, базирани на честота, преди да обвинявате географията. Правило, което се задейства при обема заявки на изхода, оставя ясен подпис и също ви казва дали поправката е корекция на лимит или различен изходен път.
Какво да промените и в какъв ред
Първо решете за какво е проверката. Поддържането на регионален каталог, ограничаването на злоупотреби и налагането на договор са три различни цели и само първата се адресира със списък на държави. Ако целта е контрол на злоупотребите, изходът е грешната единица за идентичност и никакво количество списъци с разрешения няма да направи споделен адрес надежден.
Ако за списък с разрешения наистина е нужен стабилен адрес, отделен или статичен изход помага, защото адресът може да бъде регистриран и не се сменя. Това не прави адреса жилищен и не променя държавата, която базата GeoIP му присвоява. Смяната на изходи, докато един проработи, е временна промяна на репутацията, а не поправка на политиката.
След това запишете резултата с термините, които заявителят е използвал: този адрес е блокиран по държава, по репутация или по честота, и това е проверката, която ще се промени. Всичко по-неясно кани същия тикет следващата седмица с различен изход.