Chegar a S3 desde unha rede de oficina por unha VPN de sitio non é un problema de encamiñamento que unha ruta estática poida resolver por si soa. Un punto final de pasarela está ligado ás táboas de rutas e atende as peticións que se orixinan dentro da VPC. Un punto final de interface coloca interfaces de rede elásticas con enderezos privados nas túas subredes, e eses enderezos son accesibles desde as instalacións a través de VPN ou Direct Connect. Onde comeza a petición decide cal dos dous necesitas realmente, e o traballo de DNS, grupo de seguridade e política derívase desa resposta.

Separa os tipos de punto final por onde comeza a petición

Un punto final de pasarela aparece como unha entrada na táboa de rutas que apunta a unha lista de prefixos xestionada. Non ten interface de rede, nin grupo de seguridade, nin enderezo privado propio, e é exactamente por iso que un host local non pode encamiñar cara a el: ao outro lado non hai nada cara a onde encamiñar. O tráfico desde dentro da VPC chega a S3 porque a táboa de rutas da subrede envía ese prefixo ao punto final. O tráfico desde calquera outro lugar non ten esa entrada que seguir.

Un punto final de interface é un conxunto de interfaces de rede nas subredes que elixas, cada unha cun enderezo privado desa subrede e un grupo de seguridade ligado. Esa é a forma que pode usar un cliente híbrido, porque é un destino ordinario ao que o teu túnel pode levar paquetes. Tamén significa que o punto final consume enderezos na subrede e pode quedarse sen eles.

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

Le a columna Type en lugar do nome. Unha soa VPC adoita conter ambos os tipos para o mesmo servizo, e a entrada que necesita a túa aplicación local é a de interface.

Constrúe a ruta ata o enderezo de interface antes de probar S3

Tres cousas teñen que ser certas á vez: o encamiñador local ten unha ruta cara á subrede do punto final, a ruta de volta desde esa subrede chega á rede do cliente, e o grupo de seguridade do punto final admite o rango de orixe do cliente. A ACL de rede da subrede aínda pode descartar o paquete despois de que as tres se cumpran, así que revísaa como cuarto elemento e non como idea tardía.

Unha ruta que funciona cara a algunha instancia EC2 dentro da VPC non demostra nada disto. Só mostra que o túnel está levantado, que é a única parte do camiño que xa sabías. Demostra o enderezo do punto final por separado e despois demostra que o nome se resolve nel.

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

O primeiro comando mostra que interface usaría o cliente. O segundo demostra un aperto de mans TCP. O terceiro demostra que TLS se completa cun certificado válido para o nome do punto final, e esa é a comprobación que atrapa un enderezo incorrecto antes de culpar os permisos.

Decide que resposta DNS recibe a aplicación

Que exista un punto final de interface na VPC non redirixe un SDK local por si só. O cliente usa ou ben o nome específico do punto final que AWS publica para ese punto, ou ben unha zona aloxada privada que fixeches resoluble desde a oficina a propósito.

Para a resolución híbrida, o resolutor local necesita unha ruta admitida cara á vista DNS da VPC, normalmente a través dun punto final de entrada de Resolver. Activar o DNS privado sen entender que fontes de consulta afecta é como unha busca comeza a devolver un enderezo que a oficina non pode alcanzar. O axuste cambia as respostas das consultas que chegan polo resolutor da VPC, non as de todos os clientes en todas partes.

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

Executa ambos os comandos no host da aplicación, non nunha máquina de salto dentro da VPC. O resolutor que responde alí é o que usa a túa carga de traballo, e unha resposta distinta desde outro host é a fonte de confusión máis habitual neste deseño.

A accesibilidade non é autorización

Unha petición que chega ao punto final aínda necesita un principal autorizado e un permiso de bucket aplicable. Unha política de punto final pode restrinxir o que o punto permite, e unha política de bucket pode restrinxilo aínda máis. Chegar á interface non di nada sobre que obxectos pode ler o chamador.

Proba ambas as direccións: unha chamada autorizada e inofensiva contra o bucket previsto, e unha chamada que se espera denegada para unha identidade ou un recurso fóra da política. Garda o nome do punto final, o enderezo resolto e o contexto de política xunto co resultado para que a seguinte persoa poida reproducilo. Unha denegación que nomea o tipo de política aforra unha hora de conxecturas.

Por último, valora o prezo das dúas opcións antes de aprovisionar. Un punto final de interface factura por hora de interface e por gigabyte, mentres que un de pasarela non, e esa diferenza decide a cuestión para moitas cargas de pouco volume que só necesitan acceso desde o lado da VPC.

Artigos relacionados