S3 шлюз или интерфейсна крайна точка за клиент в локалната мрежа?

Достигането на S3 от офис мрежа през site VPN не е проблем за маршрутизацията, който статичен маршрут може да реши сам. Шлюзовата крайна точка се прикача към таблиците за маршрутизация и обслужва заявки, които произхождат вътре в VPC. Интерфейсната крайна точка поставя еластични мрежови интерфейси с частни адреси в подмрежите ви и тези адреси са достъпни от локалната мрежа през VPN или Direct Connect. Откъде започва заявката решава коя от двете всъщност ви е нужна, а работата по DNS, групата за сигурност и политиката следва от този отговор.

Разделете типовете крайни точки по това откъде започва заявката

Шлюзовата крайна точка се появява като запис в таблицата за маршрутизация, сочещ към управляван списък с префикси. Тя няма мрежов интерфейс, група за сигурност и собствен частен адрес, поради което хост в локалната мрежа не може да маршрутизира към нея: от другата страна няма нищо, към което да се маршрутизира. Трафикът отвътре в VPC достига S3, защото таблицата за маршрутизация на подмрежата изпраща този префикс към крайната точка. Трафикът от всякъде другаде няма такъв запис, който да следва.

Интерфейсната крайна точка е набор от мрежови интерфейси в подмрежи по ваш избор, всеки с частен адрес от тази подмрежа и прикачена група за сигурност. Това е формата, която хибриден клиент може да използва, защото е обикновена дестинация, до която тунелът ви може да носи пакети. Това също означава, че крайната точка изразходва адреси в подмрежата и може да ги изчерпи.

aws ec2 describe-vpc-endpoints --query "VpcEndpoints[].{Id:VpcEndpointId,Type:VpcEndpointType,Service:ServiceName,State:State}" --output table

Четете колоната Type, а не името. Една VPC обикновено съдържа и двата вида за една и съща услуга, а записът, който приложението ви в локалната мрежа трябва, е интерфейсният.

Изградете пътя до адреса на интерфейса, преди да тествате S3

Три неща трябва да са верни едновременно: рутерът в локалната мрежа има маршрут до подмрежата на крайната точка, обратният път от тази подмрежа достига до клиентската мрежа и групата за сигурност на крайната точка допуска диапазона на източника на клиента. Мрежовият ACL на подмрежата все още може да изхвърли пакета след като и трите са изпълнени, затова го проверете като четвърти елемент, а не като закъсняла мисъл.

Работещ маршрут до някакъв EC2 инстанс в VPC не доказва нищо от това. Той показва, че тунелът е вдигнат, което е единствената част от пътя, която вече знаете. Докажете адреса на крайната точка отделно, после докажете, че името се разпознава до него.

ip route get 10.60.4.37
nc -vz 10.60.4.37 443
openssl s_client -connect 10.60.4.37:443 -servername bucket.vpce-0123456789abcdef0-abc123.s3.us-east-1.vpce.amazonaws.com </dev/null

Първата команда показва кой интерфейс би използвал клиентът. Втората доказва TCP ръкостискане. Третата доказва, че TLS завършва със сертификат, валиден за името на крайната точка, и това е проверката, която хваща грешния адрес, преди да обвините разрешенията.

Решете кой отговор от DNS получава приложението

Съществуването на интерфейсна крайна точка във VPC не пренасочва SDK в локалната мрежа само по себе си. Клиентът или използва специфичното за крайната точка име, което AWS публикува за нея, или частна хоствана зона, която съзнателно сте направили разпознаваема от офиса.

За хибридно разпознаване локалният резолвер се нуждае от поддържан път до DNS изгледа на VPC, обикновено през входяща крайна точка на Resolver. Включването на частен DNS без разбиране кои източници на заявки засяга е начинът, по който едно търсене започва да връща адрес, който офисът не може да достигне. Настройката променя отговорите за заявки, идващи през резолвера на VPC, не за всеки клиент навсякъде.

dig +short bucket.vpce-0123456789abcdef0-abc123.s3.us-east-1.vpce.amazonaws.com
aws s3api head-bucket --bucket example-artifacts --endpoint-url https://bucket.vpce-0123456789abcdef0-abc123.s3.us-east-1.vpce.amazonaws.com

Изпълнете двете на хоста на приложението, а не на междинен сървър във VPC. Резолверът, който отговаря там, е този, който вашата работа използва, а различен отговор от различен хост е най-честият източник на объркване в този дизайн.

Достъпността не е оторизация

Заявка, която стига до крайната точка, все още се нуждае от оторизиран принципал и приложимо разрешение за бъкет. Политиката на крайната точка може да стесни какво позволява точката, а политиката на бъкета може да го стесни отново. Достигането на интерфейса не казва нищо за това кои обекти може да чете извикващият.

Тествайте и двете посоки: едно безвредно оторизирано извикване към предвидения бъкет и едно извикване, което се очаква да бъде отказано за идентичност или ресурс извън политиката. Пазете името на крайната точка, разпознатия адрес и контекста на политиката заедно с резултата, за да може следващият човек да го възпроизведе. Отказ, който посочва типа политика, спестява час догадки.

Накрая, оценете цената на двете опции преди предоставянето. Интерфейсната крайна точка се таксува за интерфейс-час и за гигабайт, докато шлюзовата не, и тази разлика решава въпроса за много натоварвания с нисък обем, които се нуждаят само от достъп от страната на VPC.