Vagrant'ın bağlantı noktası yönlendirmesi çalışmıyor [kapalı]


108

Başlarken kılavuzununvagrant sonunda küçük bir sorunla karşılaşıyorum . Apache2'nin çalıştığı (Puppet aracılığıyla sağlama) bir CentOS ana kutusu üzerinde çalışıyorum. Aşağıdaki satırı kullanarak web istekleri için bağlantı noktası yönlendirmeyi ayarladım Vagrantfile:

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

Ama o limana istekte bulunduğumda başarısız oluyorlar. Safari tarafından bildirilen hata, ' Sunucu beklenmedik bir şekilde bağlantıyı kestiğinden Safari, “ http: // localhost: 4567 / ” sayfasını açamıyor .'

Yaptığım bir vagrant reloadve testere "[varsayılan] - web: 80 => 4567 (adaptör 1)" kaydırma, böylece nerede bu giderilir başlamalıdır? Teşekkürler.


1
Ne curl -v 'http://localhost:4567/'diyor? Safari bazen hata mesajlarını gizleme konusunda biraz fazla iyidir.
Steve Losh

2
Ayrıca, curl 'http://localhost:80'sanal makinenin kendisinden çalışıyor mu? Değilse, sorun bağlantı noktası yönlendirmesi değildir.
Steve Losh

4
curlVM içinden @Steve Losh çalışıyor. curlev sahibinden bana verir (52) Empty reply from server.
Hank Gay

Serseri yeniden doldurma benzer bir soru için bana yardım ediyor ...
23'te geliyor

Benim için durum symfony 3 ile oldu: - sudo php bin / console server: run çalıştırıldığında sunucunun 127.0.0.1:8000 üzerinde çalışmasını sağladığında web tarayıcısından erişemiyorum, curl sanal makineye erişildi. Web dizininde sudo php -S 0.0.0.0:8000 çalıştırıldığında, 127.0.0.1:8082/app_dev.php'ye erişebildim . Bunun neden olduğunu anlamayın ama işe yarıyor.
Darius.V

Yanıtlar:


80

Bunu sadece daha fazla yorum yapmak yerine gerçek bir cevap yapacağım.

İlk şey: curl 'http://localhost:80'VM içinden deneyin . Bu işe yaramazsa, kesinlikle bağlantı noktası yönlendirme değildir.

Sonra: curl -v 'http://localhost:4567/'ana makinenizden deneyin . Curl, size Safari'den daha iyi bir hata mesajı verebilir.

80 numaralı bağlantı noktasına erişimi kısıtlayan bir güvenlik duvarı kurulup kurulmadığını kontrol ederim. Varsayılan Vagrant VM (Ubuntu) bir güvenlik duvarı kurulumuyla birlikte gelmez, ancak başka bir şey kullandığınızı söylediniz, bu yüzden buna değebilir kontrol etmek.

Öyle değilse, 80 numaralı bağlantı noktasında listelenen Apache dışında bir şey yapmayı deneyin. Python, kullanabileceğiniz basit bir HTTP sunucusuyla birlikte gelir - ile klasöre gidin index.htmlve çalıştırın sudo python -m SimpleHTTPServer 80, ardından her iki kutudan da curl ile vurmayı deneyin. Bu işe yararsa, muhtemelen bir Apache yapılandırma sorunudur. Bu durumda yardımcı olmak için Apache ile yeterli deneyimim yok (nginx kullanıyorum).


14
Temel olarak, RedHat ve iptables. Varsayılan politikanın ACCEPTgelen bağlantılar için olup olmadığını kontrol ettim , ancak zincirdeki REJECTson kural olarak tümünü yakalama kuralı olan RedHat'ın özel kural zincirine dikkat etmedim . tl; dr Yolda bir güvenlik duvarı vardı ve fark etmedim.
Hank Gay

Teşekkürler! Bu sinsi güvenlik duvarı kuralı, RHEL 5.5'teki sorunlarıma neden olan şeydi.
Roosh

Robert'ın aşağıdaki yorumunu yeniden yazdırıyorum çünkü kontrol etmenin çok basit bir yolu: service iptables stopBir Konuk güvenlik duvarı sorununu hızlı bir şekilde ortadan kaldırmak için root olarak çalıştır . Gerekirse daha sonra yeniden etkinleştirin.
Arnaud Meuret

1
tuhaf bir centos görüntüsüyle aynı sorunu yaşadı; iptablesneredeyse her şeyi kısıtlıyordu. Bu iptable centos kılavuzunu takip ettim (3.Bölümde Basit Bir Kural Kümesi Yazma çözümü ) ve harika çalıştı :)
GabLeRoux

benim için curl içeride çalışıyordu, bu yüzden ağda çalışmayı etkinleştirdim Vagrantfileve komut çalıştırdımvagrant reload
abhirathore2006

266

Bunun genellikle VM içindeki sunucudan kaynaklandığına dair ek bir not eklemek istedim çünkü ona bağlanıyor 127.0.0.1, bu da geri döngüdür. 0.0.0.0Tüm arayüzlerin erişebilmesi için sunucunun bağlı olduğundan emin olmak isteyeceksiniz .

Django'nun geliştirme sunucuları ve bazı Ruby sunucuları gibi bazı yerleşik uygulama sunucuları varsayılan olarak 127.0.0.1varsayılan olarak ayarlandığından, bu dikkat edilmesi gereken bir şeydir.

Bunun dışında, Steve'in söylediği şey doğrudur: Sanal makine içinden çalıştığından emin olun ve bunun bir yapılandırma sorunu olup olmadığını anlamak için başka basit sunucular deneyin.


8
Bu, webrick'i çalıştıran av tüfeği için gereken düzeltmeydi.
Ronze

Bu benim için sorunu çözdü. Torquebox'u 0.0.0.0'a bağlamak için şunu çalıştırın: torquebox run -b 0.0.0.0
Bartek Skwira

3
Evet sorun buydu. 0.0.0.0'a bağlanması gerekiyor. Vagrant'ın bu sorunu gelecekte otomatik olarak ortadan kaldırmasının bir yolu olup olmadığını merak ediyorum.
CMCDragonkai

1
sinatra ve webrick ile aynı sorun: "set: bind, '0.0.0.0'" sorunu çözdü
pragmatic_programmer

bu benim için düzeltmeydi
sixty4bit

33

CentOS 6.3 w / NGINX'te de aynı sorunu yaşadım ve cevabı serseri kutusundaki iptables'da buldum.

Serseri kutusundaki bash'tan şu adımları izleyin:

İlk liste güncel iptable kuralları

iptables -L -v

Ardından mevcut kuralları temizleyin:

iptables -F

Tcp bağlantı noktası 22'de SSH bağlantılarına izin ver

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

INPUT, FORWARD ve OUTPUT zincirleri için varsayılan politikaları ayarlayın

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

Localhost için erişimi ayarlayın

iptables -A INPUT -i lo -j ACCEPT

Kurulu ve ilgili bağlantılara ait paketleri kabul edin

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

Ayarları kaydet

/sbin/service iptables save

Değiştirilen kuralları listeleyin

iptables -L -v

Curl localhost: [port #] veya tarayıcınızda dışarıdaki serseriden vurun

CentOS iptable yapılandırmaları hakkında daha fazla bilgiyi burada bulabilirsiniz:

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

İyi şanslar.


2
Bunu yazdığınız için teşekkürler. Aynı sorunu Fedora 18'de yaşadım, bu yüzden CentOS'a özgü değil. Umarım bu başka birine yardımcı olur. :)
Benjamin Oakes

4
Bu CentOS'ta bendim. service iptables stop
Robert

2
iptables -Fbenim için yalnız yaptım
code_monk

Bu aynı sorunu çözmek için bu blog yayınında listelenen bazı çalıştırma komutları ile bu sağlam bir çözüm buldum techie-notebook.blogspot.com/2014/05/... ben yapmadım I olarak $ {os_path} bölümleri ile yolumu değiştirmek zorunda kaldı Bu değişken mevcut değil.
Joshua Fricke

27

Benim için daha iyi bir çözüm, güvenlik duvarını devre dışı bırakmak

service iptables stop
chkconfig iptables off

+1 Benim için çalıştı. Yerel bir VirtualBox örneği kullanmak için bir güvenlik duvarına ihtiyacım yoktu.
Eduardo

geçici bir düzeltme istiyorsanız bu iyi bir numara
brrystrw

0

Mitchell gibi bir not daha eklemek istiyorum. davamı 80'den 6789'a iletirsem

$ curl -v http://localhost:6789

Ve aldım

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

Ardından IP adresini kullandım, doğru html mesajını aldım.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.