Brama S3 czy punkt końcowy interfejsu dla klienta lokalnego?

Dotarcie do S3 z sieci biurowej przez VPN site-to-site nie jest problemem routingu, który statyczna trasa rozwiąże sama. Punkt końcowy bramy jest podłączony do tabel tras i obsługuje żądania powstające wewnątrz VPC. Punkt końcowy interfejsu umieszcza elastyczne interfejsy sieciowe z prywatnymi adresami w twoich podsieciach, a te adresy są osiągalne z siedziby przez VPN lub Direct Connect. To, gdzie zaczyna się żądanie, decyduje, którego z dwóch naprawdę potrzebujesz, a praca nad DNS, grupą zabezpieczeń i polityką wynika z tej odpowiedzi.

Rozdziel typy punktów końcowych według tego, gdzie zaczyna się żądanie

Punkt końcowy bramy pojawia się jako wpis w tabeli tras wskazujący na zarządzaną listę prefiksów. Nie ma interfejsu sieciowego, grupy zabezpieczeń ani własnego prywatnego adresu, i właśnie dlatego host w siedzibie nie może do niego routować: po drugiej stronie nie ma niczego, do czego można routować. Ruch z wnętrza VPC dociera do S3, ponieważ tabela tras podsieci wysyła ten prefiks do punktu końcowego. Ruch z każdego innego miejsca nie ma takiego wpisu, którego mógłby się trzymać.

Punkt końcowy interfejsu to zbiór interfejsów sieciowych w wybranych podsieciach, każdy z prywatnym adresem z tej podsieci i dołączoną grupą zabezpieczeń. To kształt, którego może użyć klient hybrydowy, bo jest to zwykłe miejsce docelowe, do którego twój tunel może przenosić pakiety. Oznacza to także, że punkt końcowy zużywa adresy w podsieci i może je wyczerpać.

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

Czytaj kolumnę Type, a nie nazwę. Jedna VPC zwykle zawiera oba typy dla tej samej usługi, a wpis, którego potrzebuje twoja aplikacja lokalna, to wpis interfejsu.

Zbuduj ścieżkę do adresu interfejsu, zanim przetestujesz S3

Trzy rzeczy muszą być prawdziwe jednocześnie: router w siedzibie ma trasę do podsieci punktu końcowego, ścieżka powrotna z tej podsieci dociera do sieci klienta, a grupa zabezpieczeń punktu końcowego dopuszcza zakres źródłowy klienta. ACL sieci podsieci nadal może odrzucić pakiet po spełnieniu wszystkich trzech, więc sprawdź go jako czwarty punkt, a nie jako późniejszą myśl.

Działająca trasa do jakiejś instancji EC2 w VPC niczego z tego nie dowodzi. Pokazuje tylko, że tunel jest podniesiony, co jest jedyną częścią ścieżki, którą już znasz. Udowodnij adres punktu końcowego osobno, a potem udowodnij, że nazwa rozwiązuje się na niego.

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

Pierwsze polecenie pokazuje, którego interfejsu użyłby klient. Drugie dowodzi uścisku dłoni TCP. Trzecie dowodzi, że TLS kończy się certyfikatem ważnym dla nazwy punktu końcowego, i to jest sprawdzenie, które łapie zły adres, zanim obwinisz uprawnienia.

Zdecyduj, którą odpowiedź DNS otrzymuje aplikacja

Istnienie punktu końcowego interfejsu w VPC nie przekierowuje lokalnego SDK samo z siebie. Klient używa albo nazwy właściwej dla punktu końcowego, którą AWS publikuje dla tego punktu, albo prywatnej strefy hostowanej, którą celowo uczyniłeś rozwiązywalną z biura.

Dla rozwiązywania hybrydowego lokalny resolver potrzebuje obsługiwanej ścieżki do widoku DNS VPC, zwykle przez przychodzący punkt końcowy Resolvera. Włączanie prywatnego DNS bez zrozumienia, na które źródła zapytań wpływa, jest sposobem, w jaki wyszukiwanie zaczyna zwracać adres, do którego biuro nie dotrze. Ustawienie zmienia odpowiedzi dla zapytań przychodzących przez resolver VPC, a nie dla każdego klienta wszędzie.

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

Uruchom oba na hoście aplikacji, a nie na maszynie skoku w VPC. Resolver, który tam odpowiada, to ten, którego używa twoje obciążenie, a inna odpowiedź z innego hosta jest najczęstszym źródłem zamieszania w tym projekcie.

Osiągalność nie jest autoryzacją

Żądanie, które dociera do punktu końcowego, nadal potrzebuje upoważnionego podmiotu i obowiązującego uprawnienia do zasobnika. Polityka punktu końcowego może zawęzić to, co punkt dopuszcza, a polityka zasobnika może zawęzić to jeszcze bardziej. Dotarcie do interfejsu nic nie mówi o tym, które obiekty wywołujący może czytać.

Przetestuj oba kierunki: jedno nieszkodliwe upoważnione wywołanie do zamierzonego zasobnika i jedno wywołanie, które ma zostać odrzucone dla tożsamości lub zasobu spoza polityki. Zachowaj nazwę punktu końcowego, rozwiązany adres i kontekst polityki razem z wynikiem, aby następna osoba mogła to odtworzyć. Odmowa, która nazywa typ polityki, oszczędza godzinę zgadywania.

Na koniec oszacuj koszt obu opcji przed przygotowaniem. Punkt końcowy interfejsu jest rozliczany za godzinę interfejsu i za gigabajt, podczas gdy punkt końcowy bramy nie, i ta różnica rozstrzyga pytanie dla wielu obciążeń o małym wolumenie, które potrzebują tylko dostępu od strony VPC.