Ich habe mehrere Instanzen in derselben Sicherheitsgruppe (z. B. Gruppe A) ausgeführt, die miteinander kommunizieren müssen, insbesondere über Port 4369.
Jede Instanz hat eine andere Elastic IP.
Die Sicherheitsgruppe ist so konfiguriert, dass eingehender Datenverkehr über TCP:4369 Quelle: sg-XXXXX (Gruppe A) zugelassen wird.
Instanzen können jedoch nur über die interne IP (10.xxx.xxx.xx) oder den öffentlichen DNS von Amazon miteinander kommunizieren: ec2-ELASTIC-IP.compute-1.amazonaws.com (offenbar übersetzt Amazon dies in die interne IP).
Wenn ich Elastic IP verwende, funktioniert es nicht. Wenn ich meinen eigenen FQDN verwende, der auf Elastic IP verweist, funktioniert es nicht.
Wenn ich die Quelle in der eingehenden Regel von sg-XXXXX (Gruppe A) auf 0.0.0.0 ändere, funktioniert es mit meinem eigenen FQDN und der elastischen IP. Aus Sicherheitsgründen werden wir dies jedoch nicht verwenden. Wenn ich die eingehende Regel entferne, funktioniert nichts, auch wenn die interne IP verwendet wird.
Was muss ich also tun, wenn ich meinen eigenen FQDN verwenden möchte? (worker-1.company.com -> Elastic IP), der viel besser lesbar und einfacher zu verwalten ist.
Antwort1
Das von Ihnen beschriebene Verhalten ist normal, da bei der Kommunikation zwischen Instanzen über elastische IP die Identität der Maschine innerhalb der Sicherheitsgruppe - für Zwecke der Sicherheitsgruppenkonfigurationen, die auf einer sg-xxxxxxxx-Quelle basieren - nicht wirklich mit voller Sicherheit festgestellt werden kann, weil die Übersetzung der Adressen den Datenverkehr (vermutlich) über zwischengeschaltete Hardware sendet und der Datenverkehr nicht mehr als vondirektaus der Instanz.
Die Lösung besteht darin, Ihre Hosts im DNS mit CNAME-Einträgen zu benennen, die auf den öffentlichen DNS-Eintrag verweisen, anstatt mit A-Einträgen, die auf eine bestimmte IP-Adresse verweisen.
In der DNS-Zone von company.com:
worker-1 IN CNAME xx-xx-xx-xx.compute-1.amazonaws.com.
Jetzt wird worker-1.company.com bei einer Abfrage von innen in die private IP aufgelöst, und bei einer Abfrage von außen in die öffentliche IP.
Antwort2
Es ist nicht perfekt, aber Sie können explizite Zuordnungen von den FQDNs zu den privaten IPs in der Hosts-Datei jeder der Instanzen hinzufügen. Ihr Code verwendet also einen FQDN, aber das Netzwerk verwendet tatsächlich private Kommunikation (was ohnehin sicherer ist).
Dies ist eine sinnvolle Option, wenn Sie über einen kleinen, relativ festen Satz von Instanzen verfügen. Sie sollten diesen Prozess nach Möglichkeit automatisieren.
Sie können auch Route 53, Amazons DNS als Service, verwenden. Ordnen Sie Ihren FQDN dem öffentlichen DNS-Namen der Instanz zu. Innerhalb von EC2 wird dies der privaten IP zugeordnet. Sie müssen dies noch mithilfe der Route 53-API automatisieren.