ネットワークの不調を感じたとき、まず確認すべきは「基本コマンド」です。
この記事では、Windows・PowerShellで使える代表的な診断コマンドを6つ紹介します。

💡 各記事は個別に詳しく解説していますので、ブックマークしておくとトラブル時に役立ちます。

🧭 1. ipconfig｜ネットワーク設定の確認

IPアドレス、DNSサーバ、ゲートウェイ設定など、PCの基本的な通信情報を確認するコマンド。
ネットワーク不調の第一歩は「設定を確認すること」から。

➡ 詳細はこちら

🌐 2. test-connection｜通信疎通の確認

PowerShellで使える「Ping代替コマンド」。
Test-Connection は ICMP通信の可否だけでなく、応答時間なども確認できます。

➡ 詳細はこちら

🧩 3. netstat｜通信ポートとプロセスを確認

「通信できているのか？」「どのアプリがポートを使っているのか？」を調べるならこれ。
netstat -ano でポート使用状況を確認し、PIDからプロセスを特定できます。

➡ 詳細はこちら

🔎 4. nslookup｜DNSトラブルを見抜く

Webサイトが開かないときにチェックすべき「名前解決」問題を調査できます。
DNSサーバ指定やMXレコードの確認にも対応。

➡ 詳細はこちら

🚫 5. ICMP禁止環境でも疎通確認する3つの方法

セキュリティポリシー上でping(ICMP)が禁止されていても、
Test-Connection -Port を使えばTCPレベルでの通信確認が可能です。

➡ 詳細はこちら

⚙️ 6. PowerShellでネットワーク監視を自動化する方法

Test-Connection -Port とタスクスケジューラを組み合わせて、
Web・DB・APIなどの死活監視を自動化できます。

➡ 詳細はこちら

🧾 まとめ表

💡 シリーズ活用のヒント

• 学習順序のおすすめ：
  「ipconfig → test-connection → netstat → nslookup → 応用① → 応用②」
• 組織運用での活用：
  ネットワーク障害対応マニュアルにリンクを添付しておくと便利です。
• 検索キーワード例：
  「ネットワークコマンド」「PowerShell 監視」「ping 代替」「ポート 確認」

ネットワーク障害の早期発見やサーバ死活確認を自動化したい場合、
PowerShellを使えばシンプルに実現できます。

本記事では、ICMPが禁止されている環境でも動作するPowerShell監視スクリプトを紹介します。
定期実行により、Web・DB・APIサーバなどの稼働状態を自動でチェック可能です。

🧭 概要

多くの企業ネットワークでは、セキュリティ上の理由から ICMP（ping）通信が遮断 されています。
そのため、従来の ping コマンドによる監視が使えないケースもあります。

しかし PowerShell 7 以降の Test-Connection -Port を使えば、
TCPレベルでの疎通確認 が可能です。
これを活用して、ping不要の自動監視スクリプトを構築していきます。

⚙️ 1. 監視対象リストの作成

まず、監視対象となるホストとポートを配列として定義します。

$targets = @(
    @{Name="Web"; Host="web01"; Port=443},
    @{Name="DB"; Host="db01"; Port=1433},
    @{Name="API"; Host="api01"; Port=8080}
)

🧩 2. TCPレベルの疎通チェック

Test-Connection -Port を利用して、ポート単位で死活確認を行います。
ICMPが禁止されていても、TCP通信が通れば「OK」と判定できます。

foreach ($t in $targets) {
    $result = Test-Connection $t.Host -Port $t.Port -Quiet
    $status = if ($result) { "OK" } else { "NG" }
    Write-Output "$(Get-Date -Format 'yyyy/MM/dd HH:mm:ss') $($t.Name): $status"
}

出力例：

2025/11/01 08:30:00 Web: OK
2025/11/01 08:30:00 DB: NG
2025/11/01 08:30:00 API: OK

📦 3. ログファイルへの出力

監視結果をファイルに追記して履歴に残します。

$logPath = "C:\Scripts\NetworkMonitor.log"
foreach ($t in $targets) {
    $result = Test-Connection $t.Host -Port $t.Port -Quiet
    $status = if ($result) { "OK" } else { "NG" }
    "$((Get-Date).ToString('yyyy/MM/dd HH:mm:ss')),$($t.Name),$($t.Host),$($t.Port),$status" | Out-File -Append -FilePath $logPath
}

結果例（CSV形式）：

2025/11/01 08:30:00,Web,web01,443,OK
2025/11/01 08:30:00,DB,db01,1433,NG
2025/11/01 08:30:00,API,api01,8080,OK

📬 4. メール通知を追加（オプション）

障害検知時に自動メール通知する場合はSend-MailMessageを使います。

if ($status -eq "NG") {
    Send-MailMessage `
        -From "monitor@domain.local" `
        -To "admin@domain.local" `
        -Subject "【アラート】$($t.Name) サーバ接続不可" `
        -Body "Host: $($t.Host) Port: $($t.Port) がNGです。" `
        -SmtpServer "mail.domain.local"
}

💡 TeamsやSlackに通知する場合は、Webhook URLにInvoke-RestMethodを使えばOKです。

⏰ 5. 定期実行（Windowsタスクスケジューラ）

作成したスクリプトを.ps1ファイルとして保存し、
タスクスケジューラで自動実行を設定します。

これで、サーバの死活状態が定期的に監視され、
障害発生時は即座に検知できます。

🧠 応用：HTTPレスポンス監視

Webサーバの応答確認にはInvoke-WebRequestを使う方法も有効です。

$response = Invoke-WebRequest "https://example.com" -UseBasicParsing -ErrorAction SilentlyContinue
if ($response.StatusCode -eq 200) {
    "Webサーバ稼働中"
} else {
    "応答異常：$($response.StatusCode)"
}

StatusCode 200 が返れば正常稼働。
API監視やWebアプリ死活確認にも応用可能です。

🔗 関連記事

• ICMP禁止環境で疎通確認する3つの方法
• Test-Connectionの基本使い方｜Pingとの違いと応用
• netstatで通信ポートを確認する方法
• PowerShellでログ出力を自動化する方法（予定）

🧾 まとめ

• Test-Connection -Portを使えば、ICMP禁止環境でも死活確認可能
• ログ出力やメール通知で、自動監視をシンプルに構築可能
• スケジューラ設定で運用自動化が実現

PowerShellは「運用監視の自動化ツール」としても強力です。
小さく始めて、徐々にログ解析・通知連携などに拡張していきましょう。

Webサイトが開かない、サーバにはpingが通るのに名前で通信できない——
そんなときに真っ先に確認したいのが nslookup コマンド です。

この記事では、DNSの名前解決を調べる基本的な使い方から、
特定のDNSサーバを指定した調査方法まで、実務で役立つ手順を解説します。

🔍 nslookupとは？

nslookup（Name Server Lookup）は、ドメイン名とIPアドレスの対応（名前解決）を確認するコマンドです。
DNSサーバの応答を直接確認できるため、ネットワーク疎通は問題ないのに名前解決ができない場合の切り分けに最適です。

💡 “nslookup = DNS診断の聴診器” のような存在です。

🧭 基本構文

nslookup ＜ホスト名 or IPアドレス＞

例：ドメインからIPを調べる

nslookup www.google.com

結果（例）：

Server:  UnKnown
Address:  192.168.1.1

非権限の回答:
名前:    www.google.com
Addresses:  142.250.196.132

「Address」に表示されるのが実際に解決されたIPアドレスです。

🔁 IPアドレスからドメイン名を調べる（逆引き）

nslookup 8.8.8.8

結果（例）：

Server:  dns.local
Address:  192.168.1.1

名前:    dns.google
Address:  8.8.8.8

逆引き（PTRレコード）が設定されていれば、IPからホスト名を取得できます。

🌐 特定のDNSサーバを指定して確認

デフォルトでは、PCに設定されたDNSサーバに問い合わせます。
特定のサーバに対してテストしたい場合は、以下のように記述します。

nslookup www.yahoo.co.jp 8.8.8.8

→ Google Public DNS(8.8.8.8)を使って名前解決を実行。
これにより、「社内DNSでは解決できないが外部DNSでは解決可能」といったケースを切り分けられます。

📖 詳細モードで確認する（setコマンド）

nslookup起動後に「set」コマンドを使うことで、より詳細な確認が可能です。

nslookup
＞ set type=MX
＞ google.com

結果（例）：

google.com  MX preference = 10, mail exchanger = smtp.google.com

💡 DNS設定の不整合（例：SPF誤設定やMX未登録）も確認できます。

🧩 実務での活用例

⚠️ トラブル時のチェックポイント

🧠 DNSトラブル切り分けフロー

(1) pingも名前も通らない → ネットワーク問題（物理 or FW）
(2) ping通るが名前解決NG → DNS問題
(3) 外部DNSでは解決OK → 社内DNSのゾーン設定を疑う
(4) 逆引きできない → PTRレコード未設定

🔗 関連記事

• ipconfig｜ネットワーク設定の確認
• test-connection｜通信疎通の確認方法
• netstat｜通信ポートとプロセスを確認する方法
• ICMP禁止環境でも疎通確認する方法

🧾 まとめ

nslookupは、DNSトラブルを切り分けるための基本ツールです。
名前解決が正しく行われているか、どのDNSサーバで問題が発生しているかを迅速に判断できます。

DNS周りで問題が発生したときは、まず「nslookup」で確認する習慣をつけましょう。

ネットワーク通信がうまくいかない、特定のポートが使用中かわからない——
そんなときに役立つのが netstat コマンド です。

この記事では、通信ポートの使用状況や接続先を確認する方法を、
実務例とともにわかりやすく解説します。

🔍 netstatとは？

netstat（Network Statistics）は、現在の通信状態を確認するコマンドです。
TCP・UDPの接続状況、ポート番号、プロセスID（PID）などを一覧で表示できます。

💡 サーバが「通信しているのか」「どのアプリがポートを掴んでいるのか」を調べるときに必須のコマンドです。

🧭 基本構文

netstat

この基本コマンドでは、現在の通信接続の一覧を簡易的に表示します。

出力例：

Active Connections

  Proto  Local Address          Foreign Address        State
  TCP    192.168.1.10:49732     142.250.196.132:443    ESTABLISHED
  TCP    192.168.1.10:49733     20.190.128.3:443       ESTABLISHED

⚙️ よく使うオプション一覧

🔎 通常使用例：現在のTCP通信を確認

netstat -ano

結果（例）：

Proto  Local Address          Foreign Address        State           PID
TCP    0.0.0.0:80             0.0.0.0:0              LISTENING       1428
TCP    192.168.1.10:49852     142.250.196.132:443    ESTABLISHED     5124

💡 「State = LISTENING」なら、そのポートでアプリが待機中という意味です。

🧩 ポートを掴んでいるアプリを特定

PID(プロセスID)から、どのアプリがポートを使用しているか調べられます。

tasklist | findstr 1428

結果（例）：

httpd.exe                 1428  Console  0  12,340 K

→　PID1428はApache(httpd)が使用していることがわかります。

🔒 特定ポートを使用しているプロセスを検索

特定のポート（例：443番）を使用しているアプリを確認するには：

netstat -ano | findstr :443

結果：

TCP    0.0.0.0:443     0.0.0.0:0     LISTENING     2564

さらにプロセスを特定：

tasklist | findstr 2564

🧠 通信状態の「State」一覧

🧰 実務での活用例

⚡ PowerShellでの代替：Get-NetTCPConnection

Windows 10以降では、PowerShellでも同様の確認が可能です。

Get-NetTCPConnection | Select-Object LocalAddress,LocalPort,RemoteAddress,State,OwningProcess

💡 結果はオブジェクトとして扱えるため、Where-Object でのフィルタリングも可能。

🔗 関連記事

• ipconfig｜ネットワーク設定の確認
• test-connection｜通信疎通の確認方法
• nslookup｜DNSトラブルを調べる方法
• ICMP禁止環境でも疎通確認する方法

🧾 まとめ

netstatは、通信状態・ポート・プロセスを一度に把握できる非常に強力なツールです。 トラブル対応時は、以下の手順で原因を切り分けましょう。

1. netstat -anoで接続確認
2. findstr : ポート番号で対象検出
3. tasklist | findstr PIDでアプリ特定

ネットワークの疎通確認といえば「ping」。
しかし、セキュリティポリシーの厳しい環境では ICMP（ping通信）がファイアウォールで禁止 されているケースも少なくありません。

この記事では、そんな「pingが通らない環境」で通信確認を行う方法を3つ紹介します。
Test-Connection -Port の活用例を中心に、実務で役立つ切り分けテクニックを解説します。

🚫 なぜpingが通らないのか？

ping は ICMP（Internet Control Message Protocol）を利用して通信確認を行います。
多くのFWやルータでは、セキュリティ上の理由からこのICMP通信が遮断されています。

• ICMPを許可すると、ネットワーク構成の推測（ポートスキャン）に悪用される恐れ
• 外部からのDoS攻撃（ICMP Flood）対策のため

結果として、pingが「Request timed out」になっても、実際はTCP通信が正常に行えている場合があります。

✅ 方法①：PowerShellのTest-Connection -Portを使う

PowerShell 7以降で利用可能な Test-Connection -Port は、TCPレベルで疎通確認を行えます。
つまり、ping(ICMP)が禁止されていても、対象ポートが開いていれば通信可能です。

例：Web・DB・SSHなどの確認

Test-Connection web01 -Port 80
Test-Connection web01 -Port 443
Test-Connection db01 -Port 1433
Test-Connection server01 -Port 22

結果：

TcpTestSucceeded : True
ComputerName     : web01
RemotePort       : 443
RoundtripTime    : 12

🧩 方法②：アプリ層でのHTTP通信テスト（Invoke-WebRequest）

Webサーバの応答を確認したい場合は、HTTPリクエストを送る方法もあります。

Invoke-WebRequest https://www.google.com -UseBasicParsing

• ステータスコード 200 OK → 正常応答
• ステータスコード 403 / 500 → Webアプリまたは認証エラー

💡 Invoke-WebRequest はAPIやWebシステムの死活確認にも活用できます。

🧠 方法③：特定ポートの開閉を確認（Test-NetConnection）

もう1つの便利なコマンドがTest-NetConnection (Windows標準搭載)。
PowerShell 5以降で利用でき、ICMPが使えない環境でもポートを指定して通信確認が可能です。

Test-NetConnection db01 -Port 1433

結果：

ComputerName     : db01
RemoteAddress    : 192.168.1.100
RemotePort       : 1433
TcpTestSucceeded : True

→ TcpTestSucceeded : Trueで疎通成功。
アプリケーション層(DBサーバやAPIサーバなど)との通信可否を簡単に判定できます。

🔍 実務での切り分けシナリオ

💻 自動監視スクリプト例（PowerShell）

以下のスクリプトをタスクスケジューラに登録しておけば、ミドルウェアの死活を定期的チェックできます。

$targets = @(
    @{Name="Web"; Host="web01"; Port=443},
    @{Name="DB"; Host="db01"; Port=1433},
    @{Name="API"; Host="api01"; Port=8080}
)

foreach ($t in $targets) {
    $result = Test-Connection $t.Host -Port $t.Port -Quiet
    $status = if ($result) { "OK" } else { "NG" }
    Write-Output "$(Get-Date -Format 'yyyy/MM/dd HH:mm:ss') $($t.Name): $status"
}

出力例：

2025/11/01 08:30:00 Web: OK
2025/11/01 08:30:00 DB: NG
2025/11/01 08:30:00 API: OK

🔗 関連記事

• Test-Connectionの基本使い方｜Pingとの違いと応用
• netstatで通信ポートを確認する方法
• PowerShellでネットワーク監視を自動化する方法

🧾 まとめ

ファイアウォールでICMPが禁止されている環境でも、
PowerShellのTest-Connection -PortやTest-NetConnectionを使えば、
TCPレベルでの疎通確認が可能です。

pingが通らない = 通信できない ではない！
TCPポートが開いているかどうかを確認することで、正確な原因切り分けができます。

ネットワークが繋がらないとき、まず思い浮かぶのが「ping」ですが、
PowerShell環境ではより高機能な test-connection コマンドを使うことができます。

この記事では、test-connection の基本的な使い方から、ping との違い、実際のトラブルシュート例までをわかりやすく解説します。

🔍 test-connectionとは？

test-connection は、PowerShell版のPingコマンドです。
通信の疎通確認だけでなく、応答時間・成功率・経路情報なども取得できます。

💡 PowerShell環境では「ping」の代わりに「test-connection」を使うのが推奨です。

🧭 基本構文

Test-Connection <宛先>

例：

Test-Connection www.google.com

結果(例)：

Source        Destination     IPV4Address      IPV6Address  Bytes    Time(ms)
------        -----------     -----------      -----------  -----    --------
PC01          www.google.com  142.250.196.132               32       15
PC01          www.google.com  142.250.196.132               32       16

• Source : 送信元ホスト名
• Destination : 通信先ホスト名
• Time(ms) : 応答時間(ミリ秒)

⚙️ 回数を指定して送信（-Count）

デフォルトでは4回パケットを送信しますが、-Countで回数を指定できます。

Test-Connection www.google.com -Count 2

🧩 結果を簡潔に出す（-Quiet）

成功・失敗だけを判定したい場合は、-Quietオプションを使用します。

Test-Connection www.google.com -Quiet

結果例：

True

→ True = 通信成功
→ False = 通信不可

🔸 スクリプトで疎通確認を行いたいときに便利です。

📊 結果を変数に格納する

PowerShellの強みは、出力をオブジェクトとして扱えることです。

$result = Test-Connection www.google.com -Count 4
$result | Select-Object Address, ResponseTime

→ これで応答時間だけを抽出することも可能。

🚪 特定ポートの疎通を確認する（-Port）

PowerShell 7以降では、-Portオプションを使って
特定のTCPポートへの疎通確認が可能です。
これは、アプリケーション層の通信確認にも役立ちます。

Test-Connection 192.168.1.100 -Port 1433 -InformationLevel Detailed

出力例：

TcpTestSucceeded : True
ComputerName     : 192.168.1.100
RemotePort       : 1433
RoundtripTime    : 12

💡 例：
・ “Webサーバ(HTTP/HTTPS) : -Port 80 または -Port 443“
・ “SQL Server : -Port 1433“
・ “MySQL : -Port 3306“
・ “SSH : -Port 22”

このオプションを使えば、ICMPが遮断された環境でもTCPポートレベルで疎通確認ができます。
つまり、ミドルウェア(DB・Web・APIサーバなど)の死活確認にも活用可能です。

🧠 pingとの違いまとめ

🧩 トラブルシュートの例

🔗 関連記事

• ipconfig｜ネットワーク設定の確認
• nslookup｜DNSトラブルを調べる方法
• netstat｜通信ポートとプロセスを確認する方法

🧾 まとめ

test-connectionは、PowerShell環境での通信確認の定番コマンドです。
シンプルな疎通確認から、スクリプトによる自動監視まで幅広く使えます。
特に-Portオプションを活用すれば、特定ミドルウェアやアプリケーションのTCPレベルの疎通確認が可能になります。

次の記事 → nslookup｜DNSトラブルを調べる方法

ネットワークが繋がらない、通信が不安定……
そんな時にまず確認したいのが、ipconfigコマンドです。
この記事では、Windows環境でネットワーク設定を簡単に確認できる「ipconfig」の使い方を、初心者にもわかりやすく解説します。

🔍 ipconfigとは？

ipconfigは、現在のネットワーク設定情報を表示するコマンドです。
具体的には以下のような情報を確認できます。

• IPv4アドレス（自分のPCのIP）
• サブネットマスク
• デフォルトゲートウェイ
• DNSサーバー
• MACアドレス（物理アドレス）

💡 ネットワーク接続ができないときは、まず「ipconfig」で設定の基本を確認するのが鉄則です。

🧭 基本構文

ipconfig

実行すると、接続中のネットワークアダプタごとに、IPアドレスなどの情報が表示されます。

例:

イーサネット アダプター ローカル エリア接続:

接続固有の DNS サフィックス . . . . . . :
IPv4 アドレス . . . . . . . . . . . . . : 192.168.1.10
サブネット マスク . . . . . . . . . . . : 255.255.255.0
デフォルト ゲートウェイ . . . . . . . : 192.168.1.1

⚙️ 詳細情報を確認する（/all オプション）

ipconfig /all

/allオプションを付けると、DNSサーバーやMACアドレスなどの詳細情報も表示されます。

主な項目：

🔁 IPアドレスを再取得する（リリース／リニュー）

Wi-FiやLAN接続の不具合時に有効な手順です。

ipconfig /release
ipconfig /renew

• /release : 現在のIPアドレスを解放
• /renew : DHCPサーバから新しいIPアドレスを再取得

⚠️ 管理者権限で実行が必要な場合があります。PowerShellを「管理者として実行」して行いましょう。

🧩 トラブル解決の実践例

💡 よくある質問

Q1. IPv4とIPv6の両方が表示されるけど、どっちを見ればいい？ → 多くの家庭・企業ネットワークでは、IPv4を使っています。まずはこちらを確認すればOKです。

Q2. Wi-Fiと有線LANのどちらを見れば？ → 現在使っているネットワークアダプタを見ましょう。Wi-Fiなら「ワイヤレスLANアダプタ」、LANなら「イーサネットアダプタ」と表示されます。

🔗 関連記事

• test-connection | 通信確認に使えるPowerShellコマンド
• nslookup | DNSトラブルを調べる方法
• netstat | 通信ポートとプロセスを確認する方法

🧠 まとめ

ipconfigは、ネットワーク診断の第一歩となる基本コマンドです。 まずはこのコマンドで、自分のPCがどんな設定でネットワークに接続しているかを把握しましょう。

トラブルシューティングでは、以下の順序が有効です👇

1. ipconfig /allで設定確認
2. test-connectionで疎通確認
3. nslookupでDNS確認
4. netstatで通信ポート確認

次の記事 → test-connectionの使い方はこちら

どうも！リョクちゃです。

ネットワークを学ぶうえで避けて通れないのが ARP（Address Resolution Protocol）。
今回はCisco Packet Tracerを使って、「IPアドレスからMACアドレスを解決する仕組み」を実際に目で見て確認していきましょう。

🧭 シナリオ概要

PC1からPC2へPingを送信するとき、
「192.168.1.20 はどのMACアドレス？」という問い合わせが発生します。
このやり取りを担うのが ARP（Address Resolution Protocol） です。

🧱 トポロジ構成

構成は非常にシンプルです👇

⚙️ ステップ1：IPアドレス設定

それぞれのPCで、
「Desktop」→「IP Configuration」から静的アドレスを設定します。

🔍 ステップ2：ARPテーブルの確認

通信前に、PC1で現在のARPテーブルを確認してみましょう。

C:\> arp -a
No ARP Entries Found

まだ通信していないため、テーブルは空です。
つまり「誰のMACアドレスも知らない」状態ですね。

🛰 ステップ3：Pingを実行してARPを発動させる

次に、PC1からPC2へPingを送信します。

C:\> ping 192.168.1.20

この瞬間、PC1は「192.168.1.20 のMACアドレスを教えて！」とLAN全体にブロードキャストを送信します。
これが ARP Request（問い合わせ） です。

💡 ステップ4：ARP Reply（応答）

PC2は「それ、私です！」とユニキャストで返答します。
この通信が ARP Reply（応答） にあたります。

🧠 ステップ5：ARPテーブルを再確認

再度、PC1で arp -a を実行してみましょう。

C:\> arp -a

Internet Address      Physical Address      Type
192.168.1.20          000d.5870.0955        dynamic

PC1がPC2のMACアドレスを学習したことが確認できます。
この情報はしばらくキャッシュとして保存され、再通信時はARPを行わずに送信できます。

🎞 ステップ6：Simulationモードで可視化

Cisco Packet Tracerの右下にある「Simulation」モードを使うと、
ARPの動きをステップごとに観察できます。

▶ ボタンの隣にある「→」ボタンで1ステップずつ進めながら、通信の流れを追ってみましょう。

🏁 まとめ

今回のハンズオンで理解できたポイントを整理します。

✅ IP通信を行う前に、必ずARPでMAC解決が行われる
✅ ARP Requestはブロードキャスト、ARP Replyはユニキャスト
✅ 通信後はARPテーブルにMACアドレスがキャッシュされる

ARPはネットワークの裏方として、IP通信を支える重要なプロトコルです。
Packet Tracerを使えば、目に見えない通信を「見える化」できます。
ぜひ、他のトポロジでも試してみてください！

どうも！リョクちゃです。

前回までの記事でVPNの設定方法を学びましたが、
「そもそもVPNはなぜ安全なのか？」
「IPsecやIKEって実際に何をしているのか？」
という疑問が残った人もいるのではないでしょうか。

この記事では、VPNの中核である IKE（鍵交換） と IPsec（データの暗号化） を図解つきでわかりやすく解説します。

IKEとIPsecの役割の違い

VPNには「準備」と「本番」の2つのフェーズがあります。

✅ IKEは準備、IPsecは本番通信 です。

IKEの動き：Phase1とPhase2

IKEは2段階でVPNの準備を行います。

🔐 Phase1：安全に話し合うための準備

• 暗号方式を決める（AESやSHAなど）
• お互いの身元を確認する（PSKや証明書）
• 鍵交換（Diffie-Hellman）
• ISAKMP SA（鍵交換用トンネル）を確立

🚀 Phase2：実際のVPN通信の準備

• VPNトラフィックの範囲を決定（どのネットワーク同士をつなぐか）
• IPsec SA（データ保護トンネル）を確立

✅ IKE Phase1とPhase2の流れ（図解）

IPsecのカプセル化：ESPとAH

IPsecはパケットを暗号化して安全に送信するための仕組みです。

✅ ESPパケット構造のイメージ

VPNでよく出る「SA」って何？

SA（Security Association） とは暗号通信に関する「約束事」のことです。

• 暗号方式
• 鍵の種類
• 有効期間
• 通信方向（片方向ごとに管理）

👉 VPN設定時の show crypto isakmp sa の「SA」はこの意味。

NAT環境でVPNが動かない理由とNAT-T

家庭用ルータ配下からVPNを貼ろうとすると失敗することがあります。
その原因は NAT装置がESPパケットを変えてしまうから です。

これを解決するのが NAT Traversal（NAT-T） です。

✅ NAT-Tの動き（図解）

用語まとめ

次回予告

次回は、VPN設計編 として
✅ 暗号方式の選び方（AES vs 3DES）
✅ IKEv1とIKEv2の違い
✅ セキュリティと速度のバランス
✅ 実務で使われる設計パターン
をわかりやすく解説します。

どうも！リョクちゃです。

前回の「VPN基礎」では、VPNの概念や種類を解説しました。
今回は、Cisco IOSを例にしたVPNの設定手順と実際のコマンド出力例を紹介します。

実践環境の想定

• 本社ルータ（R1）：グローバルIP 203.0.113.1
• 支社ルータ（R2）：グローバルIP 203.0.113.2
• 社内ネットワーク：
  ・ R1側：192.168.10.0/24
  ・ R2側：192.168.20.0/24

IPsec VPN の設定例（Cisco IOS）

1. ISAKMPフェーズ1（IKE設定）

# 暗号化方式と認証設定
crypto isakmp policy 10
 encryption aes
 hash sha
 authentication pre-share
 group 2
 lifetime 86400

# 事前共有鍵（PSK）
crypto isakmp key vpnkey address 203.0.113.2

2. フェーズ2 (IPsec設定)

crypto ipsec transform-set MYSET esp-aes esp-sha-hmac
crypto map MYMAP 10 ipsec-isakmp
set peer 203.0.113.2
set transform-set MYSET
match address VPN_ACL

3. VPN対象トラフィックをACLで指定

ip access-list extended VPN_ACL
permit ip 192.168.10.0 0.0.0.255 192.168.20.0 0.0.0.255

4. インターフェースに適用

interface GigabitEthernet0/0
crypto map MYMAP

動作確認コマンド

ISAKMPセッションの確認

R1# show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
203.0.113.2     203.0.113.1     QM_IDLE        1001    ACTIVE

👉 QM_IDLE はPhase1とPhase2が正常に確立されている状態。

IPsecセッションの確認

R1# show crypto ipsec sa
local ident (addr/mask/prot/port): (192.168.10.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (192.168.20.0/255.255.255.0/0/0)
current_peer 203.0.113.2
#pkts encaps: 120, #pkts decaps: 118

👉 pkts encaps/decaps がカウントされていれば、実際に暗号化トラフィックが流れている。

トラブルシュートのヒント

実務Tips

• NATとVPNの競合に注意
  NATの除外設定（ip nat inside source ...）が必要な場合あり。

• MTU調整
  VPNトンネルでパケット断片化が起きる場合はMTU値を調整。

• ログ活用
  debug crypto isakmp や debug crypto ipsec は詳細な原因分析に有効（本番環境では慎重に使用）。

まとめ

• VPNは設定だけでなく状態確認コマンドの理解が重要
• Phase1（ISAKMP）とPhase2（IPsec）のどこで失敗しているかを切り分けるのが基本
• 本番環境では安全性と冗長性を意識しつつテスト環境での事前検証がおすすめ

👉 次回は「VPN運用のベストプラクティス」として、監視やログ管理、可用性向上策を紹介します。