S3-poortwag of koppelvlak-eindpunt vir ’n kliënt op die perseel?

Om S3 vanaf ’n kantoor netwerk oor ’n site-VPN te bereik, is nie ’n roeteringsprobleem wat ’n statiese roete op sy eie kan oplos nie. ’n Poortwag-eindpunt word aan roetetabelle geheg en bedien versoeke wat binne die VPC ontstaan. ’n Koppelvlak-eindpunt plaas elastiese netwerkkoppelvlakke met private adresse in jou subnetwerke, en daardie adresse is van die perseel af bereikbaar oor VPN of Direct Connect. Waar die versoek begin, bepaal watter van die twee jy werklik nodig het, en die DNS-, sekuriteitsgroep- en beleidswerk volg uit daardie antwoord.

Skei die eindpuntsoorte volgens waar die versoek begin

’n Poortwag-eindpunt verskyn as ’n roetetabel-inskrywing wat na ’n bestuurde voorvoegsellys wys. Dit het geen netwerkkoppelvlak, geen sekuriteitsgroep en geen private adres van sy eie nie, en dit is juis waarom ’n gasheer op die perseel nie daarheen kan roeteer nie: daar is niks aan die ander kant om na te roeteer nie. Verkeer van binne die VPC bereik S3 omdat die subnet se roetetabel daardie voorvoegsel na die eindpunt stuur. Verkeer van elders het geen sulke inskrywing om te volg nie.

’n Koppelvlak-eindpunt is ’n stel netwerkkoppelvlakke in subnetwerke wat jy kies, elk met ’n private adres uit daardie subnet en ’n sekuriteitsgroep daaraan geheg. Dit is die vorm wat ’n hibriede kliënt kan gebruik, want dit is ’n gewone bestemming waarheen jou tonnel pakkette kan dra. Dit beteken ook dat die eindpunt adresse in die subnet verbruik en daaraan uitgeput kan raak.

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

Lees die Type-kolom eerder as die naam. ’n Enkele VPC hou gewoonlik albei soorte vir dieselfde diens, en die een wat jou toepassing op die perseel nodig het, is die koppelvlak-inskrywing.

Bou die pad na die koppelvlakadres voordat jy S3 toets

Drie dinge moet gelyktydig waar wees: die roeteerder op die perseel het ’n roete na die eindpunt se subnet, die terugpad van daardie subnet bereik die kliëntnetwerk, en die eindpunt se sekuriteitsgroep laat die kliënt se bronbestek toe. Die subnet se netwerk-ACL kan die pakket steeds laat val nadat al drie geslaag het, so toets dit as ’n vierde item eerder as ’n nagedagte.

’n Werkende roete na een of ander EC2-instansie in die VPC bewys niks hiervan nie. Dit wys dat die tonnel op is, wat die een deel van die pad is wat jy reeds geweet het. Bewys die eindpuntadres afsonderlik, en bewys dan dat die naam daarheen oplos.

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

Die eerste opdrag wys watter koppelvlak die kliënt sou gebruik. Die tweede bewys ’n TCP-handdruk. Die derde bewys dat TLS voltooi met ’n sertifikaat wat vir die eindpuntnaam geldig is, en dit is die toets wat ’n verkeerde adres vang voordat jy toestemmings blameer.

Bepaal watter DNS-antwoord die toepassing ontvang

’n Koppelvlak-eindpunt wat in die VPC bestaan, herlei nie vanself ’n SDK op die perseel nie. Die kliënt gebruik óf die eindpuntspecifieke naam wat AWS vir daardie eindpunt publiseer, óf ’n private gehoste sone wat jy doelbewus vanaf die kantoor oplosbaar gemaak het.

Vir hibriede resolusie het die oplosser op die perseel ’n ondersteunde pad na die VPC se DNS-aansig nodig, gewoonlik deur ’n Resolver-inbound-eindpunt. Om private DNS te aktiveer sonder om te verstaan watter navraagbronne dit raak, is hoe ’n opsoek begin om ’n adres terug te gee wat die kantoor nie kan bereik nie. Die instelling verander antwoorde vir navrae wat deur die VPC-oplosser kom, nie vir elke kliënt oral nie.

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

Voer albei uit op die toepassing se gasheer, nie op ’n sprongkas in die VPC nie. Die oplosser wat daar antwoord, is die een wat jou werklading gebruik, en ’n ander antwoord van ’n ander gasheer is die algemeenste bron van verwarring in hierdie ontwerp.

Bereikbaarheid is nie magtiging nie

’n Versoek wat by die eindpunt aankom, het steeds ’n gemagtigde prinsipaal en ’n toepaslike emmer-toestemming nodig. ’n Eindpuntbeleid kan vernou wat die eindpunt toelaat, en ’n emmerbeleid kan dit weer vernou. Om die koppelvlak te bereik sê niks oor watter objekte die oproeper mag lees nie.

Toets albei rigtings: een skadelose gemagtigde oproep teen die beoogde emmer, en een oproep wat na verwagting geweier word vir ’n identiteit of hulpbron buite die beleid. Hou die eindpuntnaam, die opgeloste adres en die beleidskonteks by die resultaat sodat die volgende persoon dit kan reproduseer. ’n Weiering wat die beleidstipe noem, spaar ’n uur se raaiwerk.

Prys laastens die twee opsies voordat jy dit inrig. ’n Koppelvlak-eindpunt faktureer per koppelvlak-uur en per gigabyte, terwyl ’n poortwag-eindpunt dit nie doen nie, en daardie verskil beslis die vraag vir baie lae-volume werkladings wat net toegang aan die VPC-kant nodig het.