web-dev-qa-db-ja.com

Ubuntu 18.04のDHCPクライアントからの間違ったIPアドレス

DHCPサーバーからの起動中に、Ubuntu 18.04（サーバー）ボックスに間違ったIPアドレスが発行されるという奇妙な問題が発生しています。ブート後にインターフェースでdhclientを実行すると、正しいIPがインターフェースに追加されます。

DHCPサーバーは、ubuntuでip addrで示されるMACアドレスを使用して予約が手動で構成されたWindowsボックスです（コロンなし）。

5: eno4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:26:b9:82:44:27 brd ff:ff:ff:ff:ff:ff
    inet 10.10.11.162/23 brd 10.10.11.255 scope global dynamic eno4
       valid_lft 689861sec preferred_lft 689861sec
    inet6 fe80::226:b9ff:fe82:4427/64 scope link
       valid_lft forever preferred_lft forever

私の50-courtin-networking.cfg（cloud-init cfg）

network:
  version: 2
  ethernets:

    bcm:
      match:
        name: eno*
      dhcp4: true
      dhcp6: false

DHCPのJournalctlエントリ：

#journalctl | grep -Ei 'dhcp'`
Jul 12 10:10:56 skprov2 systemd-networkd[1160]: eno1: DHCP lease lost
Jul 12 10:10:57 skprov2 systemd-networkd[1160]: eno4: DHCP lease lost
Jul 12 10:11:00 skprov2 systemd-networkd[1160]: eno1: DHCPv4 address 10.10.11.157/23 via 10.10.10.254
Jul 12 10:11:02 skprov2 systemd-networkd[1160]: eno4: DHCPv4 address 10.10.11.162/23 via 10.10.10.254

ログイン後にdhclientを手動で呼び出す（詳細）：

# dhclient -v eno4
Internet Systems Consortium DHCP Client 4.3.5
Copyright 2004-2016 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eno4/00:26:b9:82:44:27
Sending on   LPF/eno4/00:26:b9:82:44:27
Sending on   Socket/fallback
DHCPREQUEST of 10.10.10.40 on eno4 to 255.255.255.255 port 67 (xid=0x4cb8a62d)
DHCPACK of 10.10.10.40 from 10.10.10.10
bound to 10.10.10.40 -- renewal in 294538 seconds.

10.10.10.10は正しいDHCPサーバーであり、10.10.10.40はそれに構成されているIPです。 Windows DHCPで、誤ったリース（.162）は、ubuntuボックスに存在するMACアドレスを含まない長い「一意のID」を示します：032e827c00020000ab11d0fc617dced58a43

これを回避する正しい方法は何ですか？長いUIDのリースを拒否しますか？そもそもそのUIDはどこから来たのですか？ NICは、Dell PowerEdge R710サーバーに搭載されています。

networkingubuntuipdhcp
10
NoMad

この問題の原因は、Ubuntu 18.04のビルトインネットワーク構成で、NIC MacアドレスがDHCPリクエストのデフォルトIDとして使用されなくなったことです。

次のように/etc/netplan/xxx.yaml（cloud-init）ファイルの構成にdhcp-identifier: macを追加することで、従来の（そして「賢明な」と信じている）動作を復元できます。

network:
    renderer: networkd
    version: 2
    ethernets:
        nicdevicename:
            dhcp4: true
            dhcp-identifier: mac

ここで、「nicdevicename」はネットワークデバイスの名前です

使用する

Sudo netplan apply

新しい構成を試す。エラーが発生した場合、.yamlファイルでは正確なインデントが非常に重要です。

21
anneb

リースの拒否は機能しません。 networkdがそれが拒否されている理由を知る方法はないので、そうしない行うと、魔法のように別のIDタイプに切り替えるだけです。手動で行う必要があります。

Systemdのバージョンが十分に新しく、cloud-initによって書き出された構成ファイルを直接制御できる場合は、*.networkファイルを介してMACアドレスベースのクライアントIDを送信するようにsystemd-networkdに指示できます。

[DHCP]
ClientIdentifier=mac

ただし、systemd-networkdがalwaysを使用することがわかっている場合は、正しいリースをクライアントID 032e827c00020000ab11d0fc617dced58a43に割り当てることができます。これは、systemd-networkdがそのマシンに対して常に送信するものだからです。 （/etc/machine-idに基づいてIDを生成します。）

Dhclientを含むMos DHCPクライアントは、タイプ '01'（MACベース）のクライアントIDフィールドを提供します。別の一般的なタイプは '00'（ドメイン名）です。ただし、デフォルトでは、systemd-networkdは/ etc/machine-idの内容から生成された「不透明な」クライアントIDを提供します。

DHCPプロトコルによれば、リースはクライアントID firstによって選択され（クライアントがMACベースの場合もそうでない場合もある「クライアントID」オプションを提供する限り）、次にMACアドレスによって選択されます。 次の場合のみクライアントはIDを送信しませんでした。

したがって、予約を構成する場合、すべての適切なDHCPサーバーでは、クライアントID または MACアドレスのいずれかを入力できます。 MACアドレスのみを入力した場合、type-'01 '（MACベース）のクライアントIDが自動的に暗示されると思います。 「クライアントIDを無視する」というチェックボックスがある場合があります。これは便利ですが、技術的にはDHCP仕様に違反しています。

（たとえば、MACが異なる2つのWi-Fiアダプターがありますが、接続されているアダプターに関係なく同じクライアントIDを送信するようにOSを構成しました。これにより、両方から同じアドレスを取得します。）

3
user1686