Warum kann ich über eine VPC-Peering-Verbindung nicht mit einer VPC in einem anderen Konto kommunizieren?

Warum kann ich über eine VPC-Peering-Verbindung nicht mit einer VPC in einem anderen Konto kommunizieren?

Ich habe zwei Amazon AWS-Konten, einen kostenpflichtigen, der öffentliche Webserver hostet (genannt "bezahlt" unten) und ein kostenloses Konto (genannt "frei" weiter unten). Jeder hat ein paar EC2-Instanzen, auf denen Amazon Linux in seiner eigenen VPC läuft, jede mit einem einzigen Subnetz ohne Überschneidungen zwischen ihnen. Ich wollte Dateien einfach zwischen Konten übertragen können, einschließlich des Zugriffs auf ein Git-Bare-Repository aufbezahltausfrei. Ich habe mich also über VPC-Peering-Verbindungen informiert und glaube, dass ich die Anleitungen richtig befolgt habe. Ich habe eine Peering-Verbindung zwischen den VPCs erstellt und akzeptiert, dann Sicherheitsgruppen geändert und in jeder VPC Routen eingerichtet, um auf das Subnetz in der anderen VPC zuzugreifen.

Hier ist das Grundsetup für denbezahltKonto:

VPC: bezahlte VPC

Peering-Verbindung und Routen: kostenpflichtige Peering-Verbindung und Routen

Sicherheitsgruppe: bezahlte Sicherheitsgruppe

Und hier sind die gleichen Informationen für diefreiKonto:

VPC: kostenlose VPC

Peering-Verbindung und Routen: kostenlose Peering-Verbindung und Routen

Sicherheitsgruppe: kostenlose Sicherheitsgruppe

Was ich finde, ist, dass aus einer Instanz in derbezahltKonto kann ich eine Instanz im kostenlosen Konto erfolgreich anpingen:

$ ip -f inet addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc pfifo_fast state UP qlen 1000
    inet 10.0.0.12/24 brd 10.0.0.255 scope global eth0
       valid_lft forever preferred_lft forever
$ ping 172.31.30.44
PING 172.31.30.44 (172.31.30.44) 56(84) bytes of data.
64 bytes from 172.31.30.44: icmp_seq=1 ttl=255 time=0.722 ms

Ich kann aber nicht pingen vomfreiKonto an diebezahltKonto:

$ ip -f inet addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc pfifo_fast state UP group default qlen 1000
    inet 172.31.30.44/20 brd 172.31.31.255 scope global dynamic eth0
       valid_lft 3259sec preferred_lft 3259sec
$ ping 10.0.0.12
PING 10.0.0.12 (10.0.0.12) 56(84) bytes of data.
^C
--- 10.0.0.12 ping statistics ---
14 packets transmitted, 0 received, 100% packet loss, time 13308ms

Kann mir jemand erklären, warum diese Konfiguration es mir nicht erlaubt, einen Host imbezahltKonto von einem Host imfreiKonto?

Muss ich weitere Angaben machen (und wenn ja, welche)?

Antwort1

In Kommentaren zudiese Antwortauf eine unabhängige Frage zu Netzwerk-ACLs auf derbezahltIch habe erwähnt, dass ich die Verwendung von AWS-Netzwerk-ACLs durch den Linux-Befehl iptables ersetzt habe. Als ich es vor zehn Jahren einrichtete, hatte ich nicht erwartet, jemals mit privaten Adressen außerhalb meines eigenen Subnetzes kommunizieren zu wollen. Also habe ich eingehende Verbindungen von 172.16.0.0/12 abgebrochen. Deshalb konnte ich erreichenfreiausbezahlt, aber nicht umgekehrt. Das Entfernen dieses iptables-Blocks behebt das Problem.

Wie peinlich!

verwandte Informationen