Ich habe zwei EC2-Instanzen in derselben AZ und auf demselben Konto erstellt. Sie verwenden unterschiedliche Sicherheitsgruppen. Ich möchte, dass Instanz A auf einem bestimmten Port nur Verbindungen von Instanz B akzeptiert.
Ich glaube nicht, dass es sich bei diesen Instanzen um VPC handelt, weiß aber nicht, wie ich das bestätigen kann. Ich konnte die Sicherheitsgruppe nicht ändern, was mich glauben lässt, dass es sich nicht um VPC handelt.
In der Sicherheitsgruppe hat beispielsweise AI eine Regel für den Port hinzugefügt und die öffentliche IP /32 von Instanz B als Quelle verwendet. Anschließend habe ich versucht, von Instanz B aus eine Verbindung mit der öffentlichen IP von Instanz A herzustellen, aber der Verbindungsversuch schlägt sofort fehl.
Ich habe die gleichen Schritte mit der privaten IP jeder Instanz versucht. Was übersehe ich?
Hier ist ein Artikel, der eine ähnliche Frage beantwortet, aber VPC ist beteiligt:Verbindung zur EC2-Instanz in VPC (Amazon AWS) kann nicht hergestellt werden.
Beide Instanzen haben dieselbe VPC-ID und Subnetz-ID.
Ich habe auch versucht, die Quelle auf die Sicherheitsgruppe der Instanz B einzustellen, was auch nicht funktioniert hat.
Ich versuche dies mit MySQL. Der auf Instanz B ausgeführte MySQL-Client ist sofort mit diesem Fehler fehlgeschlagen:
FEHLER 2003 (HY000): Verbindung zum MySQL-Server auf '54.xx.xx.xx' nicht möglich (113)
Um zu überprüfen, dass es kein Problem mit der MySQL-Einrichtung gab, habe ich dasselbe mit ICMP Echo Reply versucht, was auch nicht funktionierte.
Bearbeiten Dank der ersten Antworten konnte ich bestätigen, dass diese beiden Instanzen in einer VPC ausgeführt werden (indem ich zur VPC-Konsole gegangen bin). Meine Frage ist also dem verlinkten Artikel sehr ähnlich. In diesem Fall bestand das Problem jedoch darin, dass die Instanzen keine Standardinstanzen waren und daher nicht die richtige Route und das richtige Subnetz erstellt wurden. So ist meine VPC eingerichtet: Die VPC ist standardmäßig und mit einer Routentabelle verknüpft. Die Routentabelle ist implizit mit dem mit der VPC verknüpften Subnetz verknüpft. Die Routentabelle enthält eine einzelne Route und das Ziel ist „lokal“.
Diese werden alle standardmäßig erstellt, da die Dokumente meines Wissens die Verbindung zweier Instanzen zueinander ermöglichen sollen. Was übersehe ich (noch)?
Antwort1
Ich habe das Problem mit Hilfe des AWS-Techniksupports gelöst. Hier sind die Informationen für zukünftige Neulinge wie mich:
Das Problem bestand darin, dass iptables auf Instanz B lief und keinen Datenverkehr zuließ. Ich erfuhr, dass es für EC2-Instanzen zwei Firewall-Ebenen gibt: Sicherheitsgruppen (verwaltet über die AWS-Konsole) und iptables (verwaltet auf dem Host). Es gibt Gründe, iptables zu verwenden, zum Beispiel https://wincent.com/wiki/Using_iptables_on_EC2_instances
In den meisten Fällen müssen Sie sich beim Ausführen von Amazon EC2 keine Gedanken über die Verwendung einer Firewall auf Hostebene wie iptables machen, da Amazon Ihnen erlaubt, Instanzen innerhalb einer „Sicherheitsgruppe“ auszuführen, was im Grunde eine Firewall-Richtlinie ist, mit der Sie angeben, welche Verbindungen von der Außenwelt die Instanz erreichen dürfen. Dies ist jedoch ein „Whitelist“-Ansatz und es ist nicht einfach, ihn für „Blacklist“-Zwecke bei einer laufenden Instanz zu verwenden.
In meinem Fall brauche ich keine Firewall auf Hostebene, also habe ich iptables ausgeschaltet:
sudo service chkconfig stop
sudo chkconfig iptables off
Hier sind einige Ergebnisse, die ich im Zusammenhang mit den zu dieser Frage geposteten Kommentaren erhalten habe:
- Verbindung mit privater IP funktionierte
- Verbindung mit privatem DNS-Namen funktionierte
- Verbindung mit öffentlicher IP funktionierte
- Die Anbindung an das öffentliche EIP hat funktioniert
- Die Verbindung mit dem öffentlichen DNS funktionierte, aber wie Chad Smith in seiner Antwort sagte, gibt DNS diePrivatIP für diesen Namen
Der Grund, warum dies bei mir in einer anderen Instanz funktioniert hat, ist, dass das Image, das ich in dieser Instanz verwendet habe, iptables nicht ausgeführt hat – jedes Image ist anders. Das Image, das ich in diesem Fall verwendet habe, verwendete iptables, um alle Verbindungen außer SSH zu unterbinden.
Antwort2
Etwas abseits vom Thema, aber dies ist das einzige Suchergebnis zu diesem Problem.
Wir hatten ein ähnliches Problem, aber unsere bestehenden Instanzen wurden neu gestartet und konnten plötzlich nicht mehr kommunizieren. Es stellte sich heraus, dass es in der Sicherheitsgruppe zu viele Regeln gab – durch Entfernen einiger konnte die Kommunikation einfach fortgesetzt werden. Vor dem Neustart funktionierte es noch, da die Regeln im Laufe der Zeit durch automatisierte Aufrufe der API hinzugefügt werden.
Hoffe, dass dies in Zukunft jemandem hilft.
Antwort3
Wenn Sie die Sicherheitseinstellungen der laufenden Instanzen nicht ändern können, werden sie NICHT in einer VPC gestartet.
Auch für Instanzen, die sich nicht in VPC befinden, startet EC2 sie in privaten Netzwerken, die miteinander verbunden sind. Sie sollten daher dieprivate IP-Adresseder Instanz B in der Sicherheitsgruppe Instanz A.
Antwort4
AWS verfügt über separate Sicherheitsgruppen für VPC- und Nicht-VPC-Instanzen. Sie müssen also irgendwie herausfinden, ob Sie sich auf VPC befinden oder nicht (gehen Sie einfach zur VPC-Konsole und prüfen Sie, ob Ihre Instanzen dort angezeigt werden) und dann sicherstellen, dass die von Ihnen erstellten Sicherheitsgruppen im selben Kontext sind. Dann können Sie einfach Sicherheitsgruppe A als vertrauenswürdig zur Sicherheitsgruppe B hinzufügen und auch das Gegenteil tun. Auf diese Weise lassen Sie einfach den gesamten Datenverkehr zwischen zwei Hosts auf einzelnen Ports zu (ich gehe davon aus, dass dies Ihre Absicht war).