Невозможно подключиться к любому подключению localhost

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

Конфигурация Loopback

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

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

В соответствии с выведенным выводом ifconfig у вас есть адрес loopback 127.0.0.1 установленный на двух интерфейсах.

Пытаться

 ip addr del 127.0.0.1/32 dev venet0 

и проверьте, восстановлен ли ваш loopback-доступ.

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

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

 ifconfig lo up 

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

 ifconfig -a 

Я смог продолжить свой день … 🙂

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

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

 nc ::1 8080 

или

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