Шлюз 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.