web-dev-qa-db-ja.com

127.0.0.1にバインドされたサービスに接続できません

いくつかのWebアプリケーションを実行しているDebianwheezyサーバー、MongoDBデータベース、およびNGinxサーバーの背後にあるRedisサーバーがあります。 NGinxサーバーのみが公開されており、他のサービスはその背後で逆プロキシされます。このセットアップは、サーバーが配置されているデータセンターで一時的な停電が発生した2日前まで完全に機能していました。再起動してクラッシュ後の定期的なメンテナンス（ロックファイルの削除、DBの修復など）を行った後、NGinxがプロキシするすべてのサービスでタイムアウトしていることに気付きました。問題を解決するために私が取った手順は次のとおりです。

  1. ログの確認
    すべてのサービスのログを確認しましたが、すべてがエラーなしでクリーンです（NGinxがアップストリーム接続のタイムアウトを報告する以外）。

  2. サービスが実行されていることを確認します
    WSGIアプリケーション、MongoDBなどのすべてのプロセスが実行されており、netstatも確認しました。

    # netstat -ntple
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       User       Inode       PID/Program name
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      0          21730537    1469/nginx      
tcp        0      0 0.0.0.0:2525            0.0.0.0:*               LISTEN      1000       21730714    1511/python     
tcp        0      0 0.0.0.0:9090            0.0.0.0:*               LISTEN      1000       21730931    1627/python     
tcp        0      0 0.0.0.0:2022            0.0.0.0:*               LISTEN      0          21730651    1553/sshd       
tcp        0      0 0.0.0.0:9000            0.0.0.0:*               LISTEN      1000       21730885    1624/python     
tcp        0      0 127.0.0.1:27017         0.0.0.0:*               LISTEN      104        21730531    1376/mongod     
tcp        0      0 0.0.0.0:6379            0.0.0.0:*               LISTEN      105        21730621    1532/redis-server *
tcp        0      0 0.0.0.0:8080            0.0.0.0:*               LISTEN      1000       21730731    1500/python     
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      0          21730536    1469/nginx      
tcp6       0      0 :::2022                 :::*                    LISTEN      0          21730654    1553/sshd       
tcp6       0      0 :::6379                 :::*                    LISTEN      105        21730619    1532/redis-server *

  3. ループバックインターフェイスとping 127.0.0.1を確認します
    ループバックインターフェイスは/etc/network/interfacesで適切に設定されており、ifconfigはそれが起動して実行されていることを報告します。 127.0.0.1とlocalhostに問題なくpingを実行することもできます。

  4. ファイアウォールを無効にする
    ファイアウォールを無効にしても状況は変わりませんでした。接続はまだタイムアウトしています。

  5. telnet経由で接続してみてください
    サービスの1つにtelnetで接続しようとしましたが、奇妙なパターンに気づきました。

    # telnet 127.0.0.1 6379
Trying 127.0.0.1...
telnet: Unable to connect to remote Host: Connection timed out

# telnet ::1 6379
Trying ::1...
Connected to ::1.
Escape character is '^]'.

IPv4経由でサービス（この例ではRedis）に接続しようとするとタイムアウトしますが、IPv6経由で接続しようとするとすぐに接続します。このタイプの動作を引き起こす可能性のあるIPv4接続に関連するファイルはありますか？サーバーのイメージを再作成せずにこれを修正する方法はありますか？

更新

SYNの回答を読んだ後、同じサービス（上記を参照）に接続しようとしましたが、代わりにサーバーのパブリックIPを使用しました（ただし、サーバーの内部から）。すぐに接続します。私の理解では、任意のインターフェイスで接続を受け入れる0.0.0.0をリッスンするため、機能します。ただし、127.0.0.1からの接続は引き続き機能せず、127.0.0.1を特にリッスンするサービスへの接続も機能しません。私の結論は、ループバックインターフェイス（IPv4上）に実際に問題があるということです。 ifconfigからの出力は次のとおりです。

# ifconfig
lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:7984 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7984 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:711801 (695.1 KiB)  TX bytes:711801 (695.1 KiB)

venet0    Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:127.0.0.2  P-t-P:127.0.0.2  Bcast:0.0.0.0  Mask:255.255.255.255
          UP BROADCAST POINTOPOINT RUNNING NOARP  MTU:1500  Metric:1
          RX packets:35812 errors:0 dropped:0 overruns:0 frame:0
          TX packets:47530 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:2568793 (2.4 MiB)  TX bytes:34332070 (32.7 MiB)

venet0:0  Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:*public ip*  P-t-P:*public ip*  Bcast:*public ip*  Mask:255.255.255.255
          UP BROADCAST POINTOPOINT RUNNING NOARP  MTU:1500  Metric:1

そこから、ループバックインターフェイスの誤動作を説明する何かがありますか？このインターフェイスで発生している問題を説明したり、修正したりする可能性のある、見落とした別のログファイルまたは構成ファイルはありますか？

アップデート2

私のサーバーがOpenVZのVPSであることを追加するためのクイックアップデート。私の（継続的な）Google検索から、OpenVZは他のプラットフォームとは少し異なるネットワーキングを行うことがわかったので、ここにその情報を含めて、正しい方向に導く可能性があります。しかし、私が見たところ、私のようなリモートで問題を抱えている人は誰も解決策を見つけていないようです...（例： この投稿 Unix＆Linux StackExchangeから）。

linuxnetworkingdebianopenvz
1
J-F Desrochers

IPv4でredisに接続できると思います。 redisが127.0.0.1:6379をリッスンしない限り、ローカルホストに接続（またはtelnet）することはできません。

IPv6に精通していないため、IPv6が機能する理由を説明できません。

繰り返しになりますが、nginxがトラフィックをredisにプロキシすることは疑わしいです。どの仮想ホストが有効になっているかを教えていただけますか？ pythonプロセスが0.0.0.0をリッスンするのは正常ですか？そうであれば、無効にしたファイアウォールルールを有効に戻す必要があります。

更新、OPの更新を読む：

あなたが何かを見つけたのを見てうれしいです。その間、ローカルホストへの接続に関する私の最初の発言はまったく間違っていました、お詫びします。

1
SYN