S3-átjáró vagy interfész-végpont egy helyszíni ügyfél számára?

Az S3 elérése irodai hálózatból site VPN-en keresztül nem olyan útválasztási probléma, amelyet egy statikus útvonal önmagában megoldana. Az átjáró-végpont útvonaltáblákhoz kapcsolódik, és a VPC-n belül keletkező kéréseket szolgálja ki. Az interfész-végpont privát címekkel rendelkező rugalmas hálózati interfészeket helyez el az alhálózatokban, és ezek a címek a helyszínről VPN vagy Direct Connect használatával elérhetők. Hogy hol kezdődik a kérés, eldönti, melyikre van valóban szüksége, és a DNS-, biztonságicsoport- és szabályzatmunka ebből a válaszból következik.

Válassza szét a végponttípusokat aszerint, hogy hol kezdődik a kérés

Az átjáró-végpont útvonaltábla-bejegyzésként jelenik meg, amely egy felügyelt előtaglistára mutat. Nincs hálózati interfésze, biztonsági csoportja és saját privát címe, és éppen ezért a helyszíni gazdagép nem tud rá útvonalat építeni: a túloldalon nincs semmi, amire útvonal épülhetne. A VPC-n belüli forgalom azért éri el az S3-at, mert az alhálózat útvonaltáblája azt az előtagot a végpontra küldi. Bármely más helyről érkező forgalomnak nincs ilyen bejegyzés, amelyet követhetne.

Az interfész-végpont az Ön által választott alhálózatokban lévő hálózati interfészek halmaza, mindegyik egy abból az alhálózatból származó privát címmel és egy kapcsolt biztonsági csoporttal. Ez az a forma, amelyet hibrid ügyfél használhat, mert ez egy közönséges célpont, ahová az alagút csomagokat szállíthat. Ez azt is jelenti, hogy a végpont címeket fogyaszt az alhálózatban, és azok elfogytak.

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

A nevet ne, a Type oszlopot olvassa. Egy VPC általában mindkét típust tartalmazza ugyanahhoz a szolgáltatáshoz, és az a bejegyzés, amelyre a helyszíni alkalmazásnak szüksége van, az interfész-bejegyzés.

Építse fel az interfész címéhez vezető útvonalat az S3 tesztelése előtt

Három dolognak kell egyszerre igaznak lennie: a helyszíni útválasztónak van útvonala a végpont alhálózatához, az abból az alhálózatból induló visszaút eléri az ügyfélhálózatot, és a végpont biztonsági csoportja engedi az ügyfél forrástartományát. Az alhálózat hálózati ACL-je még mindig eldobhatja a csomagot, miután mindhárom teljesül, ezért negyedik elemként ellenőrizze, és ne utólagos gondolatként.

Egy működő útvonal valamelyik VPC-n belüli EC2-példányhoz ebből semmit nem bizonyít. Csak azt mutatja, hogy az alagút áll, ami az útvonal egyetlen olyan része, amelyet már ismert. Külön bizonyítsa a végpont címét, majd bizonyítsa, hogy a név arra oldódik fel.

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

Az első parancs megmutatja, melyik interfészt használná az ügyfél. A második TCP-kézfogást bizonyít. A harmadik azt bizonyítja, hogy a TLS a végpont nevére érvényes tanúsítvánnyal fejeződik be, és ez az az ellenőrzés, amely a jogosultságok hibáztatása előtt elkapja a rossz címet.

Döntse el, melyik DNS-választ kapja meg az alkalmazás

Egy interfész-végpont megléte a VPC-ben önmagában nem irányít át egy helyszíni SDK-t. Az ügyfél vagy a végpontra jellemző nevet használja, amelyet az AWS közzétesz ahhoz a végponthoz, vagy olyan privát hosztolt zónát, amelyet szándékosan tett az irodából feloldhatóvá.

A hibrid feloldáshoz a helyszíni feloldónak támogatott útra van szüksége a VPC DNS-nézetébe, általában egy bejövő Resolver-végponton keresztül. A privát DNS bekapcsolása anélkül, hogy értené, mely lekérdezési forrásokra hat, az az út, amelyen egy keresés olyan címet kezd visszaadni, amelyet az iroda nem ér el. A beállítás az VPC-feloldón keresztül érkező lekérdezések válaszait változtatja meg, nem minden ügyfélét mindenhol.

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

Mindkettőt az alkalmazás gazdagépén futtassa, ne egy ugródobozon a VPC-ben. Az ott válaszoló feloldó az, amelyet a munkaterhelése használ, és egy másik gazdagépről kapott eltérő válasz a leggyakoribb zavarforrás ebben a tervezésben.

Az elérhetőség nem jogosultság

A végpontra érkező kérésnek továbbra is szüksége van jogosult főre és alkalmazható gyűjtőengedélyre. A végpontszabályzat szűkítheti, mit enged meg a végpont, a gyűjtőszabályzat pedig tovább szűkítheti. Az interfész elérése semmit nem mond arról, mely objektumokat olvashat a hívó.

Tesztelje mindkét irányt: egy ártalmatlan, jogosult hívást a szándékolt gyűjtő felé, és egy olyan hívást, amelynél a szabályzaton kívüli identitás vagy erőforrás miatt elutasítás várható. Tartsa meg a végpont nevét, a feloldott címet és a szabályzat kontextusát az eredménnyel együtt, hogy a következő ember reprodukálhassa. A szabályzat típusát megnevező elutasítás egy óra találgatást takarít meg.

Végül árazza be a két lehetőséget a kiépítés előtt. Az interfész-végpont interfészóránként és gigabájtonként számlázódik, az átjáró-végpont nem, és ez a különbség dönti el a kérdést sok kis volumenű munkaterhelésnél, amelyeknek csak a VPC oldali hozzáférésre van szükségük.