LinuxでDHCPを用いたIPアドレスの取得とリリースの全手順

LinuxでDHCPのアドレスを取得・更新・解放する方法は、そのインターフェイスをNetworkManager、systemd-networkd、dhclientなどのどれが管理しているかで異なります。すべての環境でsudo dhclientを実行する方法は適切ではありません。別の管理サービスと二重にDHCPクライアントを動かすと、アドレス・経路・DNSの設定が競合するおそれがあります。

SSH接続中のインターフェイスを切断・解放すると、自分の接続も失われます。遠隔サーバーでは、管理コンソールや別経路、復旧手順を用意してから変更してください。以下のenp1s0や接続UUIDは例で、自分の環境へ置き換えます。

DHCPの取得・更新・リリースの違い

DHCPv4の初回取得では、一般にDiscover、Offer、Request、ACKというやり取りで、リース期間付きのアドレスとネットワーク情報を受け取ります。これはIP設定の取得であり、社内ネットワークの利用権限やインターネット接続の成功を保証するものではありません。

更新は既存リースの延長を要求する処理、リリースは不要になったリースを返却する処理です。通常の更新はクライアントが自動で行うため、定期的に手動リリースする必要はありません。再取得しても同じIPアドレスが返ることがあり、「IPを変える」ための確実な方法ではありません。

更新タイミングはサーバーからの設定や実装に依存します。一般的なT1の既定値はリース期間の半分ですが、すべての環境で固定とは限りません。また、DHCPv6やIPv6のSLAACは、ここで説明するDHCPv4と同一の動作ではありません。

変更前にインターフェイスと管理元を確認する

ip -brief link
ip -brief address
ip route
command -v nmcli
command -v networkctl
command -v dhclient

ipコマンドで実際のインターフェイス名、現在のアドレス、デフォルト経路を確認します。eth0とは限らず、enp1s0、ens18などの名前が使われます。コマンドが存在するだけで、そのインターフェイスの管理元とは判断できません。対象について次の状態表示を確認してください。

nmcli device status
nmcli connection show --active
networkctl status enp1s0

存在しないコマンドは実行せず、ディストリビューションの管理方法を確認します。NetworkManagerで管理対象になっているか、networkctlでsystemd-networkdの設定が適用されているか、既存の設定ファイルや管理手順も照合します。複数のサービスが動いていても、担当するインターフェイスが異なる場合があります。

NetworkManager：接続プロファイルを確認して再接続する

NetworkManagerでは、インターフェイス名と接続プロファイル名は別です。先ほどの一覧から、対象インターフェイスが使う接続のUUIDを控えます。次は設定と現在のDHCP情報を確認する例です。

nmcli connection show uuid "対象接続のUUID"
nmcli -f GENERAL,IP4,DHCP4 device show enp1s0

IPv4の自動取得は、接続プロファイルのipv4.methodがautoかを確認します。既にDHCPで動いている接続なら、切断・再接続でDHCPを再実行できます。ただし次の操作は通信を切るため、ローカルコンソールや保守時間帯で、対象を確認してから行います。これは通信を維持したままの更新専用操作ではありません。

sudo nmcli connection down uuid "対象接続のUUID"
sudo nmcli connection up uuid "対象接続のUUID" ifname enp1s0

静的IPからDHCPへ変更する場合の設定は次のとおりですが、単に更新したいだけなら不要です。既存の固定アドレス、経路、DNS、ignore-auto-dnsなどが残っていないかも確認し、移行計画に従って調整します。autoへ変えたことだけで、すべての静的設定が消えるわけではありません。

sudo nmcli connection modify uuid "対象接続のUUID" ipv4.method auto

設定を変えたら適切なタイミングで接続へ反映し、アドレス・経路・DNSを確認します。接続をdownにすることと、サーバーへDHCPRELEASEが送られたことは同じ確認ではありません。明示的なリース返却が要件なら、利用版のDHCPバックエンドと切断時の動作を調べてください。

systemd-networkd：更新はnetworkctl renew

対象がsystemd-networkdで管理され、DHCPが有効なら、次のコマンドで動的設定の更新を要求できます。利用版で対応しているかはnetworkctlのヘルプやmanページも確認してください。NetworkManager管理のインターフェイスに代用しないでください。

sudo networkctl renew enp1s0
networkctl status enp1s0

renewは更新要求であり、リースを先に解放する操作ではありません。IPアドレスが変わらなくても失敗とは限りません。DHCPを恒久的に有効にする設定は、既存の.networkファイルや、Netplanなどその設定を生成している仕組みで行います。生成されたファイルを直接編集しても、次の生成で上書きされる場合があります。

Netplan：管理方式を変えずに既存設定を編集する

NetplanはYAMLからNetworkManagerやsystemd-networkd向けの設定を生成する仕組みです。新しいDHCPクライアントを手動起動するコマンドではありません。既存の/etc/netplan配下の設定、renderer、cloud-initなどの管理元を確認し、バックアップを取ってから対象設定を編集します。

次はDHCPv4を有効にする最小の断片例です。ファイル全体をこれで置き換える例ではありません。実際のインターフェイス名、既存renderer、固定アドレス・ルート・DNS、ほかのYAMLとの結合結果を確認します。

network:
  version: 2
  ethernets:
    enp1s0:
      dhcp4: true

構文・生成を確認してから、確認付きの一時適用を検討します。generateは設定を生成するもので、通信が成功することをテストするものではありません。

sudo netplan generate
sudo netplan try --timeout 120

netplan tryは、制限時間内に確認しなければ設定を戻す仕組みがありますが、公式資料にも制約があります。リモート接続が必ず回復する保証として使わないでください。コンソールを確保し、タイムアウトやキャンセル後は実際の状態とディスク上の設定を確認します。既存ファイルの編集、生成、適用は通信へ影響する変更作業です。

既存のdhclient環境で取得・リリースする場合

dhclientはISC DHCPのクライアントです。ISCでの開発は終了しているため、現在のディストリビューションの保守状況と推奨管理方法を確認します。コマンドがないからといって、現在の管理サービスへ追加して並行実行しないでください。KeaのDHCPサーバーを入れることも、クライアント更新の代わりにはなりません。

以下は、そのインターフェイスを既にdhclientで管理する構成で、管理者がPID・リースファイルや起動方法を把握している場合の例です。まず取得する場合は次のように対象を明示します。-vは詳細な診断表示で、全通信をキャプチャするオプションではありません。

sudo dhclient -v enp1s0

リリースが必要な場合は次のようにします。これにより通信が失われる可能性があります。サービスがdhclientを管理している場合はその管理手順を優先し、独立したプロセスを重複起動しないでください。

sudo dhclient -r enp1s0

再取得は同じ管理方式で行います。インターフェイスを省略して全体へ作用させる例は避けます。-rはシステム全体のネットワーク設定を初期化する万能操作ではなく、停止時に必ずリースが返るとも限りません。静的IPを削除するために使うコマンドでもありません。

取得後はアドレス・経路・DNSを別々に確認する

ip -4 address show dev enp1s0
ip -4 route show
# systemd-resolvedを使っている環境だけ
resolvectl status enp1s0

アドレスがあることだけではDHCPで取得した証明にはなりません。管理サービスのDHCP情報やログも合わせて見ます。期待するサブネット、デフォルト経路、DNS、必要な宛先への通信を確認します。DNSを確認する方法は環境により異なり、resolvectlがない環境で導入を強制する必要はありません。

ifconfigが既に入っている環境では表示にも使えますが、一覧確認のためだけにnet-toolsを追加する必要はありません。また、DHCPでアドレスを得てもDNSやルーティング、プロキシの問題でアプリ通信が失敗する場合があります。

取得できないときの切り分け

ケーブルやWi-Fi接続、リンク状態、正しいVLAN、DHCPサーバー／リレーへの到達性、サーバーのアドレスプール、クライアント識別子や予約設定を管理者と確認します。169.254系のIPv4リンクローカルアドレスだけでは、通常のDHCP取得成功とは判断しません。

journalctl -u NetworkManager --since "10 minutes ago"
# systemd-networkdを使う場合
journalctl -u systemd-networkd --since "10 minutes ago"

使用しているサービスのログだけを確認し、エラーと時刻を記録します。複数のDHCPサーバーがある構成は必ずしも誤りではありません。予想外のアドレスだけを理由にサーバーを削除・停止せず、VLANやリレー、予約などを調べます。共有するログにはIP・MACアドレス、ホスト名などが含まれるため、公開前に必要な部分へ限定してください。

公式資料

NetworkManager：nmcli
systemd：networkctl
Netplan：netplan tryと制約
ISC DHCPの保守状況
ISC：dhclientの構文

まとめ

LinuxのDHCP操作は、管理元の確認から始めます。NetworkManagerなら接続プロファイル、systemd-networkdならnetworkctl、Netplanなら既存の生成設定を使い、dhclientを無条件に追加しないでください。切断やリリースの前に復旧経路を確保し、取得後はアドレス・経路・DNSと実際の通信を確認しましょう。