El reenvío de puertos de Vagrant no funciona [cerrado]

108

Me encuentro con un pequeño problema al final de la guía de introducción paravagrant . Estoy trabajando en una caja base CentOS que tiene Apache2 en ejecución (aprovisionamiento a través de Puppet). Configuré el reenvío de puertos para solicitudes web usando la siguiente línea en Vagrantfile:

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

Pero cuando hago solicitudes a ese puerto, fallan. El error informado por Safari es "Safari no puede abrir la página" http: // localhost: 4567 / "porque el servidor cortó la conexión inesperadamente."

Hice un vagrant reloady vi "[predeterminado] - web: 80 => 4567 (adaptador 1)" en el desplazamiento, entonces, ¿por dónde debería comenzar a solucionar este problema? Gracias.

— Hank Gay
fuente

1

¿Qué curl -v 'http://localhost:4567/'dice? A veces, Safari es demasiado bueno para ocultar mensajes de error.

— Steve Losh

2

Además, ¿funciona curl 'http://localhost:80'desde la propia máquina virtual? Si no es así, el problema no es el reenvío de puertos.

— Steve Losh

4

@Steve Losh curldesde dentro de la VM está funcionando. curldel anfitrión me da (52) Empty reply from server.

— Hank Gay

La recarga vagabunda me ayuda en una pregunta similar ...

— haudoing

Para mí, el caso fue con Symfony 3: - cuando se ejecuta sudo php bin / console server: run, lo que hace que el servidor se ejecute en 127.0.0.1:8000, entonces no puedo acceder desde el navegador web, se accede a curl en la máquina virtual. Cuando ejecuté sudo php -S 0.0.0.0:8000 en el directorio web, pude acceder a 127.0.0.1:8082/app_dev.php . No entiendo por qué sucede esto, pero funciona.

— Darius.V

80

Haré de esta una respuesta real en lugar de solo más comentarios.

Primero: intente curl 'http://localhost:80'desde dentro de la máquina virtual. Si eso no funciona, definitivamente no es el reenvío de puertos.

Siguiente: intente curl -v 'http://localhost:4567/'desde su máquina host. Curl puede darle un mensaje de error mejor que Safari.

Verificaría que no hay firewalls configurados que restrinjan el acceso al puerto 80. La VM Vagrant predeterminada (Ubuntu) no viene con una configuración de firewall, pero dijiste que estás usando otra cosa, por lo que podría valer la pena. verificar.

Si no es así, intente hacer que aparezca algo diferente a Apache en el puerto 80. Python se envía con un servidor HTTP simple que puede usar: vaya a la carpeta con index.htmly ejecute sudo python -m SimpleHTTPServer 80, luego intente presionar eso con curl en ambos cuadros. Si eso funciona, probablemente sea un problema de configuración de Apache. No tengo suficiente experiencia con Apache para ayudar si ese es el caso (uso nginx).

— Steve Losh
fuente

14

Básicamente, apesto en RedHat y iptables. Verifiqué para asegurarme de que la política predeterminada fuera ACCEPTpara conexiones entrantes, pero no presté atención a la cadena de reglas personalizadas de RedHat, que tiene una REJECTregla general como última regla de la cadena. tl; dr. Tenía un firewall en el camino y no me di cuenta.

— Hank Gay

¡Gracias! Esa astuta regla de firewall es lo que causó mis problemas en RHEL 5.5.

— Roosh

Reimprimo el comentario de Robert a continuación porque es una forma trivial de verificar: Ejecutar service iptables stopcomo root para descartar rápidamente un problema de firewall invitado. Vuelva a habilitarlo más tarde si es necesario.

— Arnaud Meuret

1

tenía el mismo problema con una extraña imagen centos; iptablesestaba restringiendo casi todo. Seguí esta guía de iptable centos (solución en la sección 3 Escribiendo un conjunto de reglas simples ) y funcionó a la

— perfección

para mí, curl estaba funcionando en el interior, así que habilité la conexión en red Vagrantfiley ejecuté el comandovagrant reload

— abhirathore2006

266

Quería agregar una nota adicional de que a menudo esto es causado por el servidor dentro de la VM porque se une a 127.0.0.1, que es un bucle invertido. Querrá asegurarse de que el servidor esté vinculado para 0.0.0.0que todas las interfaces puedan acceder a él.

Algunos servidores de aplicaciones incorporados, como los servidores de desarrollo de Django y algunos servidores Ruby, están predeterminados 127.0.0.1de forma predeterminada, por lo que esto es algo a tener en cuenta.

Aparte de eso, lo que Steve dijo es cierto: asegúrese de que funcione desde la máquina virtual y pruebe con otros servidores simples para tratar de averiguar si se trata de un problema de configuración.

— Mitchell
fuente

8

Esta era la solución necesaria para la escopeta con webrick.

— Ronze

Esto resolvió mi problema. Para vincular Torquebox a 0.0.0.0, ejecútelo con: torquebox run -b 0.0.0.0

— Bartek Skwira

3

Sí, este era el problema. Necesita enlazar a 0.0.0.0. Me pregunto si hay alguna forma en que Vagrant pueda hacer que este problema desaparezca automáticamente en el futuro.

— CMCDragonkai

1

mismo problema con sinatra y webrick: "set: bind, '0.0.0.0'" resolvió el problema

— pragmatic_programmer

esta fue la solución para mí

— sixty4bit

33

Tuve el mismo problema en CentOS 6.3 w / NGINX y encontré que la respuesta estaba en las iptables del cuadro vagabundo.

Desde bash on the vagrant box, sigue estos pasos:

Primero enumere las reglas actuales de iptable

iptables -L -v

Luego limpie las reglas actuales:

iptables -F

Permitir conexiones SSH en el puerto tcp 22

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

Establecer políticas predeterminadas para las cadenas INPUT, FORWARD y OUTPUT

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

Establecer acceso para localhost

iptables -A INPUT -i lo -j ACCEPT

Acepta paquetes pertenecientes a conexiones establecidas y relacionadas

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

Guardar ajustes

/sbin/service iptables save

Lista de reglas modificadas

iptables -L -v

Curl localhost: [puerto #] o presione en su navegador desde fuera de vagrant

Más información sobre las configuraciones de iptable de CentOS aquí:

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

Buena suerte.

— travyo
fuente

2

Gracias por escribir esto. Tuve este mismo problema en Fedora 18, por lo que no es específico de CentOS. Espero que eso ayude a alguien más. :)

— Benjamin Oakes

4

Este era yo en CentOS. service iptables stop

— Robert

2

iptables -Fsolo lo hizo por mí

— code_monk

Encontré una solución sólida para esto con algunos comandos ejecutivos enumerados en esta publicación de blog para resolver este mismo problema techie-notebook.blogspot.com/2014/05/ ... Tuve que reemplazar mi ruta con las secciones $ {os_path} como no hice No tengo esa variable disponible.

— Joshua Fricke

27

Una mejor solución para mí es deshabilitar el firewall.

service iptables stop
chkconfig iptables off

— edwinallenz
fuente

+1 funcionó para mí. Para usar una instancia local de VirtualBox, no necesitaba un firewall.

— Eduardo

es un buen truco si quieres una solución temporal

— brrystrw

0

También quiero agregar otra nota como Mitchell. si mi caso lo reenvío al 6789 de 80

$ curl -v http://localhost:6789

Y tengo

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

Luego, usé la dirección IP en su lugar, obtuvo el mensaje html correcto.

— Larry Cai
fuente