技術的な問題のトラブルシューティングが必要になった場合、その問題に関する正しい情報を手に入れることが極めて重要です。これには、エラーを再現する手順や問題の詳細が記録されたログだけでなく、問題を解決しようとして（成功しなかった）実行した手順も含まれます。とは言え、情報が多すぎて、問題とは関係ない情報も含まれている可能性もあるので、注意が必要です。情報が過剰であると、無関係の多くの事柄を理解するのに時間がかかり、集中して取り組むべき事柄が疎かになる恐れがあります。

このブログ記事では、ネットワークの問題をトラブルシューティングする際に実行できる手順を説明します。説明する概念の中には、他のシナリオにも適用できるものも含まれていますが、このトラブルシューティングガイドの主な対象は、ウォッチガードのファイアウォールアプライアンスが統合されているネットワークです。また、トラブルシューティングにあたって、ウォッチガードデバイスの管理インタフェースにアクセスでき、管理アクセスが可能なコンピュータがあることを前提にしています。

最初の手順

最初にやるべきは、一度立ち止まって気持ちを落ち着かせ、最も重要なのは、深呼吸することです。技術的な問題はさまざまであり、1 人のユーザだけが影響を受ける小規模で限定的なものからサイト全体の機能停止といった大規模のものまでの多岐に渡ります。技術担当者であれば、どのような状況においても、問題の解決にあたって大きなプレッシャーにさらされるでしょう。オンラインでの業務の場合が多いはずですが、平常心を失うと、論理的思考力が損なわれ、問題がさらに拡大する恐れがあります。

• わかりやすく一言で説明すると、どのような問題なのか
• 誰が影響を受けるのか、1 人の従業員なのか、あるいは複数のユーザなのか
• その問題を簡単に再現できるか
• どのような製品（電子デバイス）、オペレーティングシステム（OS）、バージョンが関係しているのか
• 過去に正常に動作していたことがあるのか

これらの質問の答えがわかれば、トラブルシューティングを進める上での大きな手掛かりになります。ネットワークの問題のトラブルシューティングの良いところは、さまざまな方法を使って問題を解決できる点にあります。

何ができないのかを確認する

よくある問題の一例として、VPN 経由でリソースにアクセスできないという苦情が寄せられたという状況を考えてみましょう。そのような場合は、先ず初めに、使用している OS とそのバージョンが何で、どのタイプの VPN を使用しているかを確認します。

新しい導入環境であった場合は、過去に正しく動作したことがないため、どこに問題があるのかを知る方法はありません。逆に、以前に正しく動作していたことがあって、今は動作しなくなってしまったのであれば、さらにいくつかの点を確認します。たとえば、オフィスにいる時、あるいは出張中のどちらの状況で問題が発生したのでしょうか。

この点を確認する必要があるのは、リモート接続の場合は、VPN 接続がウォッチガードアプライアンスの背後にあるオフィス環境とは異なるためです。ウォッチガードが提供しているリモート VPN ソフトウェアとして、Mac と Windows の両方で利用できる SSL VPN クライアントがありますし、同様にIPSec VPN クライアントも利用できます。サイト間 VPN（ウォッチガードの用語でブランチオフィス VPN）の場合は、この機能がアプライアンスに組み込まれているため、考慮すべき追加ソフトウェアはありません。

したがって、リモートの従業員向けにインストールされているソフトウェアクライアント、ウォッチガードアプライアンスそのもの、あるいは場合によってはリモートのエンドポイントのいずれかの問題であると考えられます。

リモートエンドの問題であるという結論を出す前に、アクセスできるものすべてのトラブルシューティングに取り組みます。他のユーザが同じ VPN を使って同じリソースにアクセスできるのかどうか調査すれば、ホストマシンの問題かどうかを判断できるはずです。リモートエンドで問題が発生しているユーザだけがブロックされている可能性もあるため、他のユーザが同じ VPN を使って想定通りにリソースにアクセスできるかどうか確認します。もちろん、さまざまな理由が考えられますが、こういったプロセスを続けながらトラブルシューティングを実行する必要があります。

リモートユーザのクライアントソフトウェアを再インストールしてみるのも、1 つの方法です。ユーザがローカルでアクセスしている場合、VPN アクセス以外のネットワークアクティビティをチェックすることで、通常のインターネットアクセスは可能なのか、VPN を使って他のリソースにアクセスできるのか、あるいは VPN の接続そのものが失敗しているのかといったことを確認します。

一般的なネットワークのチェック

ウォッチガードのサポート技術者であった頃に、ネットワークの問題を解決するために私自身がよく実行していた手順は、問題の特性によって異なるものでしたが、一般的には以下の手順を実行することで、アクセスが可能かどうかを確認できます。

• IP アドレスをチェックする
  Windows OS の場合は、コマンドプロンプトを開いて「ipconfig」コマンドを実行します。
  Mac/Linux の場合は、「ifconfig」または「ip addr」を使用します。
  表示された IP アドレスとネットワークがネットワーク管理者によって割り当てられたネットワークと一致していますか？パブリックに割り当てられておらず、APIPA（169.254.x.x/16）の一部ではないにもかかわらず、有効となっている IP はありませんか？
• リモートエンドに ping できるか？
  ほとんどの OS は、「ping x.x.x.x」を受け付けるため、リモートエンドに到達できるかどうかを確認できます。
• 自分のホストからアクセスしようとしている他のホストに traceroute できるか？
  ・Windows の場合は、「tracert x.x.x.x」を使用します
  ・Mac/Linux の場合は、「traceroute x.x.x.x」を使用する必要があります
  この手順は、ホストマシンが IP を使ってターゲットマシンにアクセスできることを確認するのに役立ちます。マシンのソフトウェアの問題、あるいはマシンの不具合のどちらなのでしょうか？ping でリモートホストにアクセスできない場合は、次の手順として、ネットワークパスに注目します。
• 中間ネットワーキングデバイスがネットワークトラバーサルを妨げていないか確認する
  たとえば、VLAN スイッチや、正しく構成されていれば何の問題もなく動作する「スマート」デバイスが、ネットワークトラフィックに影響する可能性があります。
• パケットキャプチャを取得する
  パケットキャプチャは、使用する引数に従ってトラフィックログを提供するため、多少の技術的なノウハウが必要ですが、トラブルシューティングに役に立つことがあります（ウォッチガードの場合）。

ウォッチガードファイアウォールの管理インタフェースにログインできないというお問い合わせがお客様から寄せられることも多いのですが、これは間違いなく、かなり深刻な問題です。その点を考慮して、先ず初めに、デバイスの管理 IP アドレスに ping して、応答があるか確認します。

応答がない場合、問題の原因になっている可能性のある中間デバイスがないかtraceroute でチェックします。ダイレクト接続は中間デバイスを排除する方法として適当ですか？

ウォッチガードの構成

上記の手順はウォッチガード以外のネットワークでも使用できる一般的なものですが、それ以外に、アプライアンスそのものの単純な構成ミスである可能性もあります。ここで重要なのは、パケットフィルタあるいはポリシー、さらには、ポリシーの上位にスタックして利用できる、IPS、GAV、APT などのサービスが存在するということです。

パケットフィルタがチェックするのは、送信元の IP アドレスとポート、送信先の IP アドレスとポートだけですが、プロキシポリシーはこれらのチェックに加えて、（オプション）はるかに多くの処理を実行します。そのため、問題がある場合は、プロキシポリシーの構成ミスが原因であると考えられます。プロキシは、OSI モデルの上位の層のネットワークトラフィックに対して、集中的なインスペクションを実行する場合があります（HTTP インスペクションなど）。

リモートエンドがボットネットの一部になっていて、そのサービスによってアクセスが妨害されている可能性があります。また、会社のポリシーでアクセスを禁止する地域が構成されており、取引先である会社のサーバがその地域に置かれている場合もあります。あるいは、より一般的な例として、WebBlocker のルールで特定のカテゴリへのアクセスが禁止されている可能性があります。

ウォッチガード固有の問題の場合、サポートケースの申請前の最初の手順として、全アクセスを許可する簡単なパケットフィルタを作成することをお奨めします。パケットフィルタを構成して、管理者である自分だけがアクセスできる既知のホストを「From」に指定し、「To」を「Any」にすることで、ファイアウォールがすべてのトラフィックを受け入れるようにします。最後に、このポリシーを先頭に登録することで、「From」ホストが最初にこのポリシーで評価されるようにします。これがうまく場合は、構成の問題である可能性があり、うまくいかない場合は、リモートホストの問題である可能性があります。

まとめ

問題が発生する環境は同じではないため、この記事の内容は、あらゆる状況に対応するものではありません。しかしながら、ここで説明した手順は、ウォッチガードだけでなく、他のベンダのサポートにトラブルシューティングを依頼する場合も役に立つはずです。ネットワークやその他のあらゆる要素を最も理解しているのは、その環境の実際の管理者であるため、管理者ができる作業が多いほど、ベンダの技術者に提供できるデータも多くなります。

上記の手順以外に、WatchGuard Traffic Monitor でもパケットキャプチャとほとんど同じ情報を入手することができ、引数を使用する必要はありません。また、グラフィック表示であるため、ユーザフレンドリであるという利点があり、トラブルシューティングをさらに進めて問題を自己解決する際に役立つ資料がカテゴリ別に提供されています。

サポートケースを申請する必要がある場合は、それまでに実行した手順、関連するスクリーンショット、パケットキャプチャを忘れずに含めてください。どのベンダのサポート契約でも、これらの情報が重要になりますが、ウォッチガードのサポートチームは、これらの情報に基づき、お客様の問題の解決を全面的に支援させていただきます。