Amazon-EC2-Ports trotz Sicherheitsgruppen- und iptables-Konfiguration nicht geöffnet

2368
pie3636

Ich habe gerade einen Amazon EC2-Server gemietet, um eine node.js-App zu hosten, die den Client auf Port 9001 hört.

Ich habe die Sicherheitsgruppen konfiguriert und an diesem Port eingehende und ausgehende Regeln hinzugefügt . Es gibt keine Firewall (Amazon Linux) und ich habe iptables komplett deaktiviert.

A sudo netstat -plunta | grep LISTENgibt dies zurück:

tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 2064/sshd  tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 2104/sendmail  tcp 0 0 0.0.0.0:9001 0.0.0.0:* LISTEN 3207/node  tcp 0 0 127.0.0.1:27017 0.0.0.0:* LISTEN 2146/mongod  tcp 0 0 :::80 :::* LISTEN 2303/httpd  tcp 0 0 :::22 :::* LISTEN 2064/sshd  

Meine Anwendung node.js überwacht diesen Port und alle Adressen mit dem Befehl server.listen(9001, "0.0.0.0");

Eine nmap des Servers gibt jedoch Folgendes zurück:

Portscan scan report for 172.31.47.81 Host is up. All 1000 scanned ports on 172.31.47.81 are filtered  Portscan done: 1 IP address (1 host up) scanned in 2.32 seconds 

Alternativ kann mir eine nmap auf meinem Telefon zeigen, dass nur Port 80 geöffnet ist.

Wenn ich die Anwendung node.js auf dem Server ausführen und eine Aktion ausführen kann, telnet <ip_server> 9001funktioniert es. Wenn ich jedoch dasselbe von meinem PC aus mache, erhalte ich einen Timeout-Fehler.

Ich weiß, dass diese Frage mehrmals angesprochen wurde, aber keine der Lösungen, die ich ausprobiert habe, hat funktioniert. Ich kann den Server anpingen und ssh verwenden, um eine Verbindung zu ihm herzustellen, aber die Anwendung node.js funktioniert nicht, und die Ports, die eigentlich geöffnet sein sollten, sind nicht der Fall (selbst wenn versucht wird, über einen Browser eine Verbindung zum Webserver herzustellen) Funktioniert nicht, obwohl httpd mit einer richtigen Website konfiguriert wurde, so ist Port 80 ebenfalls nicht geöffnet.

Irgendwelche Ideen, wie man das beheben kann?

2

1 Antwort auf die Frage

2
Michael - sqlbot

Alle 1000 gescannten Ports auf 172.31.47.81 werden gefiltert

Da sollten sie in der Tat sein.

Es gibt mehrere IPv4-Adressbereiche, die für die Verwendung in privaten Netzwerken reserviert sind.

10.*.*.* 172.16.*.* through 172.31.*.* 192.168.*.* 

Auf jede Adresse in diesen Bereichen kann nicht direkt über das Internet zugegriffen werden.

http://tools.ietf.org/html/rfc1918

https://www.arin.net/knowledge/address_filters.html

EC2-Instanzen haben immer eine private IP-Adresse und manchmal eine von außen zugängliche öffentliche IP-Adresse. Diese externen Adressen werden entweder beim Start der Instanz aus einem Pool dynamisch zugewiesen (und freigegeben, wenn die Instanz gestoppt oder beendet wird (zu diesem Zeitpunkt geht die Adresse wieder in den Pool über), oder sie können vom Kunden fortlaufend reserviert und Instanzen zugeordnet / nicht zugeordnet werden und für die spätere Wiederverwendung des Kunden aufbewahrt werden (in diesem Fall werden sie als "elastische IP-Adressen" bezeichnet.)

Innerhalb der EC2-Bereitstellung eines Kunden in einer bestimmten Region (und über VPN-Tunnel in VPC) können sich die Instanzen über ihre private IP-Adresse ansprechen (und sollten, da sie frei von Datentransportgebühren sind) ... aber über das Internet können Instanzen dies tun Zugriff nur über ihre öffentliche (auch als "externe" bezeichnete) IP-Adresse, die in der Konsole sichtbar ist ... obwohl aus Sicht der Instanz (dh ifconfigusw.) nur die private Adresse bekannt ist.

Die EC2-Infrastruktur übernimmt transparent die Netzwerkadressenübersetzung (Network Address Translation, NAT) zwischen der externen öffentlichen und der internen privaten Adresse.

Wenn Sie mit ssh von außerhalb auf die Instanz zugreifen, ist die IP-Adresse, die Sie zum Herstellen der SSH-Verbindung verwenden, auch die, die Sie für den Zugriff auf andere Dienste verwenden müssen.