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