Smart Assist ネットワーク技術者育成テキスト
EN

第10章 トラブルシューティング実践

PowerShell

PowerShell

Wireshark

Wireshark（パケット解析）

OpenSSL

OpenSSL

10.1 ping

pingとは

pingは、対象ホストとのネットワーク疎通を確認する最も基本的なコマンドである。ICMP（Internet Control Message Protocol）を使用して、パケットが相手に到達し応答が返ってくるかを確認する。

基本的な使い方

# IPアドレスを指定
ping 192.168.20.10

# ホスト名を指定
ping lis-server.hospital.local

実行結果の読み方

ping 192.168.20.10

Reply from 192.168.20.10: bytes=32 time=1ms TTL=128    ← 応答あり（疎通OK）
Reply from 192.168.20.10: bytes=32 time=1ms TTL=128
Reply from 192.168.20.10: bytes=32 time=1ms TTL=128
Reply from 192.168.20.10: bytes=32 time=1ms TTL=128

Ping statistics for 192.168.20.10:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss)
    Approximate round trip times in milli-seconds:
    Minimum = 1ms, Maximum = 1ms, Average = 1ms

応答がない場合

ping 192.168.20.99

Request timed out.    ← 応答なし
Request timed out.
Request timed out.

Smart Assistでのping活用

確認対象コマンド目的
LISサーバping 192.168.20.10院内のLISサーバとの疎通確認
デフォルトゲートウェイping 192.168.10.1ルーターとの疎通確認
DNSサーバping 192.168.1.53DNSサーバとの疎通確認
外部ホストping 8.8.8.8インターネットへの疎通確認

注意事項

  • ICMPがファイアウォールでブロックされている場合、pingが失敗しても実際のHTTPS通信は可能な場合がある
  • pingの成功は「IPレベルの疎通」を確認するもので、アプリケーション層の通信を保証するものではない
pingが通らなくても慌てるな

現場で「pingが通りません！」と焦る人、めちゃくちゃ多いです。でも落ち着いて。病院のFWはICMPをブロックしていることが多い。特にインターネット向けのpingはほぼ通らないと思ってください。

pingが通らなくても、HTTPS通信は問題なく動くケースがほとんど。だから、外部向けの疎通確認はpingではなく Test-NetConnection -Port 443 か curl -v を使うこと。「pingが通らない」で止まらず、次のステップに進む判断力が大事です。

10.2 nslookup

nslookupとは

nslookupは、DNSの名前解決を確認するコマンドである。FQDNからIPアドレスへの変換が正しく行われているかを調べる。

基本的な使い方

# FQDNのIPアドレスを調べる
nslookup smartassist.example.com

実行結果の読み方

nslookup smartassist.example.com

Server:     192.168.1.53          ← 問い合わせ先のDNSサーバ
Address:    192.168.1.53#53

Non-authoritative answer:
Name:       smartassist.example.com
Address:    52.194.10.20          ← 解決されたIPアドレス

名前解決が失敗する場合

nslookup smartassist.example.com

Server:     192.168.1.53
Address:    192.168.1.53#53

** server can't find smartassist.example.com: NXDOMAIN    ← 解決失敗

DNSサーバを指定して問い合わせ

# 特定のDNSサーバを指定
nslookup smartassist.example.com 8.8.8.8

院内DNSで失敗するが、外部DNS（8.8.8.8）で成功する場合、院内DNSの設定（フォワーダ等）に問題がある可能性が高い。

Smart Assistでの活用

確認項目コマンド判断
宛先FQDNの解決nslookup smartassist.example.comIPが返ればDNSは正常
院内DNSの動作確認nslookup smartassist.example.com 院内DNS_IP院内DNSで解決できるか
外部DNSでの確認nslookup smartassist.example.com 8.8.8.8院内DNS問題の切り分け

10.3 curl

curlとは

curlは、URLを指定してHTTP/HTTPS通信を行うコマンドラインツールである。実際のHTTPS通信を模擬して接続テストを行える。

基本的な使い方

# HTTPS接続テスト
curl -v https://smartassist.example.com/health

# プロキシ経由での接続テスト
curl -v --proxy http://proxy.hospital.local:8080 https://smartassist.example.com/health

実行結果の読み方（成功例）

curl -v https://smartassist.example.com/health

* Trying 52.194.10.20:443...
* Connected to smartassist.example.com (52.194.10.20) port 443    ← TCP接続成功
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256     ← TLS成功
* Server certificate:
*   subject: CN=smartassist.example.com                            ← 証明書確認
*   issuer: C=US, O=Amazon, CN=Amazon RSA 2048 M01
*   expire date: Mar 15 2026 GMT                                   ← 有効期限
> GET /health HTTP/1.1
> Host: smartassist.example.com
>
< HTTP/1.1 200 OK                                                  ← 200 OK = 成功
< Content-Type: application/json
<
{"status": "healthy"}

失敗例と原因

エラーメッセージ原因
Could not resolve hostDNS解決失敗
Connection timed outFWブロックまたはネットワーク不通
Connection refused宛先サーバがポートを開いていない
SSL certificate problem証明書エラー（期限切れ、不正な発行者等）
407 Proxy Authentication Requiredプロキシ認証が必要
curlの-vオプションは"魔法の杖"

トラブルシューティングの基本は curl -v です。これさえ覚えておけば、大半の問題の切り分けができます。-v（verbose）をつけると、以下の情報が全部見えます：

  • DNS解決結果: Trying 52.194.10.20:443...
  • TCP接続: Connected to ...
  • TLSハンドシェイク: SSL connection using TLSv1.2
  • 証明書情報: issuer: と expire date:
  • HTTPステータス: HTTP/1.1 200 OK

「通信できません」と報告を受けたら、まず curl -v https://smartassist.example.com/health の出力を取ってもらう。この出力だけで、どの層で止まっているかが分かります。

10.4 ポート疎通確認

なぜポート疎通確認が必要か

pingが成功してもHTTPS通信が失敗する場合がある。これは、ICMP（ping）は許可されているが、TCP 443番ポートがブロックされているケースである。

PowerShellでの確認方法（Windows）

# TCP 443ポートの疎通確認
Test-NetConnection -ComputerName smartassist.example.com -Port 443

実行結果の読み方

ComputerName     : smartassist.example.com
RemoteAddress    : 52.194.10.20
RemotePort       : 443
TcpTestSucceeded : True          ← True = ポート疎通OK

ComputerName     : smartassist.example.com
RemoteAddress    : 52.194.10.20
RemotePort       : 443
TcpTestSucceeded : False         ← False = ポート疎通NG

telnetでの確認方法

# telnetがインストールされている場合
telnet smartassist.example.com 443

画面が真っ暗になれば接続成功。「接続できませんでした」と表示されれば失敗。

10.5 DNS障害切り分け

DNS障害の症状

Smart Assist PCからクラウドへの通信が失敗し、nslookupでFQDNの名前解決ができない場合、DNS障害を疑う。

切り分けフローチャート

nslookup smartassist.example.com 成功 DNSは正常。別の原因を調査 失敗 nslookup smartassist.example.com 8.8.8.8 成功 院内DNSの問題 フォワーダ設定・DNSサーバの状態を確認 失敗 FQDNが存在しない or 外部DNSへの通信がブロック 並行して確認 ping 院内DNSサーバIP 成功 DNSサービスは到達可能だが応答しない DNSサービスの再起動を検討 失敗 DNSサーバとの疎通がない ネットワーク経路の確認

10.6 プロキシ障害切り分け

プロキシ障害の症状

  • curlで接続タイムアウトが発生する
  • 407 Proxy Authentication Required が返される
  • 403 Forbidden が返される

切り分けフローチャート

curl -v --proxy http://proxy:8080 https://smartassist.example.com/health 200 OK 正常に通信できている 407 プロキシ認証が必要 認証情報を確認・設定 403 URLフィルタでブロック ホワイトリスト追加を依頼 タイムアウト ping proxy.hospital.local 成功 プロキシサービスの状態を確認 失敗 プロキシへのネットワーク経路を確認 プロキシ設定の確認 アドレス・ポート番号、HTTPS_PROXY変数 SSL証明書エラー SSLインスペクション の可能性（次節参照）
プロキシ除外設定の確認方法

プロキシ環境のトラブルで意外と見落とすのが、プロキシ除外設定（bypass list）の確認。Smart Assistの宛先がプロキシ除外リストに入っていたら、プロキシ設定があっても直接接続しようとします。

Windowsなら以下で確認：

  • netsh winhttp show proxy でシステムプロキシ設定と除外リストを表示
  • 環境変数 NO_PROXY の値を確認
  • IEのプロキシ設定画面の「例外」欄を確認

逆のパターンもあります。「プロキシ経由で通信するはずなのに、直接接続しようとしてタイムアウトする」場合、HTTPS_PROXY 環境変数が設定されていない可能性大。

10.7 SSLインスペクション障害

症状

  • curlで SSL certificate problem: unable to get local issuer certificate が表示される
  • Smart Assistクライアントが「証明書エラー」で接続に失敗する

確認方法

# curlで証明書の詳細を確認
curl -v https://smartassist.example.com/health 2>&1 | grep -i "issuer"

* Server certificate:
*   issuer: CN=Hospital Proxy CA    ← AWSの証明書ではなく、病院のプロキシCA

発行者がAWSやLet's Encryptなどの公的CAではなく、病院内部のCA名になっている場合、SSLインスペクションが行われている。

対処の流れ

ステップ内容
1curlの-vオプションで証明書の発行者を確認する
2発行者が病院内部のCAであれば、SSLインスペクションが原因
3病院IT担当者にSmart Assistの宛先FQDNをSSLインスペクション除外リストに追加するよう依頼する
4除外が難しい場合、プロキシCAの証明書をSmart Assist PCの信頼されたルート証明書ストアにインストールする
「通信できない」チェックリスト -- この順番で潰せ

「Smart Assistが繋がりません」と連絡が来たとき、この順番で確認すれば効率的です。上から順に確認して、最初に失敗したところが原因です。

  1. IPアドレス確認: ipconfig でIPアドレスとGWが正しいか
  2. GW疎通: ping デフォルトGW
  3. DNS解決: nslookup smartassist.example.com
  4. ポート疎通: Test-NetConnection smartassist.example.com -Port 443
  5. HTTPS接続: curl -v https://smartassist.example.com/health
  6. 証明書確認: curl -v の issuer と expire date を確認

この6ステップをメモに書いてPCの横に貼っておくと、電話対応中でもスムーズに指示が出せます。

10.8 証明書期限切れ

症状

  • 今まで正常に動作していたSmart Assistの通信が突然失敗する
  • curlで SSL certificate has expired が表示される

確認方法

# 証明書の有効期限を確認
curl -v https://smartassist.example.com 2>&1 | grep "expire"

*   expire date: Jan 15 2025 GMT    ← 有効期限が過去の日付

OpenSSLでの詳細確認

# サーバ証明書の詳細を表示
openssl s_client -connect smartassist.example.com:443 -servername smartassist.example.com < /dev/null 2>/dev/null | openssl x509 -noout -dates

notBefore=Jan 15 2024 00:00:00 GMT
notAfter=Jan 15 2025 00:00:00 GMT      ← 有効期限

対処の流れ

原因対処
Smart Assistサーバの証明書期限切れSmart Assist運用チームに証明書更新を依頼
SSLインスペクション用CA証明書の期限切れ病院IT担当者に更新を依頼
Smart Assist PCの時刻がずれているPCの時刻を正しく設定する（NTP確認）

予防策

  • 証明書の有効期限を定期的に監視する仕組みを構築する
  • 期限切れの30日前にアラートを出すよう設定する
  • 自動更新が設定されている場合でも、更新の成功を確認するプロセスを設ける

トラブルシューティング総合フローチャート

Smart Assist 通信障害発生 ① ping デフォルトゲートウェイ 失敗 ネットワーク基本疎通の問題 ケーブル、IP設定を確認 成功 ② nslookup smartassist.example.com 失敗 DNS障害（10.5の切り分けへ） 成功 ③ Test-NetConnection -Port 443 失敗 FWでブロックされている可能性 FWルールを確認 成功 ④ curl -v https://smartassist.example.com/health SSL証明書エラー SSLインスペクション or 期限切れ （10.7, 10.8の切り分けへ） 407 プロキシ認証エラー（10.6へ） 403 URLフィルタ（10.6へ） タイムアウト プロキシ設定確認（10.6へ） 200 OK ネットワーク経路は正常 アプリケーション側の問題を調査

次章では、Smart Assistの導入から本番稼働までの実務プロセスを学ぶ。