Wie überprüfe ich, ob ein AWS VPC (S3) -Endpunkt funktioniert?

Ich habe meiner VPC mithilfe von CloudFormation einen VPC-Endpunkt hinzugefügt und die Verwendung von s3 zugelassen. Die Routen werden in der AWS-Konsole angezeigt, jedoch nicht in den lokalen Routing-Tabellen der EC2-Instanzen:

$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         172.29.4.129    0.0.0.0         UG    0      0        0 eth0
169.254.169.254 0.0.0.0         255.255.255.255 UH    0      0        0 eth0
172.29.4.128    0.0.0.0         255.255.255.128 U     0      0        0 eth0

Wie überprüfe ich, ob die EC2-Instanzen in der VPC tatsächlich den VPC-Endpunkt für S3 verwenden und nicht die verfügbare Internetverbindung?

Sie können die S3-Protokollierung aktivieren und prüfen, ob auf die Dateien nicht über öffentliche, sondern über Ihre private IP zugegriffen wird. Wenn Ihre Protokollierung anzeigt, dass private IP-Adressen auf die Buckets zugreifen, haben Sie sie korrekt konfiguriert. Viel Glück!

Ich habe eine Methode gefunden, um die Verwendung des VPC-Endpunkts zu überprüfen.

1. Melden Sie sich bei einer AWS EC2-Instanz in der VPC an
2. Konfigurieren Sie den aws cli-Client
3. laufen aws ec2 describe-prefix-lists; für Windows PowerShell ,Get-EC2PrefixList

Das Ergebnis sollte die Präfixlisten-ID der VPC-Endpunkte im Attribut enthalten PrefixListId.

Zur zusätzlichen Überprüfung können Sie die folgende Richtlinie auf einen S3-Bucket anwenden:

{
  "Version": "2008-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Principal": "*",
      "Action": [
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::mybucket"
      ],
      "Condition": {
        "StringNotEquals": {
          "aws:sourceVpc": [
            "vpc-121212"
          ]
        }
      }
    }
  ]
}

mit Ihrer vpc ID anstelle von vpc-121212. Sie sollten dann nur von der angegebenen VPC aus auf den S3-Bucket zugreifen können

Ich würde empfehlen, die ec2-Instanz (mit der IAM-Rolle zum Auflisten von s3-Buckets) im Subnetz ohne Internetzugang zu starten.

Grundsätzlich nur 2 aktive Regeln in der Routentabelle (Ihr VPC-Subnetzbereich und s3-Endpunkt).

Stellen Sie eine Verbindung zur Instanz her und führen Sie den folgenden Befehl aus:

aws s3 ls /**

Es sollte mit Timeout fehlschlagen, da Boto standardmäßig eine Anforderung an die globale s3-URL (s3.amazonaws.com) erstellt.

export AWS_DEFAULT_REGION=us-east-1** ## your region here
aws s3 ls /**

sollte Ihre Buckets in der Region us-east-1 auflisten (vpc router leitet Ihre Anfrage an s3.us-east-1.amazonaws.com weiter).

Ich denke, der direkte Weg besteht darin, diese Routen tatsächlich zu untersuchen.

Sie können auf s3 zurückverfolgen und prüfen, ob sich die interne IP des NAT-Gateways an einer beliebigen Stelle in der Ausgabe befindet (z. B. im ersten Hop).

Überprüfen Sie zunächst die internen IP-Adressen des NAT-Gateways in der Konsole .

Beispielausgabe mit gesetztem Endpunkt - keine Gateway-IP angezeigt. Das möchten Sie sehen.

$ traceroute -n -T -p 443 s3.amazonaws.com                                
traceroute to s3.amazonaws.com (52.216.204.93), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  52.216.204.93  0.662 ms  0.668 ms  0.637 ms

Beispielausgabe eines anderen Ziels über NAT (siehe erster Hop)

$ traceroute -n -T -p 443 serverfault.com
traceroute to serverfault.com (151.101.129.69), 30 hops max, 60 byte packets
 1  172.20.10.188  0.206 ms  0.147 ms  0.145 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  100.65.13.49  0.956 ms 100.65.13.113  1.253 ms *
 8  52.93.28.209  1.083 ms 52.93.28.231  1.213 ms 52.93.28.235  1.151 ms
 9  100.100.4.38  1.770 ms 100.100.4.46  2.089 ms 100.100.4.36  1.723 ms
10  103.244.50.242  1.136 ms 100.100.4.44  1.702 ms  2.738 ms
11  151.101.129.69  1.013 ms 103.244.50.244  1.745 ms 151.101.129.69  1.142 ms

Ihre Instanz leitet Pakete, die für S3 bestimmt sind, an das lokale Gateway weiter, und von dort leitet der VPC-Router sie an den S3-Endpunkt weiter. Es sind keine Client-Konfigurationen oder Kenntnisse erforderlich.

Sie können den S3-Endpunkt mit einem sehr restriktiven Satz von ACLs so konfigurieren, dass alle Anforderungen abgelehnt werden und Ihr Client den Fehler ebenfalls empfängt.

@ m-glatkis Antwort (die aus irgendeinem Grund die akzeptierte ist) ist sachlich falsch.

Zunächst müssen Sie explizit eine ec2-VPC-Schnittstelle aktivieren, um den aws ec2 describe-prefix-listsAnruf überhaupt ausführen zu können , da sonst eine Zeitüberschreitung auftritt .

Zweitens, selbst wenn Sie diese API aufrufen können, wird Ihnen nicht mitgeteilt, ob Sie Ihren Datenverkehr über diesen Endpunkt leiten. Es enthält lediglich Details zu einer bestimmten Präfixliste (PL) in der aktuellen Region.

Sie müssen der Routentabelle des Subnetzes einen S3-VPC-Endpunkt zuordnen und sicherstellen, dass die Sicherheitsgruppe Ihrer EC2-Instanz oder des Dienstes die Ausgangsverbindung über diesen Endpunkt zulässt (Sie sollten mit der Standardausgangsregel "Alle zulassen" einverstanden sein). Dadurch wird der S3-Verkehr über den Endpunkt weitergeleitet, auch wenn ein NAT-Gateway daran angeschlossen ist.

Sie können überprüfen, ob Ihr Datenverkehr nicht über das NAT geleitet wird, indem Sie die zugehörigen Cloudwatch-Protokolle überprüfen (siehe Metriken BytesOutToDestination , BytesOutToSource , BytesInFromDestination und BytesInFromSource ).

Überprüfen Sie auch die S3-Bucket-Protokolle, wie @michael richtig hervorgehoben hat.