Я використовую Centos 6.5 з останніми оновленнями.

Моя проблема полягає в тому, що коли я намагаюся підключитися до якоїсь локальної служби, вона просто зависає, наприклад:

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

і він зависає до таймауту.

Те саме з telnet, і те саме з підключенням до irc-сервера. Зовнішні з'єднання працюють нормально ...

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

Я без особливих зусиль змиваю iptables. Формати виводу 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         

Конфігурація петлі

# 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

Включення SELinux не покращило його нічим.

ip route show table local

# 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 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

працює добре

# 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

Найдивовижніше в тому, що я можу без проблем підключитися до ssh, nginx-сервера із зовнішньої адреси (наприклад, комп’ютера, з якого я ssh'ing).

Це відбувається після того, як ISP перезавантажив мій сервер. Що може бути корисним у тому, що сервер часто оновлювався без перезавантажень.

У мене був такий самий випуск, який ви описуєте. Мені не вдалося підключитися до будь-якого порту прослуховування на хості з локального, але я можу підключитися, коли віддалено.

Для мене рішенням було повернути назад інтерфейс lo, який з певних причин був знищений і не з'явився під час завантаження.

ifconfig lo up

Після повернення інтерфейсу до резервного копіювання та підтвердження того, що я міг бачити loінтерфейс із ...

ifconfig -a

Мені вдалося продовжити свій день ... :)

Я помітив, що під час запуску ip aя не бачив 127.0.0.1, призначеного інтерфейсу lo: Це те, що підказало мені на тому, що мені потрібен і цей інтерфейс для роботи ...

Відповідно до ifconfigрезультату, який ви опублікували, у вас встановлена ​​адреса петлі 127.0.0.1на двох інтерфейсах.

Спробуйте

ip addr del 127.0.0.1/32 dev venet0

і перевірте, чи відновлено ваш доступ до циклу.

Flup відповів правильно, але я знайшов це питання з іншої причини. Я думаю, альтернативна відповідь потрібна. Сервер, я почав прив'язуватися до сокета IPv6, і я повинен використовувати іншу адресу для підключення:

nc ::1 8080

або

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