De acordo com a saída ifconfig
que você publicou, você tem o endereço de loopback 127.0.0.1
definido em duas interfaces.
Tente
ip addr del 127.0.0.1/32 dev venet0
e veja se o seu acesso de loopback foi restaurado.
Estou usando o Centos 6.5 com as atualizações mais recentes.
Meu problema é que sempre que eu tento me conectar a algum serviço local, ele simplesmente trava, por exemplo:
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 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
e demora para expirar.
O mesmo com o telnet e o mesmo com a conexão ao servidor irc. Conexões externas estão funcionando bem ...
# 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
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
Eu posso liberar iptables sem sorte. Formulário de saída 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
A conversão do SELinux não melhorou com nada.
# 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
funciona bem
# 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
A coisa mais estranha sobre isso é que, eu posso conectar ao servidor ssh, nginx de external endereço (por exemplo, computador do qual eu ssh'ing) sem problemas.
Isso acontece depois que o ISP reinicializou meu servidor. A coisa que talvez seja útil é que o servidor foi atualizado com freqüência sem reinicializações.
De acordo com a saída ifconfig
que você publicou, você tem o endereço de loopback 127.0.0.1
definido em duas interfaces.
Tente
ip addr del 127.0.0.1/32 dev venet0
e veja se o seu acesso de loopback foi restaurado.
Eu tive exatamente o mesmo problema que você descreve. Não consegui me conectar a nenhuma porta de escuta no host do local, mas consegui conectar quando remoto.
A solução para mim foi trazer a interface de volta para cima, que estava inativa por algum motivo e não aparecer na inicialização.
ifconfig lo up
Depois de recuperar a interface e confirmar que eu podia ver a interface lo
com ...
ifconfig -a
Eu pude continuar meu dia ...:)
Percebi que, ao executar ip a
, não vi 127.0.0.1 atribuído à interface lo:. Isto é o que me indicou o fato de que eu precisava que essa interface estivesse funcionando também ...
Flup respondeu certo, mas achei essa pergunta com outro motivo. Eu acho que uma resposta alternativa é necessária. Servidor, eu comecei a ligar ao socket IPv6 e eu deveria usar outro endereço para se conectar como:
nc ::1 8080
ou
curl http://[::1]:8080/
Tags networking linux centos