Day 10: ネットワークトラブルシューティングとツール
今日学ぶこと
- 体系的なトラブルシューティングアプローチ（OSIレイヤーごと）
- 必須ツール：ping、traceroute、nslookup/dig、netstat/ss、curl、tcpdump、Wireshark
- よくあるネットワーク問題と診断方法
- ネットワーク監視（SNMP、Nagios、Zabbix）
- パフォーマンス最適化（帯域幅、レイテンシ、ジッター、パケットロス）
- クラウドネットワーキングの基礎（VPC、セキュリティグループ、ロードバランサー）
- ネットワークエンジニアのキャリアパス
体系的なトラブルシューティング
ネットワーク問題を効率的に解決するには、OSI参照モデルの各レイヤーを下から順に確認する方法が有効です。
flowchart TB
subgraph Approach["OSIレイヤーごとのトラブルシューティング"]
L1["L1 物理層<br/>ケーブル接続、リンクランプ"]
L2["L2 データリンク層<br/>MACアドレス、ARP、VLAN"]
L3["L3 ネットワーク層<br/>IPアドレス、ルーティング、ping"]
L4["L4 トランスポート層<br/>ポート、TCP接続、ファイアウォール"]
L7["L5-7 アプリケーション層<br/>DNS、HTTP、TLS、アプリ設定"]
end
L1 --> L2 --> L3 --> L4 --> L7
style L1 fill:#ef4444,color:#fff
style L2 fill:#f59e0b,color:#fff
style L3 fill:#22c55e,color:#fff
style L4 fill:#3b82f6,color:#fff
style L7 fill:#8b5cf6,color:#fff
各レイヤーでの確認項目
| レイヤー | 確認項目 | ツール |
|---|---|---|
| L1 物理 | ケーブル接続、ランプ点灯、Wi-Fi信号 | 目視確認 |
| L2 データリンク | MACアドレス、ARP テーブル | arp -a, ip link |
| L3 ネットワーク | IPアドレス、デフォルトゲートウェイ、到達性 | ping, traceroute, ip addr |
| L4 トランスポート | ポート開放、TCP接続状態 | netstat, ss, telnet |
| L5-7 アプリケーション | DNS解決、HTTP応答、TLS証明書 | dig, curl, openssl |
必須ネットワークツール
ping
指定したホストへのICMPエコーリクエストを送信し、到達性と応答時間を確認します。
# Basic ping
ping -c 4 example.com
# Ping with specific packet size
ping -c 4 -s 1472 example.com
# Continuous ping (Linux)
ping example.com
# Ping with timeout
ping -c 4 -W 2 example.com
出力例：
PING example.com (93.184.216.34): 56 data bytes
64 bytes from 93.184.216.34: icmp_seq=0 ttl=56 time=11.3 ms
64 bytes from 93.184.216.34: icmp_seq=1 ttl=56 time=10.8 ms
64 bytes from 93.184.216.34: icmp_seq=2 ttl=56 time=11.1 ms
64 bytes from 93.184.216.34: icmp_seq=3 ttl=56 time=10.9 ms
--- example.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 10.8/11.0/11.3/0.2 ms
| 結果 | 意味 |
|---|---|
| 応答あり | ネットワーク到達可能 |
| Request timeout | ホスト到達不可またはICMPブロック |
| Destination unreachable | ルーティング問題 |
| 高いRTT | ネットワーク遅延 |
| パケットロス | ネットワーク品質問題 |
traceroute / tracert
パケットが目的地まで経由するルーター（ホップ）を表示します。
# Linux
traceroute example.com
# Using TCP instead of UDP (more reliable through firewalls)
traceroute -T example.com
# Windows
tracert example.com
# Alternative: mtr (combines ping + traceroute)
mtr example.com
flowchart LR
A["自分のPC"] -->|Hop 1| B["ルーター1<br/>192.168.1.1<br/>1ms"]
B -->|Hop 2| C["ISP<br/>10.0.0.1<br/>5ms"]
C -->|Hop 3| D["中継<br/>172.16.0.1<br/>15ms"]
D -->|Hop 4| E["目的地<br/>93.184.216.34<br/>25ms"]
style A fill:#3b82f6,color:#fff
style E fill:#22c55e,color:#fff
nslookup / dig
DNS名前解決を確認するツールです（Day 6で詳しく学びました）。
# Quick DNS check
nslookup example.com
# Detailed DNS query
dig example.com
# Check specific record type
dig example.com MX
# Use specific DNS server
dig @8.8.8.8 example.com
netstat / ss
ネットワーク接続、リスニングポート、ルーティングテーブルを表示します。
# Show all listening ports (ss is the modern replacement for netstat)
ss -tlnp
# Show all TCP connections
ss -tnp
# Show listening ports with process info
ss -tlnp | grep :80
# Show network statistics
ss -s
# Legacy: netstat equivalent
netstat -tlnp
| オプション（ss） | 意味 |
|---|---|
-t |
TCPのみ |
-u |
UDPのみ |
-l |
リスニング状態のみ |
-n |
名前解決しない（高速） |
-p |
プロセス情報を表示 |
curl
HTTPリクエストを送信し、レスポンスを確認します。
# Basic GET request
curl https://example.com
# Show response headers
curl -I https://example.com
# Verbose output (request + response details)
curl -v https://example.com
# POST request with JSON
curl -X POST https://httpbin.org/post \
-H "Content-Type: application/json" \
-d '{"key": "value"}'
# Follow redirects
curl -L https://example.com
# Show timing information
curl -o /dev/null -s -w "DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTLS: %{time_appconnect}s\nTotal: %{time_total}s\n" https://example.com
tcpdump
ネットワークインターフェースを流れるパケットをキャプチャします。
# Capture all traffic on eth0
sudo tcpdump -i eth0
# Capture only HTTP traffic
sudo tcpdump -i eth0 port 80
# Capture traffic to/from specific host
sudo tcpdump -i eth0 host 93.184.216.34
# Save capture to file (for Wireshark analysis)
sudo tcpdump -i eth0 -w capture.pcap
# Capture DNS traffic
sudo tcpdump -i eth0 port 53
# Capture with readable output
sudo tcpdump -i eth0 -A port 80
Wireshark
WiresharkはGUIベースのパケット解析ツールで、tcpdumpよりも視覚的にパケットを分析できます。
| 機能 | 説明 |
|---|---|
| リアルタイムキャプチャ | ネットワークトラフィックをリアルタイムに表示 |
| フィルタリング | 表示フィルタとキャプチャフィルタ |
| プロトコル解析 | 数百のプロトコルを自動解析 |
| ストリーム追跡 | TCP/HTTPストリームの再構築 |
よく使うWiresharkフィルタ：
http # HTTPトラフィックのみ
tcp.port == 443 # HTTPS（ポート443）
ip.addr == 192.168.1.1 # 特定IPのトラフィック
dns # DNSクエリのみ
tcp.flags.syn == 1 # SYNパケット（接続開始）
tcp.analysis.retransmission # 再送パケット
よくあるネットワーク問題と診断
トラブルシューティングのフローチャート
flowchart TB
Start["インターネットに接続できない"]
Q1{"ケーブル/Wi-Fi<br/>接続済み？"}
Q2{"IPアドレス<br/>取得済み？"}
Q3{"デフォルトGW<br/>にping可能？"}
Q4{"外部IP<br/>にping可能？"}
Q5{"DNS解決<br/>可能？"}
Fix1["ケーブル接続<br/>Wi-Fi再接続"]
Fix2["DHCP確認<br/>手動設定"]
Fix3["ルーター再起動<br/>設定確認"]
Fix4["ISP障害確認<br/>ルーティング確認"]
Fix5["DNSサーバー変更<br/>8.8.8.8 等"]
OK["接続成功"]
Start --> Q1
Q1 -->|No| Fix1
Q1 -->|Yes| Q2
Q2 -->|No| Fix2
Q2 -->|Yes| Q3
Q3 -->|No| Fix3
Q3 -->|Yes| Q4
Q4 -->|No| Fix4
Q4 -->|Yes| Q5
Q5 -->|No| Fix5
Q5 -->|Yes| OK
style Start fill:#ef4444,color:#fff
style OK fill:#22c55e,color:#fff
style Fix1 fill:#f59e0b,color:#fff
style Fix2 fill:#f59e0b,color:#fff
style Fix3 fill:#f59e0b,color:#fff
style Fix4 fill:#f59e0b,color:#fff
style Fix5 fill:#f59e0b,color:#fff
よくある問題と対処法
| 問題 | 症状 | 確認方法 | 対処法 |
|---|---|---|---|
| 物理接続 | 完全に通信不可 | ランプ確認 | ケーブル交換、Wi-Fi再接続 |
| DHCP障害 | IPアドレス未取得 | ip addr |
DHCP再要求、手動設定 |
| DNS障害 | 名前解決失敗 | dig example.com |
DNSサーバー変更 |
| ファイアウォール | 特定ポートがブロック | telnet host port |
ルール確認・修正 |
| MTU問題 | 大きいパケットが通らない | ping -s 1472 |
MTU値を調整 |
| 帯域不足 | 通信が遅い | iperf3 |
QoS設定、帯域増強 |
ネットワーク監視
SNMP（Simple Network Management Protocol）
SNMPは、ネットワーク機器の情報を収集・管理するためのプロトコルです。
flowchart LR
subgraph NMS["管理サーバー（NMS）"]
A["監視ソフトウェア"]
end
subgraph Devices["管理対象デバイス"]
B["ルーター<br/>SNMPエージェント"]
C["スイッチ<br/>SNMPエージェント"]
D["サーバー<br/>SNMPエージェント"]
end
A -->|GET/SET| B
A -->|GET/SET| C
A -->|GET/SET| D
B -->|TRAP| A
C -->|TRAP| A
D -->|TRAP| A
style NMS fill:#3b82f6,color:#fff
style Devices fill:#22c55e,color:#fff
| SNMPバージョン | 認証 | 暗号化 | 推奨度 |
|---|---|---|---|
| SNMPv1 | コミュニティ文字列 | なし | 非推奨 |
| SNMPv2c | コミュニティ文字列 | なし | 限定使用 |
| SNMPv3 | ユーザー認証 | あり | 推奨 |
監視ツール
| ツール | 種類 | 特徴 |
|---|---|---|
| Nagios | オープンソース | プラグインが豊富、老舗 |
| Zabbix | オープンソース | エージェント型、テンプレート充実 |
| Prometheus | オープンソース | Pull型、Kubernetes連携 |
| Grafana | ダッシュボード | 可視化に特化 |
| Datadog | SaaS | クラウドネイティブ |
| CloudWatch | AWS | AWSリソース監視 |
パフォーマンス最適化
4つの主要指標
flowchart TB
subgraph Metrics["ネットワークパフォーマンス指標"]
BW["帯域幅<br/>（Bandwidth）<br/>データ転送の最大容量"]
LAT["レイテンシ<br/>（Latency）<br/>データ到達までの時間"]
JIT["ジッター<br/>（Jitter）<br/>レイテンシのばらつき"]
PL["パケットロス<br/>（Packet Loss）<br/>失われたパケットの割合"]
end
style BW fill:#3b82f6,color:#fff
style LAT fill:#8b5cf6,color:#fff
style JIT fill:#f59e0b,color:#fff
style PL fill:#ef4444,color:#fff
| 指標 | 定義 | 測定方法 | 理想値 |
|---|---|---|---|
| 帯域幅 | 単位時間あたりのデータ転送量 | iperf3 |
契約速度に近い値 |
| レイテンシ | パケットの往復時間（RTT） | ping |
国内 < 20ms |
| ジッター | レイテンシの変動幅 | mtr |
< 5ms |
| パケットロス | 失われるパケットの割合 | ping -c 100 |
0% |
アプリケーション別の要件
| アプリケーション | 帯域幅 | レイテンシ | ジッター | パケットロス |
|---|---|---|---|---|
| Webブラウジング | 中 | 中 | 低い影響 | 低い影響 |
| ビデオ会議 | 高 | 低 | 重要 | 重要 |
| オンラインゲーム | 低 | 極低 | 重要 | 重要 |
| ファイル転送 | 高 | 低い影響 | 低い影響 | 低い影響 |
| VoIP | 低 | 低 | 非常に重要 | 重要 |
クラウドネットワーキングの基礎
VPC（Virtual Private Cloud）
VPCは、クラウド上に作成するプライベートネットワークです。
flowchart TB
subgraph VPC["VPC (10.0.0.0/16)"]
subgraph Public["パブリックサブネット (10.0.1.0/24)"]
ALB["ロードバランサー"]
NAT["NATゲートウェイ"]
end
subgraph Private["プライベートサブネット (10.0.2.0/24)"]
App["アプリサーバー"]
end
subgraph DB["データベースサブネット (10.0.3.0/24)"]
RDS["データベース"]
end
end
IGW["インターネット<br/>ゲートウェイ"]
IGW --> ALB
ALB --> App
App --> RDS
App --> NAT
NAT --> IGW
style VPC fill:#3b82f6,color:#fff
style Public fill:#22c55e,color:#fff
style Private fill:#f59e0b,color:#fff
style DB fill:#ef4444,color:#fff
主要コンポーネント
| コンポーネント | 説明 |
|---|---|
| VPC | 仮想ネットワーク空間 |
| サブネット | VPC内のネットワーク分割 |
| インターネットゲートウェイ | VPCとインターネットの接続点 |
| NATゲートウェイ | プライベートサブネットからの外部通信 |
| セキュリティグループ | インスタンスレベルのファイアウォール |
| ネットワークACL | サブネットレベルのファイアウォール |
| ロードバランサー | トラフィックの分散（ALB、NLB） |
| Route 53 | AWS のDNSサービス |
セキュリティグループ vs ネットワークACL
| 項目 | セキュリティグループ | ネットワークACL |
|---|---|---|
| レベル | インスタンス | サブネット |
| ステートフル | はい | いいえ |
| ルール | 許可のみ | 許可 + 拒否 |
| 評価 | すべてのルールを評価 | 番号順に評価 |
| デフォルト | 全拒否（インバウンド） | 全許可 |
キャリアパス
ネットワークの知識は、さまざまなIT分野で活かせます。
flowchart TB
subgraph Career["ネットワーク関連キャリア"]
NE["ネットワークエンジニア"]
SE["セキュリティエンジニア"]
CE["クラウドエンジニア"]
SRE["SRE / DevOps"]
SA["ソリューションアーキテクト"]
end
subgraph Certs["主要資格"]
CCNA["Cisco CCNA"]
CCNP["Cisco CCNP"]
AWS["AWS SAA / ANS"]
SEC["CompTIA Security+"]
LPIC["LPIC / LinuC"]
end
NE --> CCNA
NE --> CCNP
CE --> AWS
SE --> SEC
SRE --> LPIC
style Career fill:#3b82f6,color:#fff
style Certs fill:#8b5cf6,color:#fff
| キャリア | 主な業務 | 推奨資格 |
|---|---|---|
| ネットワークエンジニア | ネットワーク設計・構築・運用 | CCNA, CCNP |
| セキュリティエンジニア | セキュリティ対策・監視 | CompTIA Security+, CISSP |
| クラウドエンジニア | クラウドインフラ設計 | AWS SAA, Azure AZ-104 |
| SRE / DevOps | 信頼性・自動化 | CKA, AWS DevOps |
| ソリューションアーキテクト | システム全体設計 | AWS SAP, TOGAF |
まとめ
今日学んだことの整理
| トピック | キーポイント |
|---|---|
| トラブルシューティング | OSIレイヤーを下から順に確認 |
| 必須ツール | ping, traceroute, dig, ss, curl, tcpdump, Wireshark |
| よくある問題 | 物理接続、DHCP、DNS、ファイアウォール、MTU |
| ネットワーク監視 | SNMP、Nagios、Zabbix、Prometheus |
| パフォーマンス指標 | 帯域幅、レイテンシ、ジッター、パケットロス |
| クラウドネットワーキング | VPC、セキュリティグループ、ロードバランサー |
| キャリアパス | NE、セキュリティ、クラウド、SRE |
重要ポイント
- 体系的なアプローチが重要：闇雲に試すのではなく、レイヤーごとに切り分ける
- ツールを使いこなす：適切なツールを選べることがプロの条件
- 監視は予防：問題が起きてからではなく、常時監視で早期発見
- クラウドの知識は必須：現代のネットワークはクラウドと切り離せない
練習問題
基礎レベル
- 「Webサイトにアクセスできない」という問題に対し、OSIレイヤーの下から順に確認すべき項目とコマンドを列挙してください。
pingとtracerouteの違いを説明し、それぞれどのような場面で使うか述べてください。- クラウドにおけるセキュリティグループとネットワークACLの違いを3つ挙げてください。
中級レベル
- 以下のpingの結果から、何が問題かを診断してください。
64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=1.2 ms 64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=1.1 ms Request timeout for icmp_seq 3 64 bytes from 10.0.0.1: icmp_seq=4 ttl=64 time=245.3 ms Request timeout for icmp_seq 5 64 bytes from 10.0.0.1: icmp_seq=6 ttl=64 time=1.3 ms - Webアプリケーションが遅い場合の原因を、ネットワーク（帯域幅、レイテンシ）、DNS、サーバー（CPU、メモリ）の3つの観点から診断する手順を説明してください。
- VPCを設計し、パブリックサブネットにWebサーバー、プライベートサブネットにアプリサーバー、データベースサブネットにRDSを配置する構成図と、必要なルーティングテーブルを作成してください。
上級レベル
- 大規模なeコマースサイトで、特定のページだけが間欠的に遅くなるという報告がありました。tcpdumpとWiresharkを使った詳細な診断手順を説明してください。
- 以下の要件を満たすネットワーク監視システムを設計してください：
- 100台以上のサーバーとネットワーク機器を監視
- CPU、メモリ、ディスク、ネットワークトラフィックのメトリクス収集
- 異常検知と自動アラート
- ダッシュボードでの可視化
- マイクロサービスアーキテクチャにおけるサービスメッシュ（Istio等）がネットワークトラブルシューティングに与える影響と、従来のネットワーク監視との違いを論じてください。
参考リンク
- Wireshark User's Guide
- AWS VPC Documentation
- Prometheus Documentation
- Cisco - Network Troubleshooting
おめでとうございます！
おめでとうございます！10日間のネットワークの学習を完了しました。
この10日間で学んだことを振り返りましょう：
| Day | テーマ | 学んだこと |
|---|---|---|
| Day 1 | ネットワーク基礎 | ネットワークの基本概念 |
| Day 2 | OSI参照モデル | 7層の役割と通信の流れ |
| Day 3 | IPアドレスとサブネット | IPv4/IPv6、CIDR |
| Day 4 | TCP/UDP | トランスポート層プロトコル |
| Day 5 | スイッチングとルーティング | L2/L3の転送技術 |
| Day 6 | DNS | 名前解決の仕組み |
| Day 7 | HTTPとWeb | Webプロトコルの詳細 |
| Day 8 | TLS/SSLとセキュリティ | 暗号化と防御 |
| Day 9 | ワイヤレスとVPN | 無線技術とVPN |
| Day 10 | トラブルシューティング | 診断ツールと実践 |
ネットワークの知識は、すべてのIT分野の基盤です。この10日間で学んだことを土台に、実務での経験を積み、さらに深い知識を身につけてください。
次のステップ：
- 実際のネットワーク環境で学んだツールを使ってみる
- CCNA等の資格取得に挑戦する
- クラウド環境（AWS、Azure、GCP）でVPCを構築してみる
- 自宅ラボを構築して実験する