L3スイッチがWindowsファイル共有をブロック

作成日： 2012年9月15日
更新日：（なし）

Windowsファイル共有ができません

あるサーバー間でWindowsのファイル共有ができませんでした。原因はタイトルの通りです。 L3スイッチのパケット・フィルタリング（Firewallみたいなもの）がファイル共有のポートを塞いでいました。分かってみると一番あり得る原因ですが、一見したところでは分かりませんでした。サーバー間でpingやhttpなどの他の通信ができていたり、同じセグメントにある別のサーバーからはファイル共有できていたりしたことが原因を直感的に見え難くしていました。

サーバーは2台ともWindows Server 2003 R2（SP2適用済み）です。 Windows Server 2012が発売されたので、2世代前の古い環境での話となります。

ファイル共有の操作は画像にあるように「ファイル名指定して実行」から相手先サーバーのIPアドレスを指定して行いました。共有先は管理共有がかかっている「Cドライブ」です。

実行すると、エラーのポップアップが表示されました。正常ならユーザー認証画面か、認証済みであれば共有フォルダが表示されるところです。

エラーのメッセージは「指定されたネットワークパスはどのネットワークプロバイダによっても受け付けられませんでした。」です。相変わらず意味不明です。原因が分かってから無理矢理想像を膨らませれば何とか繋げられなくはありません。ただそうだとしても、伝わらなければ価値はないので、もう少しエラー対応に有用なメッセージにして欲しいです。

パケット・キャプチャー結果

両サーバー上のネットワーク設定を調べましたが、おかしなところは見当たりません。デフォルト・ゲートウェイや静的経路、ファイル共有の設定も間違いはありません。インターフェースの「Microsoft ネットワーク用ファイルとプリンタ共有」もオンになっています。こういう場合、やることは昔から決まっています。男は黙ってパケット・キャプチャーです。

最初のキャプチャー結果は「ファイル名指定して実行」を行ったサーバーのものです。便宜上、こちらのサーバーを毛沢東と呼んでおきます。通信先はスターリンとしておきます。

WireSharkではスターリン（通信先）のIPアドレスでフィルターをかけて表示させています。スターリンのIPアドレスは「～.43」です。従って、「Source」に出るIPアドレスが毛沢東のもの、「Destination」に出るのがスターリンのものです。

「Source」には「～.224」と「～.38」というIPアドレスが出ています。毛沢東はマルチホーム構成で、2つのNICに各1つずつのIPアドレスを持つ設定になっています。スターリンと通信させたいのは「～.224」のIPアドレスです。デフォルト・ゲートウェイは「～.38」側に設定していますが、静的経路を設定してスターリンとは「～.224」側で通信するようにしています。 tracerouteで意図した通り「～.224」を使ってスターリンと通信していることを確認しています。

「Info」でパケットの活動が分かります。これを見ると、毛沢東からスターリン（「～.43」）へ「SYN」パケットを送信しているものの、スターリンから「SYN,ACK」パケットが返ってきていません。これはおかしいです。中ソ対立状態です。

話は逸れますが、毛沢東は初めにスターリンの445番ポートに対して接続を試みています。 445番ポートと繋がらなかったので、その後に139番ポートを試しています。悪名高い445番ポートと139番ポートですが、両者の使い方はWindows Server 2003の仕様通りです。あと、毛沢東はスターリンと「～.224」側で通信するように静的経路を設定しています。それなのに、「～.38」側からも無駄なパケットを出しています。それがRFCの仕様なのかWindowsがアホだからかは分かりません（私は後者だと思っていますが）。

次のキャプチャー結果はスターリンのものです。スターリンの表示も通信先の毛沢東のIPアドレス（「～.224」でフィルターをかけています。

毛沢東との決定的な違いはスターリンが毛沢東のパケットを受信していることです。「Source」に毛沢東の「～.224」というIPアドレスが出てきているのはそのためです。「Info」を見ると、スターリンは毛沢東からの「SYN」パケットを受信後、毛沢東へ「SYN,ACK」パケットを送信しています。その後、毛沢東から「ACK」パケットが届けば3ウェイ・ハンドシェイクの成立です。しかし、スターリンには毛沢東からの「ACK」パケットが返ってきていません。

両者のキャプチャー結果を見合わせて、スターリンから毛沢東への「SYN,ACK」パケットが届かないという現象には悩みました。スターリンは毛沢東からの「SYN」パケットを受信できているのに、毛沢東はスターリンからの「SYN,ACK」を受信できていません。毛沢東はスターリンへ自分から「SYN」パケットを送信しているにも関わらずです。こういう場合もやることは昔から決まっています。ネットワーク管理者にご相談です。

L3スイッチのパケット・フィルタリング

ネットワーク管理者に毛沢東とスターリン間の経路を調べて貰いました。そこでL3スイッチのパケット・フィルタリングがWindowsファイル共有の通信をブロックしていたことが分かりました。

数年前にWindowsファイル共有の脆弱性を狙ったウイルスの蔓延があり、その対応で445番や139番といったWindowsファイル共有で使われるポートの通信をL3スイッチでブロックさせているということでした。申請すれば解除してくれるそうで、同じセグメントにあってファイル共有ができていた別のサーバーでは誰かが過去に申請していたようでした。

また、L3スイッチでフィルタリングしているのはWindowsファイル共有の通信だけなので、pingやtracerouteなどのICMPやhttpなどの通信は行えていたのでした。

しかし、分かりに難いのが毛沢東からスターリンへの「SYN」パケットだけを通していることです。行きは通しても帰りは通さないという非対称な動作をしています。この設定について説明して貰いましたが、得心できるようなものではなかったので内容を忘れてしまいました。

その後、申請をしてL3スイッチのフィルタリングを解除すると、毛沢東からスターリンの共有フォルダを開くことができました。中ソ和解です。さしずめ今回のL3スイッチはCIAというところでしょうか。この件では環境によってはL3スイッチのような中間ノードが行き帰り（アウトバウンド・インバウンド）の通信を対称でブロックしていないケースがあるということを学びました。

更新履歴

更新日	更新内容
2012年9月15日	新規作成