S3 праз шлюз ці праз інтэрфейсны канцавы пункт: доступ з лакальнай сеткі

Два тыпы канцавых пунктаў S3 выглядаюць узаемазаменнымі на агляданні праекта і паводзяць сябе цалкам па-рознаму, як толькі кліент аказваецца па-за пляцоўкай. Канцавы пункт шлюза — гэта інтэграцыя з табліцай маршрутаў унутры VPC, таму запыт з VPN пляцоўкі ніколі не даходзіць да яго як да прыватнага пункта прызначэння. Інтэрфейсны канцавы пункт змяшчае прыватныя адрасы на сеткавыя інтэрфейсы, і гібрыдны шлях сапраўды можа да іх дабрацца. Усё далейшае залежыць ад таго, які з двух вы абралі.

Вызначайце па сеткавым уваходзе, а не па назве сэрвісу

Пачынайце з таго, дзе ўзнікае трафік, бо менавіта на гэтае пытанне адказвае тып канцавога пункта. Працоўная нагрузка ў падтрымліваным кантэксце VPC можа выкарыстоўваць канцавы пункт шлюза і ніколі не патрабуе ўласнага прыватнага адраса. Працоўная нагрузка на пляцоўцы патрабуе прыватнага адраса, да якога можна маршрутызаваць, і менавіта гэта дае інтэрфейсны канцавы пункт. Калі праект змешвае абодва, абодва тыпы канцавых пунктаў могуць суіснаваць у адным VPC, і гэта нармальная схема, а не дубляванне.

Змешваць іх — не праблема. Праблема — лічыць, што адзін тып пакрывае другі.

Класіфікуйце кліента перад тым, як нешта выбіраць. Працоўная прастора ўнутры VPC, кантэйнер за шлюзам NAT і праграма ў філіяле — гэта тры розныя крыніцы, і толькі апошняя вымушае гібрыдны ўваход. Запішыце гэтую класіфікацыю побач з інвентаром канцавых пунктаў, каб наступны рэцэнзент бачыў, навошта існуе кожны канцавы пункт.

Што патрабуе інтэрфейсны шлях ад пачатку да канца

Інтэрфейсны канцавы пункт дае дасяжнасць прыватных адрасоў, і дасяжнасць — гэта толькі адно з чатырох патрабаванняў. Лакальнай сетцы патрэбны маршрут да гэтых адрасоў, боку VPC патрэбны зваротны шлях, група бяспекі канцавога пункта павінна дапускаць дыяпазон крыніцы, а любы сродак праверкі паміж імі павінен дазваляць паток. Маршрут да любой інстанцыі ў VPC не даказвае ніводнага з чатырох.

Працуйце ад далёкага канца назад. Пацвердзіце, што сеткавыя інтэрфейсы канцавога пункта існуюць у чаканых падсетках, затым праверце, што яго група бяспекі дапускае рэальны лакальны дыяпазон, а не запаўняльнік. Пасля гэтага праверце, што тунель або канал нясе зваротны шлях у тым жа кірунку. Праверка — гэта крок, які людзі прапускаюць, бо прамежкавы блок, які дазваляе злучэнне, можа ўсё яшчэ адкідаць большы аб'ём адказу, і гэта выглядае як праблема прапускной здольнасці, а не палітыкі.

Тэстуйце самай маленькай дазволенай аперацыяй, а не вялікім спампоўваннем. Збой праяўляецца хутчэй і з меншым трафікам, які трэба тлумачыць.

DNS ідзе за крыніцай запыту, а не за VPC

Канцавы пункт, які існуе, сам нічога не перанакіроўвае. Праграма атрымлівае тое імя, якое вярнуў яе рэзалютар, а рэзалютар адказвае згодна з прадстаўленнем, якое яму дазволена бачыць. Інстанцыя ўнутры VPC і ноўтбук у офісе задаюць два розныя пытанні і могуць абодва атрымаць правільныя, але розныя адказы. Праверыць адно і зрабіць выснову пра другое — гэта шлях ад паспяховага тэсту да праваленага разгортвання.

Чытайце прыватную наладу DNS канцавога пункта як частку праекта, а не як сцяжок, які ўключаюць пасля запуску.

Калі офіснаму рэзалютару трэба бачыць прадстаўленне VPC, гэты шлях трэба пабудаваць наўмысна, звычайна праз уваходны канцавы пункт рэзалютара. Запытвайце з уласнага кантэксту праграмы і запісвайце, які рэзалютар адказаў. Вынік, сабраны на бастыённым хосце ўнутры VPC, апісвае толькі прадстаўленне бастыёна і нічога іншага.

Дазвол асобны ад дасяжнасці

Дасяжны канцавы пункт вяртае памылкі для запытаў, якія суб'ект не мае права рабіць, і гэтая памылка азначае, што сістэма працуе як задумана. Палітыка ідэнтычнасці, палітыка вядра і любая палітыка канцавога пункта ацэньваюцца ў сваіх уласных пластах. Сеткавы доступ ніколі не даваў дазволу.

Прымайце праект па двух выніках: бясшкодны дазволены выклік, які ўдаецца, і чаканая адмова для выключанай ідэнтычнасці або вядра.

aws ec2 describe-vpc-endpoints --filters Name=vpc-id,Values=vpc-0123456789abcdef0
dig +short s3.us-west-2.amazonaws.com @10.0.0.2

Запісвайце імя канцавога пункта, вызначаны пункт прызначэння і кантэкст палітыкі побач з кожным вынікам, бо адно позняе змяненне DNS можа ануляваць усю выснову. Параўнайце бягучы кошт і эксплуатацыйную вагу абодвух тыпаў канцавых пунктаў, перш чым нешта разгортваць. Інтэрфейсны канцавы пункт набывае гібрыдны прыватны ўваход, гэта не ўніверсальнае патрабаванне, і шлях праз шлюз часта застаецца лепшым адказам для працоўных нагрузак унутры VPC. Выбар робіцца для кожнага кліента і застаецца пераглядаемым.