Korzystam z Centos 6.5 z najnowszymi aktualizacjami.

Mój problem polega na tym, że za każdym razem, gdy próbuję połączyć się z jakąś usługą lokalną, po prostu się zawiesza, na przykład:

wget

wget 127.0.0.1
--2014-03-11 12:43:42--  http://127.0.0.1/
Connecting to 127.0.0.1:80...
After a while timeout...

ssh

# ssh 127.0.0.1 -p 6060 -v
OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 127.0.0.1 [127.0.0.1] port 6060.
debug1: connect to address 127.0.0.1 port 6060: Connection timed out
ssh: connect to host 127.0.0.1 port 6060: Connection timed out

i upływa limit czasu.

To samo z telnetem i to samo z połączeniem z serwerem IRC. Połączenia zewnętrzne działają poprawnie ...

netstat -tpln

# netstat -tpln
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address               Foreign Address             State       PID/Program name   
tcp        0      0 127.0.0.1:25                0.0.0.0:*                   LISTEN      589/sendmail        
tcp        0      0 127.0.0.1:6060              0.0.0.0:*                   LISTEN      520/sshd            
tcp        0      0 0.0.0.0:80                  0.0.0.0:*                   LISTEN      619/nginx           
tcp        0      0 0.0.0.0:22                  0.0.0.0:*                   LISTEN      478/sshd            
tcp        0      0 ::1:6060                    :::*                        LISTEN      520/sshd            
tcp        0      0 :::22                       :::*                        LISTEN      478/sshd            

netstat -rn

# netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 venet0
0.0.0.0         0.0.0.0         0.0.0.0         U         0 0          0 venet0

iptables

Spłukuję iptables bez powodzenia. Dane wyjściowe z iptables:

# iptables -nvL
Chain INPUT (policy ACCEPT 634 packets, 49819 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 517 packets, 47027 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Konfiguracja sprzężenia zwrotnego

# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: venet0: <BROADCAST,POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN 
    link/void 
    inet 127.0.0.1/32 scope host venet0
    inet 176.122.224.115/32 brd 176.122.224.115 scope global venet0:0

Włączenie SELinuksa niczego nie poprawiło.

ip trasa pokaż tabelę lokalnie

# ip route show table local
local 176.122.224.115 dev venet0  proto kernel  scope host  src 176.122.224.115 
broadcast 176.122.224.115 dev venet0  proto kernel  scope link  src 176.122.224.115 
broadcast 127.255.255.255 dev lo  proto kernel  scope link  src 127.0.0.1 
broadcast 127.0.0.0 dev lo  proto kernel  scope link  src 127.0.0.1 
local 127.0.0.1 dev lo  proto kernel  scope host  src 127.0.0.1 
local 127.0.0.0/8 dev lo  proto kernel  scope host  src 127.0.0.1 

traceroute

# traceroute 127.0.0.1
traceroute to 127.0.0.1 (127.0.0.1), 30 hops max, 60 byte packets
 1  localhost.localdomain (127.0.0.1)  0.029 ms  0.014 ms  0.012 ms

ping 127.0.0.1

działa ok

# ping 127.0.0.1
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.024 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.036 ms

Najdziwniejsze w tym jest to, że bez problemów mogę połączyć się z serwerem ssh, nginx z adresu zewnętrznego (np. Komputera, z którego ssh'ing).

Dzieje się tak po ponownym uruchomieniu przez ISP mojego serwera. Być może użyteczne jest to, że serwer był często aktualizowany bez restartów.

Miałem dokładnie ten sam problem, który opisujesz. Nie mogłem połączyć się z żadnym portem nasłuchującym na hoście z lokalnego, ale mogłem połączyć się zdalnie.

Rozwiązaniem było dla mnie przywrócenie interfejsu lo, który z jakiegoś powodu nie działał i nie pojawiał się przy starcie systemu.

ifconfig lo up

Po ponownym uruchomieniu interfejsu i potwierdzeniu, że mogę zobaczyć lointerfejs z ...

ifconfig -a

Udało mi się zacząć dzień ... :)

Zauważyłem, że podczas uruchamiania ip anie widziałem 127.0.0.1 przypisanego do interfejsu lo:. Właśnie to mnie przekonało o tym, że ten interfejs musiałem również działać ...

Zgodnie z ifconfigopublikowanym wyjściem, adres sprzężenia zwrotnego jest 127.0.0.1ustawiony na dwóch interfejsach.

Próbować

ip addr del 127.0.0.1/32 dev venet0

i sprawdź, czy przywrócono dostęp do pętli zwrotnej.

Flup odpowiedział słusznie, ale znalazłem to pytanie z innego powodu. Myślę, że potrzebna jest alternatywna odpowiedź. Serwer, zacząłem łączyć się z gniazdem IPv6 i powinienem użyć innego adresu do połączenia, takiego jak:

nc ::1 8080

lub

curl http://[::1]:8080/