web-dev-qa-db-ja.com

ローカルホスト接続に接続できません

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ルート表示テーブル

# 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

大丈夫

# 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

それについての最も奇妙なことは、私がexternalアドレスからssh、nginxサーバーに問題なく接続できることです（例：sshを実行する元のコンピューターの場合）。

これは、ISPがサーバーを再起動した後に起こります。役に立つかもしれないことは、サーバーが再起動せずに頻繁に更新されたことです。

linuxnetworkingcentos
12
badray

投稿したifconfig出力によると、ループバックアドレス127.0.0.1 2つのインターフェイスに設定します。

試す

ip addr del 127.0.0.1/32 dev venet0

ループバックアクセスが復元されているかどうかを確認します。

5
Flup

あなたが説明しているのとまったく同じ問題がありました。ローカルからホストのリスニングポートに接続できませんでしたが、リモートの場合は接続できました。

私の解決策は、何らかの理由でダウンしていて起動時に起動しないloインターフェースをアップに戻すことでした。

ifconfig lo up

インターフェイスを元に戻し、loインターフェイスが表示されることを確認した後...

ifconfig -a

私は私の一日を始めることができました... :)

ip aを実行すると、lo：インターフェースに127.0.0.1が割り当てられていないことに気づきました。これは、そのインターフェイスも実行する必要があるという事実に私を導きました...

5
Philip

Flupは正解ですが、この質問には別の理由があることがわかりました。別の答えが必要だと思います。サーバー、私はIPv6ソケットへのバインドを開始しました。他のアドレスを使用して接続する必要があります。

nc ::1 8080

または

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