Я использую 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

пинг 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).

Это происходит после того, как провайдер перезагрузил мой сервер. Что может быть полезно, так это то, что сервер часто обновлялся без перезагрузок.

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

Пытаться

ip addr del 127.0.0.1/32 dev venet0

и посмотрите, восстановлен ли ваш петлевой доступ.

У меня была та же самая проблема, которую вы описываете. Мне не удалось подключиться к любым прослушивающим портам на хосте с локального компьютера, но я мог подключиться при удаленном подключении.

Решение для меня состояло в том, чтобы восстановить интерфейс lo, который по какой-то причине был недоступен и не загружался при загрузке.

ifconfig lo up

После восстановления интерфейса и подтверждения того, что я вижу loинтерфейс с ...

ifconfig -a

Я смог продолжить свой день ... :)

Я заметил, что во время работы ip aя не увидел 127.0.0.1, назначенный интерфейсу lo :. Это то, что подсказало мне, что мне нужен этот интерфейс, чтобы он тоже работал ...

Флуп ответил правильно, но я нашел этот вопрос с другой причиной. Я думаю, что нужен альтернативный ответ. Сервер, я начал связываться с сокетом IPv6, и я должен использовать другой адрес для подключения, например:

nc ::1 8080

или

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