設定例を読めても、自分で通信を試せる場所がないと、値を変えた結果が分かりにくいですよね。検証環境は、機器をたくさん並べるより、「何を確かめるか」を一つ決めて作ると使いやすくなります。
最初はPCから別LANのWebサーバーへ接続する、小さな構成で十分です。実機、Packet Tracer、GNS3、EVE-NGは、再現できるものと準備が違います。目的に合う環境を選び、正常な状態を作ってから一つの条件を変えてみましょう。
道具は、試したい動作から選ぶ
配線、光モジュール、リンク速度を確かめたいなら、その物理条件を持つ実機が必要です。VLANや経路の基礎を練習するなら、Packet Tracerのような学習用環境から始める方法があります。
GNS3やEVE-NGでは仮想機器を組み合わせられますが、仮想版と実機版で機能や転送性能が同じとは限りません。利用するイメージの提供条件も確認します。
| 環境 | 最初に選ぶ目的 | 確認が難しいこと | 準備するもの |
|---|---|---|---|
| 実機 | 配線、リンク、SFP、コンソール、対象機種の操作 | 本番と異なる型番・OS・負荷の動作 | 機器、ケーブル、電源、接続手段 |
| Packet Tracer | Ciscoネットワークの基礎を小さく再現 | 実OSの全機能、不具合、実機の処理性能 | 学習に必要な機能があること |
| GNS3 | 仮想アプライアンスと端末・サーバーの連携 | ASICや物理ポート固有の動作 | 対応イメージ、利用権、CPU・メモリ |
| EVE-NG | サーバー上で複数ノードのラボをまとめる | 物理障害、本番負荷の保証 | 仮想化対応、イメージ、版・ライセンス、アクセス管理 |
EVE-NGは旧版を前提にした記事もあるため、公式のダウンロード案内で現在の版、ライセンス、サポートを確認します。環境名だけで決めず、必要な機能を使えるかを先に調べてください。
最小構成は、二つのLANと一台のルーター
図ではPC-Aを172.27.81.15/24、サーバーを172.27.92.25/24へ置き、R1で二つのLANをつなぎます。PCのゲートウェイは172.27.81.1、サーバーは172.27.92.1です。
R1は両LANへ直接接続するため、基本例ではその二つの接続経路を持ちます。最初からNATや複雑な冗長化を追加しないので、端末設定とルーティングの関係を見やすくなります。
| 対象 | IP・接続 | 役割 |
|---|---|---|
| PC-A | 172.27.81.15/24、GW 172.27.81.1 | 試験の送信元 |
| SW1 | PC側をVLAN81のaccessポートへ | 端末LANのL2接続 |
| R1 Gi0/0 | 172.27.81.1/24 | 端末のゲートウェイ |
| R1 Gi0/1 | 172.27.92.1/24 | サーバーLANへ接続 |
| Webサーバー | 172.27.92.25/24、GW 172.27.92.1 | HTTPSの待受と応答 |
ゲートウェイは、自分と別のネットワークへ送るときに最初に渡す相手です。PCとサーバーで、それぞれ自分のLAN側のR1を指定します。
実際のIF名は起動した機器で確認し、図へ書きます。ラボ内のIPと、仮想環境を動かすPC自身のIPも区別してください。
正常に動く基準を作ってから、一つずつ変える
まず両端のIP・マスク・ゲートウェイと、R1の状態を確認します。次にPCからサーバーへ、IPの到達、TCP接続、HTTPSの応答を段階ごとに見ます。
正常な結果を保存したら、ゲートウェイを変える、ACLで対象の通信を止めるなど、一つの条件だけを変えます。何が変わったかを説明しやすくするためです。
- 目的を「PC-AからWebサーバーへHTTPSで応答を得る」と書く。
- 機器・OS・インターフェース・IP・GWを図と表へ記録する。
- SW1のVLANとポート、R1のIPとインターフェース状態を設定する。
- サーバーにHTTPSサービスを用意し、ホスト側の制御と証明書を確認する。
- PCから経路・TCP接続・HTTPS応答を確認し、正常時の出力を保存する。
- R1の検証用ACLでTCP/443だけを拒否し、変わった症状を記録する。
- 変更を戻し、同じ操作でHTTPS成功まで再確認する。
R1で接続・経路を確認する例
show ip interface brief
show ip route 172.27.92.25
show ip arp
WindowsのTCP確認例
Test-NetConnection 172.27.92.25 -Port 443TCP443へ接続できたことは、TLSの証明書やHTTPの応答まで正常という意味ではありません。ブラウザーやcurlで、期待する応答を確認します。
変更後に失敗したら、正常時の設定と出力へ戻って比較します。設定を次々に足すより、失敗を生んだ差を一つ特定する練習になります。
試験表には、予想と実際の結果を別に書く
期待結果は実行前の予想、実結果は観測した事実です。「通るはず」をそのまま実結果へコピーすると、確認したことが分からなくなります。
試験ごとに、操作、送信元、宛先、時刻、出力、合否を書きます。失敗を作る試験なら、どの設定で止まる予定か、どの証拠を取るかも決めます。
| 試験 | 操作 | 期待結果 | 残す証跡 |
|---|---|---|---|
| T-LAB-01 | HTTPSの要求 | TCP・TLSが成立し、想定するHTTP応答 | 端末出力、サーバーログ |
| T-LAB-02 | R1でTCP/443を拒否した後、同じ要求 | 要求が成立せず、対象ACLへ一致 | ACLの増分、取得点のパケット |
| T-LAB-03 | ACL変更を元へ戻し、再度要求 | T-LAB-01と同じ条件で成功 | 設定差分、端末出力 |
表は計画の例です。自分の環境で取得した値を別に記入してください。設定を戻したあと、元の通信が復旧することまで確認します。
目的、図、設定、結果がそろうと、あとから同じ検証をやり直せます。面接でも、個人検証として何を理解したかを説明する材料になります。
ラボで確認できないことも、結果として残す
仮想環境で経路を確かめても、光配線、実機の転送性能、停止時間、現地作業まで確認したことにはなりません。検証した範囲と、本番で追加確認する範囲を分けます。
本番とOSや機種が違えば、その差も記録します。同じコマンドが通っただけで、本番と同じ挙動と決めないようにします。
| 差 | ラボで確認できたこと | 本番前に追加確認すること |
|---|---|---|
| 機種・OS | 使用した仮想版での設定と通信 | 対象機種の構文、既知不具合、利用機能 |
| 冗長化 | 単体R1での経路と制御 | 2台の切替、戻り経路、セッション維持 |
| 性能 | 少量の通信の成立 | 帯域、同時接続数、CPU、キュー |
| 外部連携 | 模擬Webサーバーの応答 | DNS、証明書、実アプリ、監視 |
検証の目的は立派な環境を作ることより、一つの疑問へ結果で答えることです。まず最小構成で正常・失敗・復旧を確かめ、必要になった機能を順に増やしましょう。
本番の環境が借りられない場合でも、図と設定のレビュー、公式仕様との比較など、できた確認と残る確認を分けて準備できます。
動画・筆者の投稿で補足する
文章と図で流れをつかんだら、関連する動画も参考にしてください。画面の表示や操作は、機種・ソフトウェアの版によって異なる場合があります。
