カメラからイーサネットへ：ネットワーキングへの旅

この記事は、ある興味深いネットワークトラブルシューティングの旅の記録です。始まりは「産業用カメラをノートPCに接続する」という、一見単純な要求でした。この経験は、私を次から次へと失望と「アハ！」モーメント（発見の瞬間）へと導き、最終的にはネットワークの多くの核心的な概念を発見することになりました。

パート1：最初の失敗 - PoE#

私には「産業用カメラからノートPCへ画像データを取得する」という課題がありました。カメラが標準的なイーサネットケーブルであるRJ45ケーブルを使っていることに気づきました。

ごく自然なアイデア：カメラをノートPCのイーサネットポートに直接接続する。

しかし…何も起こりません。信号も、点滅するライトも、何もありません。奇妙なことに、このカメラをメーカー提供の小型PCクラスターに接続すると、正常にストリーミングされるのです。

しばらくいじくり回した後、私は問題が PoE (Power over Ethernet) にあることに気づきました。

PoEとは？#

PoEは、1本のイーサネットケーブルでデータと電力の両方を伝送できる技術です。産業用カメラ（や多くのIPカメラ、アクセスポイントなど）は、追加の電源ケーブルを引き回す必要がないように、しばしばPoEを使用します。

• 問題点： ノートPCや通常のPCは、イーサネットポート経由で電力を供給しません。
• （メーカーの）解決策： あの小型PCクラスターには、間違いなくPoEが組み込まれていたのです。
• 私の失望： 私が新しく購入したスイッチ（TL-SG1016D）は優れたアンマネージドスイッチでしたが、PoEをサポートしていませんでした。私は間違ったものを買ってしまったのです。TL-SG1016PE（"P"は通常PoEを意味します）のモデルを買うべきでした。

PoEインジェクターを注文して待つ間、私は自分のネットワークシステムをテストするために「サイドクエスト」を行うことにしました。

パート2：サイドクエスト - イーサネット経由のSSH#

私の部屋のWi-Fiは時々非常に弱く、ノートPC（Ubuntu）からPC（Ubuntu）へのSSHセッションが深刻に中断されます。

なぜPCを直接使わずにSSHなのか？ 私はノートPCの開発環境に慣れており、これはサーバー上での開発に慣れるのにも役立つからです。クラウド時代には重要なスキルです。

私は考えました：2台のPCをイーサネットで接続してはどうだろう？ きっと速くなるし、重要なのは…インターネットがなくても接続できる！

実験1：ノートPC $\rightarrow$ PC（直接） RJ45ケーブルで2台のPCを直接接続しました。そしてまた…何も起こりません。信号がありません。 ¹

実験2：ノートPC $\rightarrow$ スイッチ $\rightarrow$ PC TL-SG1016Dスイッチを中継役として使いました。今度は、スイッチと両方のPCの信号ランプが点灯しました！

両方のマシンで確認します：

# ノートPC
$ ip a
enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ...
       link/ether 60:18:95:56:8e:ff brd ff:ff:ff:ff:ff:ff
 
# PC
$ ip a
enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ...
       link/ether d8:43:ae:c7:d6:76 brd ff:ff:ff:ff:ff:ff

両方のネットワークカードが UP,LOWER_UP（つまり物理リンクはOK）です。しかし、ping も ssh もできません。

「アハ！」モーメント：スイッチはルーターではない

この時こそ、私が基本的な概念を理解した瞬間でした：

• スイッチ（アンマネージド - レイヤー2）： 私のスイッチはOSIモデルのレイヤー2（データリンク層）で動作します。MACアドレスのみに関心があります。ビル内の賢い郵便配達員のように、MACに基づいてデータフレームを転送します。
• 通信（レイヤー3）： ssh や ping をするには、コンピュータはIPアドレス（レイヤー3 - ネットワーク層を使って互いに通信する必要があります。
• 問題点： 私のデバイスには、このネットワーク上でのIPアドレスがありません！ 誰かがIPを割り当ててくれるのを待っている状態です。

私たちのほとんどは、接続すればすぐに使えることに慣れています。なぜなら、自宅（または会社）のルーターが、すべてのデバイスに自動的にIPを割り当てるDHCPサーバーと呼ばれるサービスを統合しているからです。私の「ダムな」（機能が限定された）スイッチにはその能力がありません。

解決策： 静的IP（Static IPの割り当て。 私はローカルネットワーク 10.0.0.0/24（プライベートIP範囲）を作成することにしました。

# ノートPC側
sudo ip addr add 10.0.0.1/24 dev enp2s0
sudo ip link set enp2s0 up
 
# PC側
sudo ip addr add 10.0.0.2/24 dev enp3s0
sudo ip link set enp3s0 up

そして…

# ノートPC側
$ ssh my-user@10.0.0.2
Welcome to Ubuntu ...

成功です！ 両方のマシンでWi-Fiをオフにしても、SSHセッションはスムーズです。

パート3：カメラへの再挑戦（民生用モデル）#

PoEインジェクターを待つ間、私は民生用のカメラ（Tapo）を取り出してテストしてみました。目標は、ローカルなRTSPストリームを設定することです。セキュア（メーカーのクラウドを経由しない）で、かつ高速です。

カメラをスイッチに接続しました。すると、深刻な問題が始まりました：

• 私はすでに 10.0.0.0/24 ネットワークを持っています（ノートPCは 10.0.0.1）。
• しかし、カメラには静的IPを割り当てるためのインターフェースがありません。それは「接続すればすぐに使える」ように設計されています。つまり、DHCPサーバーを期待しているのです。

この時点で、私のネットワークはノートPC（10.0.0.1）とカメラ（IPなし）で構成され、両方ともスイッチに接続されています。カメラが何をしているかを知るにはどうすればよいでしょう？

調査段階：ネットワークを盗聴する#

arp-scan ネットワーク内にデバイスがあるか確認するためにARPスキャンを試しました。ARP (Address Resolution Protocol) は、IP (レイヤー3) から MAC (レイヤー2) へのマッピングを助けるプロトコルです。

$ sudo arp-scan --interface=enp2s0 --localnet
...
Ending arp-scan 1.10.0: 256 hosts scanned in 1.842 seconds. 0 responded

何もありません。これは理にかなっています。カメラはまだIPを持っていないので、「IP...を持っているのは誰か」というARPパケットに応答できません。

tcpdump いよいよ、カメラの「助けを求める叫び」を聞く時が来ました。enp2s0 ポート上のすべてのパケットをキャプチャするために tcpdump を実行します。

$ sudo tcpdump -i enp2s0 -n
...
11:32:31.913390 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 8c:90:2d:13:ba:e6, length 285

これです！ 素晴らしい発見です。

DHCPDISCOVERパケットの解剖#

この「助けを求める」パケットを分析してみましょう：

• 11:32:31.913390：タイムスタンプ。
• IP 0.0.0.0.68：送信元。カメラはIPを持っていないので、0.0.0.0 を使用します。ポート 68 はDHCPクライアントのポートです。
• > 255.255.255.255.67：送信先。これはブロードキャストアドレスです。カメラはネットワーク上の全員に向かって「誰かDHCPサーバーはいませんか？」と「叫んで」います。ポート 67 はDHCPサーバーのポートです。
• Request from 8c:90:2d:13:ba:e6：このパケットはこのMACアドレスから送信されました。カメラの底面を確認すると、まさにこれでした！

これは、DORA と呼ばれる4ステッププロセスの最初のステップ、DHCPDISCOVER パケットです。

パート4：解決策 - ノートPCがDHCPサーバーになる#

もしカメラがDHCPサーバーを必要としているなら…私がDHCPサーバーになればいいのです。私のノートPC（Ubuntu）なら、まったく問題なくそれができます。

isc-dhcp-server をインストールし、/etc/dhcp/dhcpd.conf ファイルを設定しました。ランダムなIPを割り当てるだけでなく、このカメラを固定のIPに紐付けたいと思いました。

# /etc/dhcp/dhcpd.conf
default-lease-time 600;
max-lease-time 7200;
authoritative;
 
# 私のローカルネットワーク
subnet 10.0.0.0 netmask 255.255.255.0 {
  # この範囲でIPを割り当てる
  range 10.0.0.10 10.0.0.20;
  # ゲートウェイ（私のノートPC）
  option routers 10.0.0.1;
}
 
# ここが重要な部分：DHCP予約
# カメラのMACアドレスを
# 私が割り当てたい固定IPに紐付ける
host tapo_cam {
  hardware ethernet 8c:90:2d:13:ba:e6;
  fixed-address 10.0.0.50;
}

サービスを起動した後、ログを確認しました（journalctl -u isc-dhcp-server -f）：

Nov 08 11:37:28 midori dhcpd[12418]: DHCPDISCOVER from 8c:90:2d:13:ba:e6 via enp2s0
Nov 08 11:37:29 midori dhcpd[12418]: DHCPOFFER on 10.0.0.50 to 8c:90:2d:13:ba:e6 via enp2s0
Nov 08 11:37:29 midori dhcpd[12418]: DHCPREQUEST for 10.0.0.50 (10.0.0.1) from 8c:90:2d:13:ba:e6 via enp2s0
Nov 08 11:37:29 midori dhcpd[12418]: DHCPACK on 10.0.0.50 to 8c:90:2d:13:ba:e6 via enp2s0

DORAプロセスの完成#

このログは、4ステップのプロセスを正確に示しています：

• Discover: カメラ（8c:90:2d:13:ba:e6）が叫びます（DHCPDISCOVER）。
• Offer: 私のノートPC（dhcpd）が応答します：「あなたのためにIP 10.0.0.50 を用意しましたよ」（DHCPOFFER）。
• Request: カメラが確認します：「素晴らしい、IP 10.0.0.50 をお願いします」（DHCPREQUEST）。
• Acknowledge: ノートPCが確定します：「OK、IP 10.0.0.50 はあなたのものです」（DHCPACK）。

そして結果は：

# ノートPC側
$ ping 10.0.0.50
PING 10.0.0.50 (10.0.0.50) 56(84) bytes of data.
64 bytes from 10.0.0.50: icmp_seq=1 ttl=64 time=1.56 ms

成功しました！ カメラはIPを取得し、私は rtsp://<user>:<pass>@10.0.0.50:554/stream 経由でストリームを見ることができます。

結論#

PoEという一見単純な失敗から始まった私は、静的IP、スイッチ/ルーターの区別、tcpdump でのパケット分析、そして最終的には静的予約を持つDHCPサーバーを自作するという一連の旅をしました。

この旅は、ネットワークの各層（レイヤー）を理解することが単なる抽象的な理論ではなく、最も強力なトラブルシューティングツールであることを私に思い出させてくれました。

さて…あの産業用カメラが、このカメラのように「行儀よく」DHCPを待っていてくれるかどうかは分かりません。しかし、それは私のPoEインジェクターが到着する日の物語です。