演習進捗 0 / 5 未完了
⏱ 約 90 分 · Part 2 修了演習
Part 2Chapter 06/ネットワーク基礎 集大成

修了演習:経路を組み立てて curl でゴールまで届かせる

VLAN10 の受講者VMから、VLAN20 の webserver01 へ到達するまでを一気通貫で確認します。IP、ARP、VLAN、経路の選ばれ方、tc、iptables を1本の経路に束ね、最後に curl で nginx のゴール画面を取りにいきます。OSPF はこの経路の外側で、ルータ同士が経路を学ぶ様子を観察します。

教材は登録なしで読めます。実機でコマンドを試す場合のみ、Google ログインで2時間枠の予約が必要です。
この章は 90 分想定の総合演習です。1 回で完走しなくても大丈夫です。STEP 04 まで、STEP 08 まで、最後まで ── のように区切って進めてください。詰まったら無理をせず、時間を置いて再開してください。
所要時間約 90 分(11 ステップ + 任意の発展)
章タイプlab
前提知識Part 2 Chapter 1-5(IP / ARP / VLAN / ルーティング / iptables と tc netem)
使用機材workstation01ssh student@learner01、到達先: webserver01 172.16.20.10
関連章前: Chapter 5「iptables と tc netem」/ 次: Part 2 修了

Ch1-5 を1本の経路にまとめる

この章でできるようになることは、「IP を付ける」から「HTTP でゴールに届く」までを、途中の失敗も含めて説明できることです。ゴールは learner01 から VLAN20 の webserver01curl し、nginx の見出しを取得することです。

受講者が打つのは learner01 側の ip / ping / curl / tcpdump / tc / iptables までです。router 側の vtyshshow ip ... は、管理者が取得済みの出力を 観察パネル として読みます。

Part2 実機トポロジ
VLAN10 (172.16.10.0/24)  オフィス
  learner01 / 受講者VM
        |
        | default gateway = l3router01 172.16.10.1
        |
  l3router01 172.16.20.1
        |
        | VLAN20 (172.16.20.0/24)  サーバ網 兼 ルータ間 transit
        |   webserver01 172.16.20.10
        |   core01      172.16.20.2
        |
  core01 172.16.30.1
        |
VLAN30 (172.16.30.0/24)  Part3 の DB セグメント(ここでは経路のみ観察)
VLAN10learner01 172.16.10.20/24
GWl3router01 172.16.10.1
VLAN20webserver01 172.16.20.10
OSPF RIDl3router01 172.16.20.1
VLAN20 transitarea 0 neighbor Full
OSPF RIDcore01 172.16.20.2
ゴール: curl http://172.16.20.10/<h1>Welcome to nginx on server-segment!</h1> を取得し、途中で起きる GW 未設定ICMP block経路未学習 を切り分けられる状態にします。

この章を終えるとできること

ネットワーク到達を作る 4 動作を、1つのストーリーで確認します。

$ ip addr
172.16.10.20/24
dev ens20.10
① 置く
受講者VMを
VLAN10 に置く
ip addr
$ ip route
default via 172.16.10.1
ping 172.16.20.10
② 出す
町の外へ出る道を
GW に向ける
ip route
State Full/DR
O>* 172.16.30.0/24
via 172.16.20.2
③ 読む
router 出力から
動的経路を読む
観察パネル
tc delay 100ms
iptables ICMP block
curl 200 OK
④ 揺らす
遅延と遮断を
結果から切り分ける
tc · iptables

使う道具の早見表

この修了演習では、Part 2 の各章で使った道具を順番に呼び戻します。

Ch1 · IPip addr / ip route で自分の位置と出口を確認します。
Ch2 · ARPip neigh で同じ VLAN10 にいる l3router01 の MAC 解決を見ます。
Ch3 · VLANTL-SG108E の空き access 設定と、learner01 の ens20.10 が扱うタグを比較します。
Ch4 · Routingdefault GW と OSPF の観察パネルで、手書きでない道を読みます。
Ch5 · 障害体験tc で遅延、iptables で ICMP block を入れて戻します。

演習:curl ゴールまで11ステップで進む

項目
操作ホストlearner01(受講者VM / VLAN10 / 172.16.10.20/24
接続方法workstation01 から ssh student@learner01
ゴールcurl http://172.16.20.10/Welcome to nginx on server-segment!
観察対象l3router01core01 の FRRouting 出力(受講者は実行しない)
必要権限受講者側は一部 sudo を使います。router の vtysh / show ip ... は観察のみです。
演習の安全範囲: 受講者が変更するのは learner01 の一時的な IP / route / tc / iptables です。2回目に既に設定済みなら、File exists や同じ成功結果が出ることがあります。その場合は「設定済み」と判断して確認ステップへ進みます。

IP を置く → curl 到達までをライブビューで通しで見る

詰まったときは、受講者が実際に打つコマンドと実機の実行結果をここで再生できます(速度変更・ステップ停止つき)。各 STEP の「▶ ここを再生」を押すと、その場面から再生します。

STEP 01 · learner01 に入り、NIC を確認する

受講者の出発点は workstation01 です。パスワード SSH で learner01 に入り、NIC 名と現在のアドレスを見ます。

bash · workstation01 から SSH
ssh student@learner01
bash · learner01
hostname
ip -br addr
# 例:
# learner01
# lo        UNKNOWN 127.0.0.1/8 ::1/128
# ens18     UP      192.0.2.203/24
# ens20.10  UP      172.16.10.20/24

NIC 名は環境で ens20.10 以外になることがあります。以降の例では ens20.10(VLAN10 サブインターフェース)と書きますが、自分の表示に合わせて読み替えます。
ここで出てくる ens18 は SSH 接続を保つための管理用 NIC です。Part 2 の演習で主に見る ens20.10 とは役割が違います。表示中の IP はいずれも例示です。

STEP 02 · TL-SG108E の空き access 設定と演習経路を比べる

ここは受講者が Linux で打つ操作ではありません。Ch3 の復習として、TL-SG108E の Port 5・6 は VLAN10 access 設定だが現在は接続先なしで、将来の物理端末用だと読みます。演習の VM 間通信は learner01 の ens20.10 → VM-103 の net2 → vmbr2 → l3router01 / webserver01 と進みます。

観察 TL-SG108E · VLAN10 access port
VLAN ID: 10
Port role: access / untagged
PVID: 10
Connected host: 接続先なし(将来の物理端末用)

物理 access ポートではスイッチ側がタグなしフレームを VLAN に割り当てます。一方、この演習の learner01 は物理 access ポートへ接続されておらず、自身の 802.1Q サブインターフェース ens20.10 でタグを扱います。TL-SG108E の Port 3 にある VLAN10 / VLAN20 trunk 設計は、複数 VLAN を物理配線へ運ぶ場合との比較として読みます。

STEP 03 · NIC が VLAN10 の IP を持っていることを確認する

learner01 の NIC が VLAN10 のアドレス(172.16.10.x/24)を持っていることを確認します。修了演習では 自分がつないでいる NIC を作り直すと SSH が切れるため、ここでは確認に徹します。

bash · learner01
IF=ens20.10
ip -br addr show dev $IF
# → ens20.10 UP 172.16.10.20/24  (VLAN10 のIPが付いていればOK)
IP を付け替えて試したいとき: ip addr fluship addr add でアドレスを入れ替える実験は、SSH 経由だと自分の接続が切れます。試す場合は noVNC コンソール(画面から直接)で行ってください。

STEP 04 · l3router01 へ ping し、ARP を見る

まず同じ VLAN10 にいるゲートウェイ 172.16.10.1 へ届くかを確認します。成功したら ip neigh で ARP 解決も見ます。

bash · learner01
ping -c 3 172.16.10.1
ip neigh show 172.16.10.1
# 例:
# 172.16.10.1 dev ens20.10 lladdr bc:24:11:aa:bb:cc REACHABLE

REACHABLESTALE が見えれば、learner01 は l3router01 の MAC アドレスを知っています。ここまでは同じ VLAN10 の L2 到達です。

STEP 05 · VLAN20 宛の経路を外す ── それでも default があると偶然届く

ここでは、VLAN20 宛の明示的な経路を消したあと、すぐには失敗しないことを確かめます。宛先ごとの経路が無くても、default(最後の受け皿)が残っていれば、そちら経由で偶然届いてしまうからです。「なぜ届くのか」を体で覚えてから、default も外して本当の失敗を作ります。

SSH には影響しません: これから消すのは ens20.10(ラボ側)の経路です。learner01 への SSH は管理用インターフェース ens18(管理用ネットワークの直結経路)を通っているため、ラボ側の default を消しても接続は切れません。(これは経路削除の話です。Ch5 で扱った tc netem の遅延とは別の操作です。)
bash · learner01
sudo ip route del 172.16.20.0/24
ip route
ping -c 3 172.16.20.10
# default via 172.16.10.1 dev ens20.10   ← 20 宛の経路は消えたが default は残る
# 64 bytes from 172.16.20.10: icmp_seq=1 ttl=63 time=...   ← まだ届く!
なぜ消したのに届くのか: ルーティングは「宛先に最も具体的に一致する経路」を選びます(ロンゲストマッチ)。172.16.20.0/24 を消すと、次に一致するのは default(=0.0.0.0/0、すべての宛先の受け皿)です。今回の default はたまたま 172.16.10.1(同じ l3router01)向きなので、専用の経路が無くても default 経由で偶然 VLAN20 に届いてしまうのです。「経路を消したのに繋がる」ときは、この default の存在を疑います。

では、default も一時的に外して、本当に出口が無い状態を作ります。

bash · learner01
sudo ip route del default
ping -c 3 172.16.20.10
# → ping: connect: ネットワークに届きません
# (Network is unreachable)
失敗を確認する STEP

この失敗が正解です。172.16.20.10 は VLAN20 の宛先で、専用経路も default も無いいま、出ていく道が一本もありません。次の STEP で両方を戻します。

STEP 06 · 消した 2 つの経路を戻して成功させる

外した default と VLAN20 宛の経路を、どちらも l3router01 172.16.10.1 経由で戻し、同じ ping を再実行します。失敗から成功に変わる点を確認します。

bash · learner01
sudo ip route add default via 172.16.10.1 dev ens20.10
sudo ip route add 172.16.20.0/24 via 172.16.10.1 dev ens20.10
ip route
ping -c 3 172.16.20.10
# 64 bytes from 172.16.20.10: icmp_seq=1 ttl=63 time=...

ttl=63 のように 1 つ減っていれば、l3router01 を1回またいで届いていると読めます。既に経路が設定済みの場合は RTNETLINK answers: File exists と表示されますが、ip route で両方見えていれば問題ありません。(再起動すれば netplan の設定から元の経路が復元されます。)

戻した経路には proto static が付きません: 最初に ip route を見たとき、2行には proto static という表示が付いていました。手で ip route add した経路にはこれが付きません。proto は「誰がこの経路を入れたか」を示す出自の記録で、static は netplan などの設定ツールが入れたことを意味します。あなたが手で入れた経路は出自が違うので表示も違う、というだけです。通信のしかたは変わりませんし、経路の選ばれ方にも影響しません。元の表示に戻したいときは再起動してください。

STEP 07 · OSPF neighbor Full を観察する

ここからは router 側の観察です。vtysh は router 上の管理CLIなので、受講者は実行しません。l3router01 と core01 が VLAN20 上で OSPF neighbor になっている証拠を読みます。

観察 l3router01 · show ip ospf neighbor(管理者が 2026-08-01 に取得した出力・現在値ではありません)
Neighbor ID     Pri State           Dead Time Address         Interface
172.16.20.2       1 Full/DR         00:00:3x  172.16.20.2     eth2:172.16.20.1
  • Neighbor ID 172.16.20.2: 相手は core01(RID 172.16.20.2
  • State Full/DR: OSPF neighbor が成立済み(完全隣接)
  • Address 172.16.20.2: VLAN20 上で隣り合っている
VLAN20 の二役を再確認: VLAN20 は webserver01 172.16.20.10 がいるサーバ網であり、同時に l3router01 172.16.20.1core01 172.16.20.2 が話す transit でもあります。

STEP 08 · 手で書いていない OSPF 経路を読む

l3router01 の経路表に、VLAN30 への道が OSPF 由来で生えています。受講者は静的経路を1行も書いていません。出力から、core01 経由で VLAN30 へ行く道を読みます。

観察 l3router01 · show ip route(管理者が 2026-08-01 に取得した出力から抜粋・現在値ではありません)
Codes: K - kernel route, C - connected, S - static, O - OSPF, B - BGP

C>* 172.16.10.0/24 is directly connected, eth1
C>* 172.16.20.0/24 is directly connected, eth2
O>* 172.16.30.0/24 [110/2] via 172.16.20.2, eth2, weight 1

O>*O は OSPF 由来、via 172.16.20.2 は core01 の VLAN20 側 IP です。発展Aでは、この経路を core01 側の経路表と読み比べ、手で書いていない経路が隣接から学習されることを観察します。

この経路は、この章のゴールでは使いません: ここで読んだ OSPF 経路は 172.16.30.0/24(VLAN30)へ行くためのものです。一方、最後の STEP で curl する相手は webserver01 172.16.20.10VLAN20 にいます。つまり curl が成功しても、それは OSPF が動いている証拠にはなりません。ここで観察しているのは「ルータ同士が、人間が書いていない経路をお互いに教え合っている」という別の事実です。両者を混ぜないでください。

STEP 09 · tc netem で100ms遅延を注入する

Ch5 の復習です。learner01 側で一時的に netem delay 100ms を入れ、webserver01 への ping RTT が増えることを観察します。最後に必ず解除します。

bash · learner01
IF=ens20.10
ping -c 3 172.16.20.10
sudo tc qdisc replace dev $IF root netem delay 100ms
ping -c 3 172.16.20.10
sudo tc qdisc del dev $IF root 2>/dev/null || true
# → delay 注入後の time= が、おおむね 100ms 分大きくなる
2回目の見え方: tc qdisc delNo such file or directory が出る場合は、解除済みです。最後に ping が通常の RTT に戻れば問題ありません。

STEP 10 · iptables で VLAN20 への ICMP を止め、解除する

今度は iptables で VLAN20 宛ての ICMP を止めます。ping が失敗することを確認し、すぐに同じルールを削除して復旧します。

bash · learner01
sudo iptables -I OUTPUT -d 172.16.20.0/24 -p icmp -j DROP
ping -c 3 172.16.20.10
# → 100% packet loss
sudo iptables -D OUTPUT -d 172.16.20.0/24 -p icmp -j DROP
ping -c 3 172.16.20.10
# → 64 bytes from 172.16.20.10 ...
失敗から復旧までを1セットにする

この失敗は「道がない」ではなく「自分の出口で ICMP を捨てている」状態です。解除後に ping が戻れば、経路そのものは壊れていないと切り分けられます。

STEP 11 · 最終ゴール:curl で nginx に届く

最後に HTTP で webserver01 へ届くことを確認します。ping が通るだけでなく、実際のサービスからHTMLを取れることが Part 2 のゴールです。

bash · learner01
curl http://172.16.20.10/
<h1>Welcome to nginx on server-segment!</h1>
Part 2 修了: VLAN10 の受講者VMから、VLAN20 の webserver01 まで HTTP で届きました。途中の ARP、経路、遅延、ICMP block も、どこを見るかを説明できます。
いま使われている経路はどれか: STEP 06 で 172.16.20.0/24 宛の経路を戻したので、この curl で選ばれているのはその行です。default ではありません(STEP 05 で default だけを残したときも届きましたが、あのときとは選ばれている経路が違います)。ip route をもう一度実行して、172.16.20.0/24 の行が戻っていることを確かめてください。
なお OSPF はこの curl には関与しません。STEP 07・08 で観察したのは VLAN30 宛の経路で、ここでは通りません。

詰まりやすい所の切り分け

修了演習で大事なのは、失敗したときに「どの層で止まっているか」を狭めることです。まず下の3つに分けます。

3 大エラー早見表
症状見る場所判断
Network is unreachableip routedefault GW 未設定の可能性が高い。default via 172.16.10.1 を確認。
ping 100% packet loss だが curl は別結果iptables -SICMP だけ block している可能性。OUTPUT の DROP ルールを確認。
VLAN30 の経路が見えない観察パネルの O>* 172.16.30.0/24OSPF 経路未学習または core01 側の問題。受講者は router sudo せず、両側の観察出力を読む。
VLAN20 宛の経路がないか確認する

ip route172.16.20.0/24 への経路がなければ、VLAN20 へ出る道がありません。次のコマンドで追加します。

bash · learner01
ip route
sudo ip route add 172.16.20.0/24 via 172.16.10.1 dev ens20.10
ICMP block が残っていないか確認する

STEP 10 の DROP ルールが残っていると ping だけ失敗します。解除コマンドは同じ条件で -D です。

bash · learner01
sudo iptables -S OUTPUT
sudo iptables -D OUTPUT -d 172.16.20.0/24 -p icmp -j DROP 2>/dev/null || true
経路未学習を疑うときの見方

VLAN30 の経路が見えない場合は、learner01 で無理に router へ入らず、観察パネルで O>* 172.16.30.0/24 via 172.16.20.2 が出ているかを見ます。出ていなければ OSPF 側の問題です。

観察 l3router01 · 期待する経路
O>* 172.16.30.0/24 [110/2] via 172.16.20.2, eth2, weight 1

発展:OSPF / BGP を本物として確認する

発展A · OSPF 経路学習を両側の経路表で観察する

ここでは VLAN30 のホストへ ping しません。VLAN30 / DB セグメントは Part3 で扱い、この章では経路表だけを観察します。

読むポイントは、静的経路を1行も書いていないのに、OSPF neighbor から学習した経路が経路表に現れることです。

観察 l3router01 · show ip route(抜粋)
O>* 172.16.30.0/24 [110/2] via 172.16.20.2, eth2, weight 1

l3router01 側の O>* は、VLAN30 の経路を OSPF で学習し、次ホップが core01 の VLAN20 側 172.16.20.2 であることを示します。

観察 core01 · show ip route(抜粋)
C>* 172.16.30.0/24 is directly connected, eth2
O>* 172.16.10.0/24 [110/2] via 172.16.20.1, eth1, weight 1

core01 側では VLAN30 が C>* の直結として見え、逆向きに VLAN10 を O>* で学習しています。片側では「学習」、反対側では「直結」として読むのがこの観察のポイントです。

発展B · BGP Established を観察する

BGP は受講者が実行するコマンドではなく、観察パネルで読みます。l3router01AS65001core01AS65002 です。OSPF は組織内、BGP は組織間の経路交換として対比します(本ラボは学習用に、同じ2台で OSPF と eBGP を併走させた割り切り構成です)。

観察 l3router01 · show ip bgp summary(管理者取得済み出力から抜粋)
Local AS number 65001
Neighbor        V         AS   MsgRcvd MsgSent   Up/Down State/PfxRcd
172.16.20.2     4      65002        xx      xx   00:xx:xx 1

FRR の summary では、Established になると State/PfxRcdそのネイバーから受信した経路数が出ます。ここでは core01(AS65002)が 172.16.30.0/24 を1本広告しているので、PfxRcd1 と読めれば BGP セッションは成立済みです。経路ビューで復習するときは、🛰 ライブビュー(動的ルーティング) の OSPF 表示と対応づけてください。

AI に相談

AI curl ゴールまでの切り分けを質問できます
この章の実機トポロジを前提に、到達確認の切り分けを説明します

修了確認

Part 2 の修了演習を締めくくる確認です。2 問だけ、原因と証拠を結びつけます。

問 1 · GW 未設定と ICMP block の違い

ping 172.16.20.10 が失敗しました。ip routedefault via 172.16.10.1 がない場合と、iptables の OUTPUT に ICMP DROP がある場合では、原因はどう違いますか?

解答を見る

GW 未設定は、VLAN10 から VLAN20 へ出る道そのものがない状態です。ip routedefault via 172.16.10.1 が見えません。

ICMP blockは、道はあるが learner01 の出口で ICMP を捨てている状態です。iptables -S OUTPUT-d 172.16.20.0/24 -p icmp -j DROP が残っていないかを見ます。

問 2 · OSPF 経路を読む

次の 1 行を見て、(a) どのプロトコルで学習した経路か、(b) 次に渡す相手はどの IP か、(c) 発展Aでは core01 側のどの行と読み比べるか、を答えてください。

O>* 172.16.30.0/24 [110/2] via 172.16.20.2, eth2, weight 1
解答を見る

(a) O なので OSPF です。

(b) via 172.16.20.2 なので、次に渡す相手は core01 の VLAN20 側 IP です。

(c) core01 側の C>* 172.16.30.0/24 is directly connected, eth2 と読み比べます。l3router01 では OSPF 学習、core01 では直結として見えるのが対比です。

💡 修了確認の段階ヒント(問 1・問 2 共通)

💡 段階ヒント 1 段目:まず見るコマンドを分ける
道がないかを見るなら ip route、自分で捨てていないかを見るなら iptables -S OUTPUT、router の自動経路を見るなら観察パネルの show ip route です。
💡 段階ヒント 2 段目:IP をトポロジに戻す
172.16.10.1 は l3router01 の VLAN10 側、172.16.20.10 は webserver01、172.16.20.2 は core01 の VLAN20 側、172.16.30.0/24 は Part3 で扱う VLAN30 / DB セグメントです。
💡 段階ヒント 3 段目:失敗の種類を名前で呼ぶ
GW 未設定は「町の外に出る出口がない」、ICMP block は「出口で ping だけ捨てている」、経路未学習は「router が奥の町への道を知らない」です。名前を分けると、直す場所も分かれます。

Part 2 修了と次の入口

この章で、Part 2 のネットワーク基礎は一区切りです。IP を付ける、ARP を見る、VLAN を意識する、経路表を読んでルータへ渡す、OSPF の証拠を読む、遅延や遮断を体感する、最後に HTTP サービスへ届く、という流れを1回通しました。

次の Part では、このネットワークの上でサービスを動かす視点に進みます。curl で取れた1行は、今後扱う Web サーバ、ログ、監視、障害対応の入口です。

持ち帰る言葉:
  • 同じ VLAN なら ARP で直接、別 VLAN なら経路表に従ってルータへ渡す(専用の経路があればそれが選ばれ、無ければ default)
  • OSPF の O>* は、手で書いていない道が生えた証拠
  • ping 失敗は原因名を分ける。GW 未設定、ICMP block、経路未学習は直す場所が違う