La redirection de port de Vagrant ne fonctionne pas [fermé]

108

Je rencontre un petit problème à la fin du guide de mise en route pourvagrant . Je travaille sur une basebox CentOS sur laquelle Apache2 est en cours d'exécution (provisionnement via Puppet). J'ai configuré la redirection de port pour les demandes Web en utilisant la ligne suivante dans Vagrantfile:

 config.vm.forward_port "web", 80, 4567

Mais quand je fais des demandes à ce port, elles échouent. L'erreur signalée par Safari est "Safari ne peut pas ouvrir la page" http: // localhost: 4567 / "car le serveur a interrompu la connexion de manière inattendue."

J'ai fait un vagrant reloadet j'ai vu "[par défaut] - web: 80 => 4567 (adaptateur 1)" dans le défilement, alors par où dois-je commencer à résoudre ce problème? Merci.

— Hank Gay
source

1

Que curl -v 'http://localhost:4567/'dit-on? Parfois, Safari est un peu trop gentil pour cacher les messages d'erreur.

— Steve Losh

2

De plus, curl 'http://localhost:80'la machine virtuelle elle-même fonctionne-t-elle? Sinon, le problème n'est pas la redirection de port.

— Steve Losh

4

@Steve Losh curldepuis la VM fonctionne. curlde l'hôte me donne (52) Empty reply from server.

— Hank Gay

The vagrant reload m'aide sur une question similaire ...

— haudoing

Pour moi, le cas était avec symfony 3: - lors de l'exécution sudo php bin / console server: run qui rend le serveur fonctionnant sur 127.0.0.1:8000 alors je ne peux pas accéder à partir du navigateur Web, curl dans la machine virtuelle accessible. Lors de l'exécution de sudo php -S 0.0.0.0:8000 dans le répertoire Web, je pouvais accéder à 127.0.0.1:8082/app_dev.php . Je ne comprends pas pourquoi cela se produit, mais cela fonctionne.

— Darius.V

80

Je vais en faire une réponse réelle au lieu de simplement plus de commentaires.

Première chose: essayez curl 'http://localhost:80'depuis la VM. Si cela ne fonctionne pas, ce n'est certainement pas la redirection de port.

Suivant: essayez curl -v 'http://localhost:4567/'depuis votre machine hôte. Curl peut vous donner un meilleur message d'erreur que Safari.

Je vérifierais qu'aucun pare-feu n'est configuré pour restreindre l'accès au port 80. La VM Vagrant par défaut (Ubuntu) n'est pas livrée avec un pare-feu configuré, mais vous avez dit que vous utilisiez autre chose, donc cela pourrait en valoir la peine vérifier.

Si ce n'est pas le cas, essayez de créer autre chose qu'Apache répertorié sur le port 80. Python est livré avec un simple serveur HTTP que vous pouvez utiliser - allez dans le dossier avec index.htmlet exécutez sudo python -m SimpleHTTPServer 80, puis essayez de frapper cela avec curl dans les deux cases. Si cela fonctionne, c'est probablement un problème de configuration Apache. Je n'ai pas assez d'expérience avec Apache pour vous aider si c'est le cas (j'utilise nginx).

— Steve Losh
source

14

En gros, je suis nul chez RedHat et iptables. J'ai vérifié pour m'assurer que la politique par défaut était ACCEPTpour les connexions entrantes, mais je n'ai pas fait attention à la chaîne de règles personnalisées de RedHat, qui a une REJECTrègle fourre-tout comme dernière règle de la chaîne. tl; dr J'avais un pare-feu sur le chemin et je n'ai tout simplement pas remarqué.

— Hank Gay

Merci! Cette règle de pare-feu sournoise est ce qui a causé mes problèmes sur RHEL 5.5.

— Roosh

Je réimprime le commentaire de Robert ci-dessous car c'est un moyen si simple de vérifier: Exécutez en service iptables stoptant que root pour éliminer rapidement un problème de pare-feu invité. Réactivez-le plus tard si nécessaire.

— Arnaud Meuret

1

eu le même problème avec une image bizarre de centos; iptablesrestreignait presque tout. J'ai suivi ce guide centos iptable (solution dans la section 3 Ecrire un jeu de règles simple ) et cela a fonctionné comme un charme :)

— GabLeRoux

pour moi, curl fonctionnait à l'intérieur, j'ai donc activé la mise en réseau Vagrantfileet exécuté la commandevagrant reload

— abhirathore2006

266

Je voulais ajouter une note supplémentaire selon laquelle cela est souvent causé par le serveur dans la machine virtuelle car il se lie à 127.0.0.1, ce qui est un bouclage. Vous voudrez vous assurer que le serveur est lié à 0.0.0.0afin que toutes les interfaces puissent y accéder.

Certains serveurs d'applications intégrés tels que les serveurs de développement de Django et certains serveurs Ruby utilisent 127.0.0.1par défaut par défaut, c'est donc quelque chose à surveiller.

En dehors de cela, ce que Steve a dit est vrai: assurez-vous que cela fonctionne depuis la machine virtuelle et essayez d'autres serveurs simples pour essayer de déterminer s'il s'agit d'un problème de configuration.

— Mitchell
source

8

C'était le correctif nécessaire pour le fusil de chasse exécutant webrick.

— Ronze

Cela a résolu le problème pour moi. Pour lier Torquebox à 0.0.0.0, exécutez-le avec: torquebox run -b 0.0.0.0

— Bartek Skwira

3

Oui, c'était le problème. Besoin de se lier à 0.0.0.0. Je me demande s'il existe un moyen pour Vagrant de faire disparaître automatiquement ce problème à l'avenir?

— CMCDragonkai

1

même problème avec sinatra et webrick: "set: bind, '0.0.0.0'" a résolu le problème

— pragmatic_programmer

c'était le correctif pour moi

— sixty4bit

33

J'ai eu le même problème sur CentOS 6.3 w / NGINX et j'ai trouvé la réponse dans les iptables sur la boîte vagrant.

De bash sur la boîte vagabonde, suivez ces étapes:

Première liste des règles iptables actuelles

iptables -L -v

Puis vider les règles actuelles:

iptables -F

Autoriser les connexions SSH sur le port TCP 22

iptables -A INPUT -p tcp --dport 22 -j ACCEPT

Définir les politiques par défaut pour les chaînes INPUT, FORWARD et OUTPUT

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

Définir l'accès pour localhost

iptables -A INPUT -i lo -j ACCEPT

Accepter les paquets appartenant aux connexions établies et associées

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

Enregistrer les paramètres

/sbin/service iptables save

Liste des règles modifiées

iptables -L -v

Curl localhost: [port #] ou appuyez dessus dans votre navigateur depuis l'extérieur de vagrant

Plus d'informations sur les configurations iptables CentOS trouvées ici:

http://wiki.centos.org/HowTos/Network/IPTables

Bonne chance.

— travyo
source

2

Merci d'avoir écrit ceci. J'ai eu ce même problème sur Fedora 18, donc ce n'est pas spécifique à CentOS. J'espère que cela aide quelqu'un d'autre. :)

— Benjamin Oakes

4

C'était moi sur CentOS. service iptables stop

— Robert

2

iptables -Fseul l'a fait pour moi

— code_monk

J'ai trouvé une solution solide à cela avec quelques commandes exécutables répertoriées dans ce billet de blog pour résoudre ce même problème techie-notebook.blogspot.com/2014/05/... J'ai dû remplacer mon chemin par les sections $ {os_path} comme je l'ai fait Je n'ai pas cette variable disponible.

— Joshua Fricke

27

Une meilleure solution pour moi est de désactiver le pare-feu

service iptables stop
chkconfig iptables off

— Edwinallenz
source

+1 a travaillé pour moi. Pour utiliser une instance VirtualBox locale, je n'avais pas besoin d'un pare-feu.

— Eduardo le

c'est un bon truc si vous voulez une solution temporaire

— brrystrw

0

Je veux aussi ajouter une autre note comme Mitchell. si mon cas je le transfère au 6789 de 80

$ curl -v http://localhost:6789

Et j'ai

<HTML>
<HEAD><TITLE>Redirection</TITLE></HEAD>
<BODY><H1>Redirect</H1></BODY>

Ensuite, j'ai utilisé l'adresse IP à la place, il a reçu le bon message html.

— Larry Cai
source