この記事では、端末がインターネット接続ができない場合のトラブルシュートの方法について記載しています。
問診とトラブルシューティングステップ
まずは、以下の問診に従って、発生の契機と影響範囲の特定を行います。
- 事象発生日時を確認。
- 継続して発生しているか。
- 継続していない場合、頻度の確認。
- 発生日時頃、周辺機器の設定変更の有無。
- 発生する端末は特定か、拠点全体か。
- 無線、有線どちらでも発生しているか。
- 宛先は特定のものか、すべての宛先か。
- 特定のアプリケーション通信のみ不可なのか、すべての通信が不可なのか。
- 対象にICMP は到達可能か。
設定変更があった場合、もとに戻した時に改善するかを確認する。
特定の端末や通信の場合、端末単位のグループポリシーの適用や経路上にファイアウォールの制限はないか確認する。
上記問診にて影響範囲が特定できない場合、実際のパケットをパケットキャプチャを行い確認します。
影響範囲が明確ではない場合、より端末に近いところからトラブルシュートを行います。
無線端末での事象でMeraki フルスタック構成の場合の例を示します。
- ローカルステータスページに接続して、接続しているMR を特定します。
- 事象発生端末にてパケットキャプチャを開始し、端末上から無線IF にパケットが送信されているか。
- ダッシュボードパケットキャプチャツールを活用し、同時にMR のWired（有線）でパケットキャプチャを取得して対象のクライアント、宛先の通信が確認できることを確認します。
宛先はFQDN で、IP アドレスが不明な場合、取得したパケットキャプチャのファイルを開きDNS パケットに含まれるドメイン名または、Client hello のパケットに含まれるサーバー名をフィルタして見つける。 - MR からアップストリームへ対象のパケットが送信されていることを確認できた場合、MX のファイアウォールロギングツールを用いてMX にてブロックされていないか確認する。※ツールは、18.2以降で利用可能。
- ファイアウォールロギングでブロックされていることが確認できない場合、MX のLAN とInternet で同時にパケットキャプチャを取得して、宛先への通信が含まれていることを確認します。
- MX のLAN で対象パケットが見られない場合は、MS のACL モニタリングツールを利用してブロックされていないか確認する。※ツールは、MS16以降で利用可能。
Wireshark DNS filter
| dns.qry.name contains "FQDN" |
| dns contains "FQDN" |
Wireshark TLS filter
| tls.handshake.extensions_server_name contains "FQDN" |
デモンストレーション
”https://www.deepl.com/” 宛の通信をブロックした時の確認方法についてデモンストレーションします。
まず、テストのためMX にてdeepl 宛の通信をブロックとして設定します。
クライアント端末から通信を発生させ、「セキュリティ&SD-WAN」>「監視」>アプライアンスステータス>ファイアウォールログ でブロックされていることを確認します。
本ツールのフィルタリング方法は、ドキュメントを参照する。
念のため、通信を発生させた時に、MX のLAN とInternet でパケットキャプチャを同時に取得し、TLS パケットを確認するとInternet ではそのパケットが見られず、期待通りに動作していることを確認します。
tls.handshake.extensions_server_name contains "deepl"
次に、対象のファイアウォールルールを削除し、アップストリームのRT で対象通信をフィルタリングし、通信を発生させ動作を確認します。
ファイアウォールロギングでは、許可されていること、Internet のパケットキャプチャでMX からアップストリームへパケットが転送されていることが確認できます。
この場合、MX よりアップストリームの問題の可能性が高いと考えられます。
