- - PR -
プロキシサーバー(Squid)が、接続できなくなる。
1
投稿者 | 投稿内容 |
---|---|
|
投稿日時: 2008-09-30 17:58
【悩んでいる事】
納品したサーバーのプロキシサーバーで、悩んでいます。 CentOS 5.2上で動作させているプロキシサーバー(Squid)が、 時々正常に動作しなくなっている現象を「調査する方法」と 「解決する方法」のヒントが欲しくて投稿しました。 【現象】 ・クライアントPCのブラウザで、時々サイトに接続できないか、 表示するまでの速度が著しく遅くなる。 ・遅くなる時は、サイトに接続をしているクライアントPCが 多い時とは、限らない。 ・サーバー上で「netstat -n」を使ってTCP接続を表示すると、 遅くなる時は、「State」が「SYN_SENT」の接続が多くなり、 「SYN_SENT」がなくなると、正常の表示速度に戻る。 tcp 0 0 xxx.xxx.xxx.xxx:34264 yyy.yyy.yyy.yyy:80 SYN_SENT tcp 0 0 xxx.xxx.xxx.xxx:59493 yyy.yyy.yyy.yyy:80 SYN_SENT tcp 0 0 xxx.xxx.xxx.xxx:43904 yyy.yyy.yyy.yyy:80 SYN_SENT ※「xxx.xxx.xxx.xxx」は、サーバー1のIPアドレス ※「yyy.yyy.yyy.yyy」は、接続先サイトのIPアドレス 【機械、ソフト】 CPU:デュアルコア インテルXeon 3065 (2.33GHz,1x4MB L2, 1333MHz FSB) MEM:2GB×2 HDD:160GB NIC:NC326i PCI Express Gigabit(オンボード) NIC: OS :CentOS 5.2(64bit) カーネル:2.6.18-92.el5 DNS:bind-9.3.4-6.0.2.P1.el5_2 Proxy:squid-2.6.STABLE6-5.el5_1.3 ※「bind」「squid」は、OSインストール時にインストール。 ※ OSインストール後、カーネルのバージョンアップは、行っていない。 【ネットワーク構成】 インターネット | | ルーター | | FW製品(SonicWall) | | サーバー1(DNS、Proxy、Gateway) | ++++++++++++++++++++++++++++ クライアントPC(約200台)、および社内サーバー(Active Directoy) 【設定】 ルーター: 外から内の通信のみポート制限 内から外の通信は無制限 FW製品: 設定内容が不明 サーバー1: DNS(bindで外向けDNS) Proxy(社内ネットワークからのみ接続可能) Gateway(iptablesでIPマスカレードを設定) 社内サーバー: Active Directry DHCPサーバー 社内ネットワーク以外の名前解決を「サーバー1」に指定 クライアントPC: ブラウザでプロキシサーバーに「サーバー1」を指定 Gatewayに「サーバー1」を指定 DNSに「社内サーバー」を指定 サーバー1での「iptables -L -t nat」の結果: Chain PREROUTING (policy ACCEPT) target prot opt source destination Chain POSTROUTING (policy ACCEPT) target prot opt source destination MASQUERADE all -- 192.168.100.0/24 anywhere Chain OUTPUT (policy ACCEPT) target prot opt source destination 【解決案】 まだ試していませんが、自分で調べた解決案は、次の3つです。 ・MTU を小さくする。 ・「/proc/sys/net/ipv4/tcp_window_scaling」を「0」にする。 ・カーネルをバージョンアップする。 サーバーは、運用中で遠隔地にあるため、解決案を多くもって、 作業に行きたい、と思っています。 何か、心当たりがある方、よろしくお願いします。 |
|
投稿日時: 2008-09-30 18:44
取り敢えず、障害が発生している時の、/var/log/squid 以下のaccess.log等を確認してみてください。
|
|
投稿日時: 2008-10-01 01:48
原因が分からなければ解決方法も分からないわけで、
いろんな対処を片っ端から実施すれば、 どれかは当たるかもしれませんが...。 とりあえず、squidのログから傾向をつかんでみては? ・接続できない事象はどの程度発生しているか? 1日数回ランダムで毎日とか、丁度1時間おき毎日とか、だいたい朝一と昼休みに起こるとか、 何日かに一回ある位とか... ・必ずある特定のサイトに接続に行こうとした後に現象が発生するとかはないか? ・事象が発生している時の処理時間はリクエスト毎にばらつきがあるか? ・事象が発生している時のresult codeの傾向は? ほとんどのリクエストに対して503が帰ってるとか、他のも結構混じってるとか... ・上にあるようなことが、「接続できない」と言われている時だけに見られるか、 通常時にも見られるのか? 頻繁に行ける所でないのであれば、 お客様に事情を説明したうえで許可をもらい、 ある程度の期間分のsquidのログを持ち帰らせていただき、 帰ってからじっくり分析してみては? ルータで、回線のトラフィックデータを取ってないでしょうか。 事象が発生した時のトラフィックは? ・該当の時間帯は帯域を全部使ってる ・普段と変わらず ・普段はそれなりにあるのに、接続不可の時間だけは限りなくゼロに近い とかの傾向は分りませんか? ステータスがSYN_SENTということは、相手からのSYN,ACK待ちということで、 もっとも疑ってみる所が、 > FW製品: > 設定内容が不明 こういう状態なので、なかなか難しいですね。他社が導入したものですか? 「こういう現象が起こっているんだけど、 SonicWall的に何か関係するところはありますか」 と、導入ベンダーに聞いてみるとかはできないのでしょうか。 サーバ1⇔Firewall間とFirewall⇔ルータ間の2ヶ所で同時にパケットキャプチャ仕掛けて、 結果を突き合わせてみればわかるかもしれませんが、実現は難しいですよね。 |
|
投稿日時: 2008-10-02 11:11
非武装エリア 様
akasaka 様 ご回答ありがとうございます。 >・接続できない事象はどの程度発生しているか? 数分に1回の時や、10分20分起きないときもあります。 なので現在は、旧プロキシサーバーで運用してもらっています。 >・必ずある特定のサイトに接続に行こうとした後に現象が発生するとかはないか? 現象が起きた時に、サーバー1で netstat で監視 していましたが、「特定のサイト」の時に起きる訳では ないようです。 >・事象が発生している時の処理時間はリクエスト毎にばらつきがあるか? 社員の方がいる時間(9時〜18時くらい)に発生し、 退勤時間が過ぎると、発生しなくなります。 ただ、退勤時間以降は、遅くまで作業できないので 情報として正しくないかもしれません。 >・事象が発生している時のresult codeの傾向は? >ほとんどのリクエストに対して503が帰ってるとか、他のも結構混じってるとか... IE で言う、「ページがありません」になる時と 長い時間かかって表示できる時が、あります。 >・上にあるようなことが、「接続できない」と言われている時だけに見られるか、 >通常時にも見られるのか? これは、注意して監視していなかったので、 次回、注意して確認します。 あと、現象が起きた時のサーバー1のリソースは、 CPU、MEM、ネットワークトラフィックとも通常時と 変化がありません(どれも20%〜30%の消費)。 アドバイスを読んで、次の事から始める事にしました。 ------------------------------------------------------ 1) ルーター、FWの製品名を教えてもらい(若しくは調査し)、 事前に、ログ(トラフィックデータ、破棄データ)確認方法、 設定内容確認方法を調べて、そのログを見れれば確認する。 2) 現地に行って、追い現象が起きた時の時刻を記録し Squid のログを持ち帰る。 3) 通常時(現象が起きていない時)に、「SYN_SENT」が 起きていないか確認する。 ------------------------------------------------------ |
|
投稿日時: 2008-10-08 14:40
「悩んでいたこと」が解決したので、一応、原因と対応方法を
書いておきます。 【原因】 クライアントPCの1台で動作していたい「S*ftEth*r」が 2〜3秒に1度「keepalive.s*fteth*r.com」宛に、IP プロトコルのパケットを「サーバー1」経由で送信していた。 「サーバー1」は、受け取ったパケットの送信元IPアドレスを 「サーバー1」のグローバルIPアドレスに変換して、 「ルーター」経由で、「keepalive.s*fteth*r.com」宛に 送信したため、「ルーター」が「サーバー1」からの 攻撃だと判断し、一定時間「サーバー1」からの送信を 遮断していた。 【調査方法】 1) 「ルーター」のログの中で、攻撃で遮断したログを見た時に <「サーバー1」から「keepalive.s*fteth*r.com」宛の パケットを「SYN Attack」攻撃と判断した>ログが見つかった。 2) 「サーバー1」で、tcpdump の結果をファイルに出力し、 「keepalive.s*fteth*r.com」に送信しているパケットを確認した。 その結果、一定のクライアントPCのIPアドレスから 「keepalive.s*fteth*r.com」に2〜3秒に一回送信している パケットが見つかった。 3) そのクライアントPCのネットワークの設定画面を見て 「仮想ネットワーク」が設定されている事を確認した。 4) そのクライアントPCで「So*nd Po*tal」と言う製品が インストールされている事を確認した。 あるサイトで、 この「So*nd Po*tal」をインストールすると、 「S*ftEth*r」がインストールされ、「S*ftEth*r」が デフォルトの設定で「keepalive.s*fteth*r.com」に 2〜3秒に一回送信する様に設定されている事を確認した。 【対処方法】 そのクライアントPCから、「So*nd Po*tal」を削除し 「仮想ネットワーク」も削除した。 【疑問点】 問題は、解決したのですが、1点だけ疑問点が残りました。 「サーバー1」を導入する前(「サーバー1」と同じ機能を 果たしていたWindows サーバーが稼動していた)では、 なぜ、今回の現象が起きなかったのか、です。 (お客さんからは、その疑問を突っ込まれなかったので、 調査しなくて、済みました) 皆さんありがとうございました。 |
|
投稿日時: 2008-10-09 04:04
解決されたとのことで、何よりです。
> 「サーバー1」を導入する前(「サーバー1」と同じ機能を > 果たしていたWindows サーバーが稼動していた)では、 > なぜ、今回の現象が起きなかったのか、です。 可能性としてはいろいろあると思います。 ・たまたま、そのクライアントPCに問題のアプリをインストールしたのが プロキシサーバの納品時期と同じだった。 ・前のプロキシサーバの時には、S*ftEth*rのパケットはそのプロキシサーバを 超えれていなかった。 (プロキシサーバが中継出来ていなかった。) ・実は前のプロキシサーバでも起きていた。 が、プロキシサーバがボロいせいだと思っていた。 ・実は前のプロキシサーバでも起きていた。 原因が分からなかったので、プロキシサーバをリプレースした。 それでも発生したので、新プロキシサーバのせいにした。 すいません、後半の2つは冗談です。 ...というのは置いといて、 前のプロキシサーバと今のプロキシサーバの、 SSL時のKeepAlive処理の違いですかね。 |
1