☰

apipaとのインターフェース（例：169.254.xx）

tag-icon • tag-icon networking routing networkmanager internet tcp-ip
apipaとのインターフェース（例：169.254.xx）

2つのインターフェース（eth0とeth1）を持つUbuntuシステムがあります。 Eth0インターフェイスにはdhcpアドレスがあり、eth1にはapipa（169.254.xx）アドレスがあります。 eth1は接続されておらず、eth0はローカルネットワークに接続されています。私のデスクトップ（同じネットワークに接続されている）では、169.254.xxアドレスでpingを実行し、scpなどを実行できます。

どうやってこれができますか？ルーティングが有効になっていません。

ベストアンサー1

もう一度確認するには：APIPAMicrosoftの元の命名法であり、次のように標準化されています。IPv4リンク - ローカルアドレスの動的構成(IPv4LL).

起こり得る状況は次のとおりです。

  • デスクトップ自体にはIPv4LL LANへのパスがあり、おそらくプライベートLAN 192.168.1.0/24など、Ubuntuが使用するのと同じDHCPを介してより「古典的な」パスに追加されます。

  • Ubuntu自体にはIPv4LLアドレスがありますイーサネット1、たとえば、169.254.5.6

  • デスクトップがオンライン（直接アクセス可能）なので、169.254.5.6を探している場合は、169.254.5.6へのARP要求をブロードキャストに送信します。

  • Ubuntuはブロードキャストを受信します。 Linuxホストとしては次のようになります。弱いホストモデル：インターフェースに追加されたIPアドレスは、そのインターフェースではなくホストに属します。これはIPv4にも当てはまります。そしてARPの場合は、文書に記載されているようにarp_filter環境：

arp_filter- ブール値

[...]

0-（デフォルト）カーネルは、他のインターフェイスのアドレスでarp要求に応答できます。。これは間違っているように見えるかもしれませんが、成功したコミュニケーションの可能性を高めるので、しばしば意味があります。 IP アドレスは、特定のインターフェイスではなく Linux のホスト全体が所有します。この動作は、ロードバランシングなどのより複雑な設定でのみ問題を引き起こします。

したがって、169.254.5.6に割り当てられたARP要求に応答します。イーサネット1しかし、時イーサネット0リクエストする場合イーサネット0イーサネットMACアドレス。

  • デスクトップはレイヤ2イーサネットアドレスを確認し、ARPテーブルを更新し、宛先MACアドレスがUbuntuのeth0 MACアドレスであるUbuntuの169.254.5.6にIPv4 ICMPエコー要求パケットを送信しました。

  • 弱いホストモデルに従うUbuntuはIPv4 ICMPエコー応答要求を使用します。 OPが動作していると言ったので、これは次のことを意味します。

    • デスクトップソースアドレスもIPv4LLで、Ubuntuには169.254.0.0/16パスもあります。イーサネット0指標が低いため（同じ場合は最初に使用されます）、応答が右側に表示されます。

    • あるいは、デスクトップはIPv4LLソースを使用してIPv4LLアドレス169.254.5.6を照会しないため、UbuntuのIPアドレスと同じIPネットワーク（DHCPで設定）にある可能性があります。イーサネット0Ubuntuは右側でも応答します（ルーティングテーブルにeth0に192.168.1.0/24などのエントリがあるため）。この場合（IPv4LLソースなし）は、次のために発生します。RFC:

同じインターフェイスでIPv4リンク - ローカルアドレスとルーティング可能アドレスを使用できる場合
ルーティング可能なアドレスは、新しい通信の送信元アドレスとして優先する必要があります。ただし、IPv4リンクローカルアドレスから送信された、またはIPv4リンクローカルアドレスに送信された
パケットは、依然として予想通りに転送されます。

私が説明の中で何も見逃さなかったと仮定すると、どのような場合でしょうか？

もちろん、この動作が完全に正しいわけではありません。各ブロードキャストドメインには独自のプライベートIPv4LL LANが必要であり、アドレスを別のドメインに漏洩できないためです。

これが実際に意味するのは、基本構成を持つLinuxホストが複数のIPv4LLネットワーク（インターフェースごとに1つ）に参加している場合、他のシステムが独自のIPv4LLアドレスを使用することを許可しない可能性があることです（不明、以下を参照）。 。あるいは、同じ側にいなくても、独自のIPv4LLアドレスを切り替える必要はありません。影響の確認。しかし、実際のアプリケーションでは、弱いホストモデルのためにデフォルトで場所を入力する169.254.0.0/16への複数のパスがあります。マルチホーミング（誤った）設定。通常、1つのパスのみが機能します。最初のパスは表示されたパスと同じですip route show 169.254.0.0/16。他のものは有効なARPを持つことができますが、有効なIPルーティングを持つことはできません。これを行うには、ホストをマルチホーミング用に正しく設定する必要があります（この場合、上記の「間違った」インターフェイスに送信されたARPへの応答が停止し、問題が発生しない可能性があります）、IPv4LLとの統合も役に立ちません。ほとんどの場合、リンクローカルアドレスを使用するにはインターフェイスを含める必要があるため、IPv6ではこれは発生しません。

おすすめ記事