HTTPSを提供しているWindowsのWebサーバに対して、同じセグメントの別のサーバからpingは応答があるが、Webサイトが閲覧できない現象が発生しました。この時具体的にどのようにして切り分けをしたのかお伝えします。
今回のネットワーク構成
まず、今回のサーバ環境のネットワーク構成を提示します。
- Linux監視サーバからWindows Webサーバへはpingが導通している。
- Linux監視サーバからWindows WebサーバのHTTPSにアクセスができない。（ココが問題）
- Widowsクライアントから、WebサーバのHTTPSにアクセス可能。
- 他にも名前解決が出来ているか等の条件がありますが、簡素化するため、割愛します。
Windowsサーバ側のFWの設定を確認
Windows Firewallの設定を確認しました。一通り目視で設定を確認しましたが特におかしなところは見当たりませんでした。次に、Windows FWのログを出力する設定を行いました。プライベート、ドメイン、パブリックの3つのルールについて、すべてのアクセス拒否ログを有効にしました。また念のため、通過したログも記録するように設定しました。この状態で、Webサーバにアクセスしました。
結果、Windowsクライアントのアクセスは、ログに記録がされるものの、Linux監視サーバからのアクセスはログには記録されませんでした。もちろん、ブラウザにWebコンテンツも表示はさせませんでした。（Windowsクライアントはちゃんと閲覧可能）
なお、pingのログは、Linux監視サーバ、Windowsクライアントともに記録されることを確認しております。
Windowsサーバ側のウィルスソフトを確認
次にウィルスソフトを疑いました。一旦ウィルスソフトを無効化して、再度試してみましたが、結果は変わりませんでした。
tcpdumpによるパケットキャプチャを実施
Linux監視サーバにて、tcpdumpによるパケットをキャプチャしました。
まず、pingの結果をモニタリングしました。具体的なコマンドは以下になります。
# tcpdump -i eth0 host 192.168.0.3こちらを実施した状態で、Linux監視サーバからWindows Webサーバへpingを打ってみました。結果、双方のサーバからパケットがやり取りされていることが確認できました。
次に、Linux監視サーバからWindows Webサーバへtelnet で443でアクセスしてみました。
# telnet 192.168.0.3 443すると、tcpdumpの結果は、Linux監視サーバからWindows Webサーバへ一方通行で、これはからの応答が記録されていない事がわかりました。これよりWebサーバ側から何らかの要因でパケットを返せていない事がわかります。
windows標準のパケットキャプチャ（調べたけれど実施していない）
windows側でもパケットキャプチャを実行したかったのですが、運用中のサーバにWiresharkをインストールするのも気が引けました。そこでWindows標準のパケットキャプチャがないか調べたところ、ありました！Windows Server 2008 R2以降であれば、標準で使用できるようです。
具体的には、キャプチャーを開始するには、
netsh trace start capture=yesキャプチャーを終了するには、
netsh trace stopという感じで、netshコマンドを使用してパケットキャプチャが可能です。
今回は実施していないのですが、また機会があれば試してみたいと思います。
tracerouteを双方のサーバで実施
まずはLinuxサーバ側で、
# traceroute 192.168.0.3を実行。結果は特に問題はありませんでした。
次に、Windows Webサーバ側で、
# tracert 192.168.0.2を実行。すると、なぜか、デフォルトゲートウェイ（192.168.0.1）に一旦送付してから、Linux監視サーバに戻ってきていることが記録されていました。同じセグメントですので、デフォルトゲートウェイに行くのはおかしいとここで気が付きました。
根本の原因は、スタティックルートの設定だった
提示が遅くなりましたが、今回の原因は、なぜか192.168.0.0/24のセグメントに対して、スタティックルートの設定がされていたことになります。（宛先は、デフォルトゲートウェイ）
IPアドレスを割り当てたセグメントに対しては、通常はスタティックルートの設定をする必要は無く、そのままで通信は可能です。（同じセグメントなので。ネットマスクが合っている前提）
今回のように通常はありもしない設定が追加されていることで、切り分けに大変時間がかかりました。また、設定をよく確認することの重要さを改めて知らされました。
route deleteコマンドの注意点
不要なスタティックルートの設定があったので、削除するためにroute deleteコマンドを実行しました。route printコマンドで状況を確認すると、削除されていたので、動作確認をしましたが、やはり接続ができないままでした。
再起動後も有効になる「-p」オプションを付与して再度コマンドを実行し、確認しましたが、やはり変わりませんでした。
もしこの状態から切り分けする場合、迷宮入りですね。だって、不要なスタティックは表示されていないし、通信もできないとなり、もうどうしたら良いか不明です。
私の場合、「-p」オプションを付与したあと、OSを再起動しました。すると、OS再起動後にやっと同セグメントのサーバにhttpsで接続ができるようになりました！
どうしようもなく途方に暮れてしまった場合は、OSを一度再起動してみる、ということも試してく見てください。今回のように設定は入っていないように見えるけれども、有効になっていない可能性があります。
pingはOKなのに、httpsはダメな理由
最後に不要なスタティックルートの設定がある状態で、pingはOKなのに、httpsはダメな理由を記載しておきます。これは、ping=ICMPやUDPの通信については、パケットの出所をそこまで厳密に管理しておらず、Linux監視サーバ → Windows Webサーバ → デフォルトゲートウェイ → Linux監視サーバ となっても問題なく通信できておりました。
しかしながら、TCPについてはそうはいかず、Linux監視サーバ → Windows Webサーバ → デフォルトゲートウェイ といったときに、デフォルトゲートウェイとしてはいきなりTCPの途中からの通信が始まることになり、通信はそこで終了します。もし仮に、Linux監視サーバに転送したとしても、Windows Webサーバに送ったパケットが、なぜかデフォルトゲートウェイから帰ってくるという、行きと戻りで経路が変わるので、通信は成立しないとなります。
今回はここまです。最後までお読みいただきありがとうございました。