ARPの動作フローとIPアドレス設計（同一LAN誤認トラブルの回避）

IPアドレスだけではLAN内でデータを送信できません。最終的にイーサネット上でデータを届けるには物理アドレス（MACアドレス）が必要であり、これを解決するプロトコルがARP（Address Resolution Protocol）です。

1. ARPの基本

同じLAN（サブネット）内の機器へ通信する際、送信元は「指定IPアドレスを持つ機器のMACアドレス」をLAN全体に問い合わせます（ARPリクエスト / ブロードキャスト）。

該当するIPを持つノードのみが、自身のMACアドレスを一対一で返答します（ARPリプライ / ユニキャスト）。

インターネットを超えた通信において、パケットヘッダのMACアドレスとIPアドレスがどう変化するかを整理します。

サブネット判定（送信元PC）:
宛先IP（10.0.0.100）から同一LAN外と判断し、デフォルトゲートウェイ（192.168.1.1）宛への送信を決定します。
自分側LANでのARP（送信元PC）:
ルーターのMACを得るため、LAN内にARPリクエスト（ブロードキャスト）を送信します。「192.168.1.1のMACを要求」→ ルーターがARPリプライでBB:BB:BBを応答します。
パケット送信（PC → 自分側ルーター）:
宛先IP: 10.0.0.100 / 宛先MAC: BB:BB:BB（ルーター）で送信します。
ルーティングとMAC付け替え（自分側ルーター）:
宛先IP（10.0.0.100）は固定のまま、宛先MACを「次のルーターのMAC」へ、送信元MACを「CC:CC:CC」へ書き換えて転送します。
相手側LANでのARP（相手側ルーター）:
相手側ルーターがデータを受信します。自LAN内（10.0.0.0/24）の10.0.0.100のMACを得るため、相手側LAN内で新たにARPブロードキャストを実行し、サーバーのMAC（FF:FF:FF）を取得します。
サーバー到達（相手側ルーター → サーバー）:
宛先IP: 10.0.0.100 / 宛先MAC: FF:FF:FF に書き換えて最終到達します。

家庭用ルーターなどでは「LAN内＝192.168.x.x」という構成が一般的ですが、前述の例で相手側を10.0.0.100としたのには理由があります。双方のLANが同じ192.168.1.x帯を使っていると、通信上のトラブルが発生するためです。

PCは宛先IPが自分と同じネットワーク（プレフィックス）であると、「同じLANの中に相手がいる」と判断し、ルーターを経由させずにLAN内で直接ARPを送って探そうとする仕組みを持っています。

ネットワーク設計の定石: 一般家庭で多用される192.168.0.xや192.168.1.xとの重複を避けるため、サーバー側や企業内LANにはあらかじめ10.x.x.x帯や172.16.x.x帯を採用するのが定石となっています。
家庭環境でのNAS構築と仮想VPNの活用: 一般家庭で外出先からアクセスできるNASを構築したい場合、デフォルトの192.168.x.xのアドレス構成のままだと外出先からのVPNアクセス時にIPが被って上手く通信できません。本来ならNASのために自宅ローカルIPの振り方自体を変更すべきですが、「家庭内LANのIPアドレスが192.168.x.xじゃないのはなんとなく収まりが悪い（気持ち悪い）」と感じる人も多いはずです。そこでTailscaleなどの仮想メッシュVPNサービス（100.64.0.0/10帯という特殊な仮想IPを使用）を導入することで、自宅のアドレス設定を変更せずに物理IPの重複事故をきれいに回避できます。

ネットワーク通信は、最終目的地を指定するレイヤー3（IP）と、隣のノードへパケットを渡すレイヤー2（MAC/ARP）の組み合わせで動いています。

IPアドレスの範囲設計を意識しておくことは、VPN接続やローカル開発環境（Docker等）での疎通トラブルを防ぐ上で必須の知識となります。