Comment faire pour configurer directement accès http à l'instance EC2?

C'est très basique, Amazon EC2 question, mais je suis perplexe, donc voilà.

Je veux lancer une instance Amazon EC2 et permettre l'accès à HTTP sur les ports 80 et 8888
à partir de n'importe où. Jusqu'à présent, je ne peux même pas permettre à l'instance à se connecter sur les ports à l'aide de
sa propre adresse IP (mais il va se connecter à localhost).

J'ai configuré "par défaut" groupe de sécurité pour HTTP à l'aide de la norme HTTP option sur la console de gestion (et aussi SSH).

J'ai lancé mon exemple dans le groupe de sécurité par défaut.

Je me suis connecté à l'instance sur SSH port 22 par deux fois et dans une seule fenêtre de lancement d'un serveur HTTP
sur le port 80. Dans l'autre fenêtre je vérifie que je peux me connecter à HTTP à l'aide de la "localhost".

Cependant, lorsque j'essaie d'accès HTTP à partir de l'instance (ou ailleurs) en utilisant soit le public DNS ou l'adresse IP Privée je het "connexion refusée".

Ce que je fais mal, s'il vous plaît?

Ci-dessous est une console fragment montrant le wget qui réussit et les deux qui échouent à courir à partir de l'instance elle-même.

--2012-03-07 15:43:31--  http://localhost/
Resolving localhost... 127.0.0.1
Connecting to localhost|127.0.0.1|:80... connected.
HTTP request sent, awaiting response... 302 Moved Temporarily
Location: /__whiff_directory_listing__ [following]
--2012-03-07 15:43:31--  http://localhost/__whiff_directory_listing__
Connecting to localhost|127.0.0.1|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: “__whiff_directory_listing__”

[ <=>
                                                                                                               ] 7,512       --.-K/s   in 0.03s   

2012-03-07 15:43:31 (263 KB/s) - “__whiff_directory_listing__” saved [7512]

[ec2-user@ip-10-195-205-30 tmp]$ wget http://ec2-50-17-2-174.compute-1.amazonaws.com/
--2012-03-07 15:44:17--  http://ec2-50-17-2-174.compute-1.amazonaws.com/
Resolving ec2-50-17-2-174.compute-1.amazonaws.com... 10.195.205.30
Connecting to ec2-50-17-2-174.compute-1.amazonaws.com|10.195.205.30|:80... failed:          
Connection refused.
[ec2-user@ip-10-195-205-30 tmp]$ wget http://10.195.205.30/
--2012-03-07 15:46:08--  http://10.195.205.30/
Connecting to 10.195.205.30:80... failed: Connection refused.
[ec2-user@ip-10-195-205-30 tmp]$

OriginalL'auteur Aaron Watters | 2012-03-07

  1. 18

    La norme sockets tcp interface nécessite de vous lier à une adresse IP en particulier lorsque vous les envoyer ou de les écouter. Il ya un couple d'un peu spécial adresses: localhost (qui vous êtes probablement familier avec) qui est 127.0.0.1. Il ya aussi une adresse 0.0.0.0 ou INADDR_ANY (internet protocole spécial d'abréviation pour TOUTE ADRESSE). C'est un moyen de l'écouter sur n'IMPORTE ou, le plus souvent, TOUTES les adresses sur l'ordinateur hôte. C'est une façon de dire au noyau de la pile que vous n'êtes pas intéressé par une adresse IP particulière.

    Donc, quand vous êtes en train de configurer un serveur qui écoute sur "localhost" vous dites que le service que vous voulez utiliser la spéciale réservée adresse qui ne peut être atteint par les utilisateurs de cette machine, et bien qu'il existe sur chaque hôte, d'une connexion à localhost ne jamais atteindre l'hôte vous en faites la demande.

    Lorsque vous voulez un service accessible partout (sur un hôte local, sur toutes les interfaces, etc.) vous pouvez spécifier 0.0.0.0.

    Compléter la réponse de Pierre, vous pouvez modifier la ligne suivante à /etc/jetty/jetty.xml: <Set name="accueil"><SystemProperty name="jetty.accueil" />0.0.0.0</>

    OriginalL'auteur Peter N

  2. 18

    (0) C'est idiot, mais la première chose que vous devez faire est de vous assurer que votre serveur web est en cours d'exécution.

    (1) Vous devez modifier votre Groupe de Sécurité de laisser entrant paquets HTTP accéder à votre site web. Si votre site web est à l'écoute sur le port 80, vous avez besoin de modifier le Groupe de Sécurité pour ouvrir l'accès au port 80 comme mentionné ci-dessus. Si votre site web est à l'écoute sur un autre port, alors vous avez besoin de modifier le Groupe de Sécurité à l'accès que l'autre port.

    (2) Si vous exécutez une instance de Linux, le iptables pare-feu peut être en cours d'exécution par défaut. Vous pouvez vérifier que ce pare-feu est actif en cours d'exécution

    sudo service iptables statut

    sur la ligne de commande. Si vous obtenez un résultat, puis le pare-feu iptables est en cours d'exécution. Si vous obtenez un message "Pare-feu pas en cours d'exécution", c'est assez explicite. En général, la iptables pare-feu est en cours d'exécution par défaut.

    Vous avez deux options: frapper le pare-feu ou de modifier le pare-feu configuration de laisser le trafic HTTP à travers. J'ai opté pour assommer le pare-feu que le plus simple (pour moi).

    sudo service iptables stop

    Il n'y a pas de réel risque pour la sécurité dans l'arrêt iptables parce que iptables, si active, se contente de répliquer les fonctionnalités d'Amazon pare-feu, qui est l'aide du Groupe de Sécurité pour générer le fichier de configuration. Nous supposons ici que Amazon AWS n'est pas misconfigure son pare - feu et une très bonne hypothèse.

    (3) Maintenant, vous pouvez accéder à l'URL de votre navigateur.

    (4) Les Serveurs Microsoft Windows également exécuter leur pare-feu par défaut, et vous aurez besoin pour résoudre le Windows du Serveur de pare-feu personnel, trop.

    De Correction: par AWS défaut, AWS ne pas le feu au serveur de pare-feu, tels iptables (Centos) ou de l'UAF (Ubuntu) lors de votre commande la création de nouvelles instances EC2 - C'est pourquoi les instances EC2 qui sont dans le même VPC pouvez ssh les uns des autres et vous pouvez "voir" le serveur web que vous avez tiré à partir d'une autre instance EC2 dans le même VPC.

    Assurez-vous que votre API RESTful est à l'écoute sur toutes les interfaces, c'est à dire 0.0.0.0:portID

    J'avais oublier de vérifier ma config iptables... après la lecture de votre réponse, j'ai vérifié mes règles et j'ai eu une règle qui redirige les paquets de 80 à 3000 et c'est la raison pour laquelle il n'a pas de travail.

    OriginalL'auteur Vietnhi Phuvan

  3. 4

    Que vous êtes l'obtention de connexion refusée (les paquets sont rejetés) je parie que c'est iptables à l'origine du problème. Essayez d'exécuter

    iptables -I INPUT-p tcp --dport 80 -j ACCEPT

    iptables -I INPUT-p tcp --dport 8888 -j ACCEPT

    et tester la connexion.

    Vous devrez également ajouter à ces règles en permanence que vous pouvez le faire en ajoutant les lignes ci-dessus dans ie. /etc/sysconfig/iptables si vous utilisez Red Hat.

    OriginalL'auteur kazimir

  4. 3

    Apparemment j'ai été "liaison à localhost", alors que j'avais besoin de se lier à 0.0.0.0 pour répondre à port 80 pour toutes les interfaces TCP (?). C'est une subtilité de TCP/IP que je ne comprends pas tout encore, mais il a résolu le problème.

    Par défaut - et c'est une AWS par défaut, la liaison est uniquement pour le localhost de l'interface, qui est interne au noyau. Donc, si vous essayez d'accéder au port à partir d'un dehors de la propriété intellectuelle, vous êtes noy allez obtenir quelque chose parce que le serveur n'est pas à l'écoute sur toutes les interfaces externes.

    OriginalL'auteur Aaron Watters

  5. 0

    Dû effectuer les opérations suivantes:

    1) Permettre l'accès HTTP à l'exemple de config, ce n'était pas par défaut uniquement SSH
    2) a Essayé de faire nodejs serveur, de sorte que le port a été lié à 80 -> 3000 a les commandes suivantes pour corriger cela

    iptables -F
iptables -I INPUT -p tcp --dport 80 -j ACCEPT
sudo service iptables-persistent flush

    OriginalL'auteur TOBlender

  6. 0

    Amazon soutien répondu et il a travaillé instantanément:

    J'ai reproduit le problème sur ma fin sur un test de Ubuntu instance et a été en mesure de le résoudre. Le problème était que pour exécuter Tomcat sur un port inférieur à 1024 dans Ubuntu/Unix, le service a besoin des privilèges root qui n'est généralement pas recommandé que l'exécution d'un processus sur le port 80 avec les privilèges de root est inutile de risque pour la sécurité.

    Ce que nous recommandons est d'utiliser une redirection de port via iptables :-

    iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080

    J'espère que les informations ci-dessus permet de.

    OriginalL'auteur Priya Ranjan Kumar