ネットワークインフラストラクチャーサービスの管理

手順

1. bind パッケージおよび bind-utils パッケージをインストールします。

   # dnf install bind bind-utils

   Copy to Clipboard Toggle word wrap

2. BIND を change-root 環境で実行する場合は、bind-chroot パッケージをインストールします。

   # dnf install bind-chroot

   Copy to Clipboard Toggle word wrap

   デフォルトである enforcing モードで SELinux を使用するホストで BIND を実行すると、より安全になることに注意してください。

3. /etc/named.conf ファイルを編集し、options ステートメントに次の変更を加えます。

   1. listen-on および listen-on-v6 ステートメントを更新して、BIND がリッスンする IPv4 インターフェイスおよび IPv6 インターフェイスを指定します。

      listen-on port 53 { 127.0.0.1; 192.0.2.1; };
      listen-on-v6 port 53 { ::1; 2001:db8:1::1; };

      Copy to Clipboard Toggle word wrap

   2. allow-query ステートメントを更新して、クライアントがこの DNS サーバーにクエリーを実行できる IP アドレスおよび範囲を設定します。

      allow-query { localhost; 192.0.2.0/24; 2001:db8:1::/64; };

      Copy to Clipboard Toggle word wrap

   3. allow-recursion ステートメントを追加して、BIND が再帰クエリーを受け入れる IP アドレスおよび範囲を定義します。

      allow-recursion { localhost; 192.0.2.0/24; 2001:db8:1::/64; };

      Copy to Clipboard Toggle word wrap
      警告

      サーバーのパブリック IP アドレスで再帰を許可しないでください。そうしないと、サーバーが大規模な DNS 増幅攻撃の一部になる可能性があります。

   4. デフォルトでは、BIND は、ルートサーバーから権限のある DNS サーバーに再帰的にクエリーを実行することにより、クエリーを解決します。または、プロバイダーのサーバーなど、他の DNS サーバーにクエリーを転送するように BIND を設定することもできます。この場合、BIND がクエリーを転送する DNS サーバーの IP アドレスのリストを含む forwarders ステートメントを追加します。

      forwarders { 198.51.100.1; 203.0.113.5; };

      Copy to Clipboard Toggle word wrap

      フォールバック動作として、フォワーダーサーバーが応答しないと、BIND はクエリーを再帰的に解決します。この動作を無効にするには、forward only; ステートメントを追加します。

4. /etc/named.conf ファイルの構文を確認します。

   # named-checkconf

   Copy to Clipboard Toggle word wrap

   コマンドが出力を表示しない場合は、構文に間違いがありません。

5. 着信 DNS トラフィックを許可するように firewalld ルールを更新します。

   # firewall-cmd --permanent --add-service=dns
   # firewall-cmd --reload

   Copy to Clipboard Toggle word wrap

6. BIND を開始して有効にします。

   # systemctl enable --now named

   Copy to Clipboard Toggle word wrap

   change-root 環境で BIND を実行する場合は、systemctl enable --now named-chroot コマンドを使用して、サービスを有効にして開始します。

検証

1. 新しく設定した DNS サーバーを使用してドメインを解決します。

   # dig @localhost www.example.org
   ...
   www.example.org.    86400    IN    A    198.51.100.34
   
   ;; Query time: 917 msec
   ...

   Copy to Clipboard Toggle word wrap

   この例では、BIND が同じホストで実行し、localhost インターフェイスでクエリーに応答することを前提としています。

   初めてレコードをクエリーした後、BIND はエントリーをそのキャッシュに追加します。

2. 前のクエリーを繰り返します。

   # dig @localhost www.example.org
   ...
   www.example.org.    85332    IN    A    198.51.100.34
   
   ;; Query time: 1 msec
   ...

   Copy to Clipboard Toggle word wrap

   エントリーがキャッシュされるため、エントリーの有効期限が切れるまで、同じレコードに対するそれ以降のリクエストは大幅に高速化されます。

手順

1. /etc/named.conf ファイルを編集し、category および channel フレーズを logging ステートメントに追加します。次に例を示します。

   logging {
       ...
   
       category notify { zone_transfer_log; };
       category xfer-in { zone_transfer_log; };
       category xfer-out { zone_transfer_log; };
       channel zone_transfer_log {
           file "/var/named/log/transfer.log" versions 10 size 50m;
           print-time yes;
           print-category yes;
           print-severity yes;
           severity info;
        };
   
        ...
   };

   Copy to Clipboard Toggle word wrap

   この設定例では、BIND はゾーン転送に関連するメッセージのログを /var/named/log/transfer.log に記録します。BIND は最大 10 バージョンのログファイルを作成し、最大サイズが 50 MB に達するとローテーションします。

   category 句は、BIND がカテゴリーのメッセージを送信するチャネルを定義します。

   channel 句は、バージョン数、最大ファイルサイズ、および BIND がチャネルにログ記録する必要がある重大度レベルを含むログメッセージの宛先を定義します。イベントのタイムスタンプ、カテゴリー、および重大度のログ記録を有効にするなどの追加設定はオプションですが、デバッグ目的で役立ちます。

2. ログディレクトリーが存在しない場合は作成し、このディレクトリーの named ユーザーに書き込み権限を付与します。

   # mkdir /var/named/log/
   # chown named:named /var/named/log/
   # chmod 700 /var/named/log/

   Copy to Clipboard Toggle word wrap

3. /etc/named.conf ファイルの構文を確認します。

   # named-checkconf

   Copy to Clipboard Toggle word wrap

   コマンドが出力を表示しない場合は、構文に間違いがありません。

4. BIND を再起動します。

   # systemctl restart named

   Copy to Clipboard Toggle word wrap

   change-root 環境で BIND を実行する場合は、systemctl restart named-chroot コマンドを使用してサービスを再起動します。

手順

1. /etc/named.conf ファイルを編集して、次の変更を行います。

   1. acl ステートメントをファイルに追加します。たとえば、127.0.0.1、192.0.2.0/24、および 2001:db8:1::/64 に対して internal-networks という名前の ACL を作成するには、次のように入力します。

      acl internal-networks { 127.0.0.1; 192.0.2.0/24; 2001:db8:1::/64; };
      acl dmz-networks { 198.51.100.0/24; 2001:db8:2::/64; };

      Copy to Clipboard Toggle word wrap

   2. ACL のニックネームをサポートするステートメントで使用します。たとえば、次のようになります。

      allow-query { internal-networks; dmz-networks; };
      allow-recursion { internal-networks; };

      Copy to Clipboard Toggle word wrap

2. /etc/named.conf ファイルの構文を確認します。

   # named-checkconf

   Copy to Clipboard Toggle word wrap

   コマンドが出力を表示しない場合は、構文に間違いがありません。

3. BIND をリロードします。

   # systemctl reload named

   Copy to Clipboard Toggle word wrap

   change-root 環境で BIND を実行する場合は、systemctl reload named-chroot コマンドを使用してサービスをリロードします。

手順

1. 既存のプライマリーサーバーで、以下を行います。

   1. 共有キーを作成し、/etc/named.conf ファイルに追加します。

      # tsig-keygen example-transfer-key | tee -a /etc/named.conf
      key "example-transfer-key" {
              algorithm hmac-sha256;
              secret "q7ANbnyliDMuvWgnKOxMLi313JGcTZB5ydMW5CyUGXQ=";
      };

      Copy to Clipboard Toggle word wrap

      このコマンドは、tsig-keygen コマンドの出力を表示し、自動的に /etc/named.conf に追加します。

      後でセカンダリーサーバーでもコマンドの出力が必要になります。

   2. /etc/named.conf ファイルのゾーン定義を編集します。

      1. allow-transfer ステートメントで、サーバーがゾーンを転送するために example-transfer-key ステートメントで指定されたキーを提供する必要があることを定義します。

         zone "example.com" {
             ...
             allow-transfer { key example-transfer-key; };
         };

         Copy to Clipboard Toggle word wrap

         または、allow-transfer ステートメントで BIND アクセス制御リスト (ACL) ニックネームを使用します。

      2. デフォルトでは、ゾーンが更新された後、BIND は、このゾーンにネームサーバー (NS) レコードを持つすべてのネームサーバーに通知します。セカンダリーサーバーの NS レコードをゾーンに追加する予定がない場合は、BIND がこのサーバーに通知するように設定できます。そのために、このセカンダリーサーバーの IP アドレスを含む also-notify ステートメントをゾーンに追加します。

         zone "example.com" {
             ...
             also-notify { 192.0.2.2; 2001:db8:1::2; };
         };

         Copy to Clipboard Toggle word wrap

   3. /etc/named.conf ファイルの構文を確認します。

      # named-checkconf

      Copy to Clipboard Toggle word wrap

      コマンドが出力を表示しない場合は、構文に間違いがありません。

   4. BIND をリロードします。

      # systemctl reload named

      Copy to Clipboard Toggle word wrap

      change-root 環境で BIND を実行する場合は、systemctl reload named-chroot コマンドを使用してサービスをリロードします。

2. 将来のセカンダリーサーバーで、以下を行います。

   1. /etc/named.conf ファイルを次のように編集します。

      1. プライマリーサーバーと同じキー定義を追加します。

         key "example-transfer-key" {
                 algorithm hmac-sha256;
                 secret "q7ANbnyliDMuvWgnKOxMLi313JGcTZB5ydMW5CyUGXQ=";
         };

         Copy to Clipboard Toggle word wrap

      2. /etc/named.conf ファイルにゾーン定義を追加します。

         zone "example.com" {
             type slave;
             file "slaves/example.com.zone";
             allow-query { any; };
             allow-transfer { none; };
             masters {
               192.0.2.1 key example-transfer-key;
               2001:db8:1::1 key example-transfer-key;
             };
         };

         Copy to Clipboard Toggle word wrap

         これらの設定状態:

         • このサーバーは、example.com ゾーンのセカンダリーサーバー (type slave) です。
         • /var/named/slaves/example.com.zone ファイルはゾーンファイルです。この例のように相対パスを設定すると、このパスは、options ステートメントの directory に設定したディレクトリーからの相対パスになります。このサーバーがセカンダリーであるゾーンファイルをプライマリーサーバーから分離するには、それを /var/named/slaves/ ディレクトリーなどに保存します。
         • どのホストもこのゾーンにクエリーを実行できます。または、IP 範囲または ACL ニックネームを指定して、アクセスを制限します。
         • このサーバーからゾーンを転送できるホストはありません。
         • このゾーンのプライマリーサーバーの IP アドレスは 192.0.2.1 および 2001:db8:1::2 です。または、ACL ニックネームを指定できます。このセカンダリーサーバーは、example-transfer-key という名前のキーを使用して、プライマリーサーバーに対する認証を行います。

   2. /etc/named.conf ファイルの構文を確認します。

      # named-checkconf

      Copy to Clipboard Toggle word wrap

   3. BIND をリロードします。

      # systemctl reload named

      Copy to Clipboard Toggle word wrap

      change-root 環境で BIND を実行する場合は、systemctl reload named-chroot コマンドを使用してサービスをリロードします。

3. オプション: プライマリーサーバーのゾーンファイルを変更し、新しいセカンダリーサーバーの NS レコードを追加します。

1. named サービスの systemd ジャーナルエントリーを表示します。

   # journalctl -u named
   ...
   Jul 06 15:08:51 ns2.example.com named[2024]: zone example.com/IN: Transfer started.
   Jul 06 15:08:51 ns2.example.com named[2024]: transfer of 'example.com/IN' from 192.0.2.1#53: connected using 192.0.2.2#45803
   Jul 06 15:08:51 ns2.example.com named[2024]: zone example.com/IN: transferred serial 2022070101
   Jul 06 15:08:51 ns2.example.com named[2024]: transfer of 'example.com/IN' from 192.0.2.1#53: Transfer status: success
   Jul 06 15:08:51 ns2.example.com named[2024]: transfer of 'example.com/IN' from 192.0.2.1#53: Transfer completed: 1 messages, 29 records, 2002 bytes, 0.003 secs (667333 bytes/sec)

   Copy to Clipboard Toggle word wrap

   change-root 環境で BIND を実行する場合は、journalctl -u named-chroot コマンドを使用してジャーナルエントリーを表示します。

2. BIND がゾーンファイルを作成したことを確認します。

   # ls -l /var/named/slaves/
   total 4
   -rw-r--r--. 1 named named 2736 Jul  6 15:08 example.com.zone

   Copy to Clipboard Toggle word wrap

   デフォルトでは、セカンダリーサーバーはゾーンファイルを未修正のバイナリー形式で保存することに注意してください。

3. セカンダリーサーバーから転送されたゾーンのレコードをクエリーします。

   # dig +short @192.0.2.2 AAAA www.example.com
   2001:db8:1::30

   Copy to Clipboard Toggle word wrap

   この例では、この手順で設定したセカンダリーサーバーが IP アドレス 192.0.2.2 でリッスンしていると想定しています。

手順

1. /etc/named.conf ファイルを編集し、次の変更を行います。

   1. options ステートメントに response-policy 定義を追加します。

      options {
          ...
      
          response-policy {
              zone "rpz.local";
          };
      
          ...
      }

      Copy to Clipboard Toggle word wrap

      response-policy の zone ステートメントで RPZ のカスタム名を設定できます。ただし、次のステップのゾーン定義で同じ名前を使用する必要があります。

   2. 前の手順で設定した RPZ の zone 定義を追加します。

      zone "rpz.local" {
          type master;
          file "rpz.local";
          allow-query { localhost; 192.0.2.0/24; 2001:db8:1::/64; };
          allow-transfer { none; };
      };

      Copy to Clipboard Toggle word wrap

      これらの設定状態:

      • このサーバーは、rpz.local という名前の RPZ のプライマリーサーバー (type master) です。
      • /var/named/rpz.local ファイルはゾーンファイルです。この例のように相対パスを設定すると、このパスは、options ステートメントの directory に設定したディレクトリーからの相対パスになります。
      • allow-query で定義されたホストは、この RPZ をクエリーできます。または、IP 範囲または BIND アクセス制御リスト (ACL) のニックネームを指定して、アクセスを制限します。
      • どのホストもゾーンを転送できません。ゾーン転送を許可するのは、セカンダリーサーバーをセットアップする際に限られ、セカンダリーサーバーの IP アドレスに対してのみ許可します。

2. /etc/named.conf ファイルの構文を確認します。

   # named-checkconf

   Copy to Clipboard Toggle word wrap

   コマンドが出力を表示しない場合は、構文に間違いがありません。

3. たとえば、次の内容で /var/named/rpz.local ファイルを作成します。

   $TTL 10m
   @ IN SOA ns1.example.com. hostmaster.example.com. (
                             2022070601 ; serial number
                             1h         ; refresh period
                             1m         ; retry period
                             3d         ; expire time
                             1m )       ; minimum TTL
   
                    IN NS    ns1.example.com.
   
   example.org      IN CNAME .
   *.example.org    IN CNAME .
   example.net      IN CNAME rpz-drop.
   *.example.net    IN CNAME rpz-drop.

   Copy to Clipboard Toggle word wrap

   このゾーンファイル:

   • リソースレコードのデフォルトの有効期限 (TTL) 値を 10 分に設定します。時間の h などの時間接尾辞がない場合、BIND は値を秒として解釈します。
   • ゾーンに関する詳細を含む、必要な SOA (Start of Authority) リソースレコードが含まれます。
   • このゾーンの権威 DNS サーバーとして ns1.example.com を設定します。ゾーンを機能させるには、少なくとも 1 つのネームサーバー (NS) レコードが必要です。ただし、RFC 1912 に準拠するには、少なくとも 2 つのネームサーバーが必要です。
   • このドメイン内の example.org およびホストへのクエリーに対して NXDOMAIN エラーを返します。
   • このドメイン内の example.net およびホストにクエリーを破棄します。

   アクションおよび例の完全なリストは、IETF draft: DNS Response Policy Zones (RPZ) を参照してください。

4. /var/named/rpz.local ファイルの構文を確認します。

   # named-checkzone rpz.local /var/named/rpz.local
   zone rpz.local/IN: loaded serial 2022070601
   OK

   Copy to Clipboard Toggle word wrap

5. BIND をリロードします。

   # systemctl reload named

   Copy to Clipboard Toggle word wrap

   change-root 環境で BIND を実行する場合は、systemctl reload named-chroot コマンドを使用してサービスをリロードします。

検証

1. NXDOMAIN エラーを返すように RPZ で設定されている example.org のホストを解決しようとします。

   # dig @localhost www.example.org
   ...
   ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 30286
   ...

   Copy to Clipboard Toggle word wrap

   この例では、BIND が同じホストで実行し、localhost インターフェイスでクエリーに応答することを前提としています。

2. RPZ でクエリーを破棄するように設定されている example.net ドメイン内のホストの解決を試みます。

   # dig @localhost www.example.net
   ...
   ;; connection timed out; no servers could be reached
   ...

   Copy to Clipboard Toggle word wrap

手順

1. /etc/named.conf ファイルの options ブロックを編集して、dnstap とターゲットファイルを有効にします。

   options
   {
   # ...
   dnstap { all; }; # Configure filter
   dnstap-output file "/var/named/data/dnstap.bin" versions 2;
   # ...
   };
   # end of options

   Copy to Clipboard Toggle word wrap

2. ログに記録する DNS トラフィックのタイプを指定するには、/etc/named.conf ファイルの dnstap ブロックに dnstap フィルターを追加します。次のフィルターを使用できます。

   • auth: 権威ゾーンの応答または回答。
   • client: 内部クライアントクエリーまたは回答。
   • forwarder: 転送クエリーまたは応答。
   • resolver: 反復的解決クエリーまたは応答。
   • update: 動的ゾーン更新要求。
   • all: 上記のオプションのいずれか。
   • query または response: query または response キーワードを指定しない場合、dnstap は両方を記録します。
   注記

   dnstap フィルターでは、dnstap {} ブロック内に ; で区切った複数の定義を含めます。次の構文を使用してください。dnstap { ( all | auth | client | forwarder | resolver | update ) [ ( query | response ) ]; …​ };

3. 記録されたパケットに対する dnstap ユーティリティーの動作をカスタマイズするには、次のように追加パラメーターを指定して dnstap-output オプションを変更します。

   • size (unlimited | <size>) - サイズが指定した制限に達したときに dnstap ファイルの自動ロールオーバーを有効にします。
   • versions (unlimited | <integer>) - 保持する自動ロールオーバーファイルの数を指定します。

   • suffix (increment | timestamp) - ロールアウトされるファイルの命名規則を選択します。デフォルトでは、増分は .0 から始まります。あるいは、timestamp 値を設定して UNIX タイムスタンプを使用することもできます。

     以下の例では、auth 応答のみ、client クエリー、および動的 updates のクエリーと応答の両方を要求します。

     Example:
     
     dnstap {auth response; client query; update;};

     Copy to Clipboard Toggle word wrap

4. 変更を適用するために、named サービスを再起動します。

   # systemctl restart named.service

   Copy to Clipboard Toggle word wrap

5. アクティブなログの定期的なロールアウトを設定します。

   次の例では、cron スケジューラーは、ユーザーが編集したスクリプトの内容を 1 日に 1 回実行します。roll オプションに値 3 指定し、dnstap が最大 3 つのバックアップログファイルを作成できるようにしています。この値 3 は、dnstap-output 変数の version パラメーターをオーバーライドし、バックアップログファイルの数を 3 に制限します。また、バイナリーログファイルは別のディレクトリーに移動されて名前が変更されます。3 つのバックアップログファイルがすでに存在する場合でも、ファイルの接尾辞が .2 に達することはありません。サイズ制限に基づくバイナリーログの自動ローリングで十分な場合は、このステップを省略できます。

   Example:
   
   sudoedit /etc/cron.daily/dnstap
   
   #!/bin/sh
   rndc dnstap -roll 3
   mv /var/named/data/dnstap.bin.1 /var/log/named/dnstap/dnstap-$(date -I).bin
   
   # use dnstap-read to analyze saved logs
   sudo chmod a+x /etc/cron.daily/dnstap

   Copy to Clipboard Toggle word wrap

6. dnstap-read ユーティリティーを使用して、人間が判読できる形式でログを処理および分析します。

   次の例では、dnstap-read ユーティリティーは出力を YAML ファイル形式で出力します。

   Example:
   
   dnstap-read  -p /var/named/data/dnstap.bin

   Copy to Clipboard Toggle word wrap

手順

1. unbound されているパッケージをインストールします。

   # dnf install unbound

   Copy to Clipboard Toggle word wrap

2. /etc/unbound/unbound.conf ファイルを編集し、server 句で次の変更を行います。

   1. interface パラメーターを追加して、unbound されているサービスがクエリーをリッスンする IP アドレスを設定します。次に例を示します。

      interface: 127.0.0.1
      interface: 192.0.2.1
      interface: 2001:db8:1::1

      Copy to Clipboard Toggle word wrap

      これらの設定では、unbound は指定された IPv4 および IPv6 アドレスでのみリッスンします。

      インターフェイスを必要なものに制限することで、インターネットなどの承認されていないネットワークからのクライアントがこの DNS サーバーにクエリーを送信するのを防ぎます。

   2. access-control パラメーターを追加して、クライアントが DNS サービスを照会できるサブネットを設定します。次に例を示します。

      access-control: 127.0.0.0/8 allow
      access-control: 192.0.2.0/24 allow
      access-control: 2001:db8:1::/64 allow

      Copy to Clipboard Toggle word wrap

3. unbound されているサービスをリモートで管理するための秘密鍵と証明書を作成します。

   # systemctl restart unbound-keygen

   Copy to Clipboard Toggle word wrap

   この手順を省略した場合、次の手順で設定を確認すると、不足しているファイルが報告されます。ただし、unbound されているサービスは、ファイルが見つからない場合に自動的に作成します。

4. 設定ファイルを確認します。

   # unbound-checkconf
   unbound-checkconf: no errors in /etc/unbound/unbound.conf

   Copy to Clipboard Toggle word wrap

5. 着信 DNS トラフィックを許可するように firewalld ルールを更新します。

   # firewall-cmd --permanent --add-service=dns
   # firewall-cmd --reload

   Copy to Clipboard Toggle word wrap

6. unbound されているサービスを有効にして開始します。

   # systemctl enable --now unbound

   Copy to Clipboard Toggle word wrap

検証

1. localhost インターフェイスでリッスンしている unbound されている DNS サーバーにクエリーを実行して、ドメインを解決します。

   # dig @localhost www.example.com
   ...
   www.example.com.    86400    IN    A    198.51.100.34
   
   ;; Query time: 330 msec
   ...

   Copy to Clipboard Toggle word wrap

   初めてレコードをクエリーした後、unbound はエントリーをそのキャッシュに追加します。

2. 前のクエリーを繰り返します。

   # dig @localhost www.example.com
   ...
   www.example.com.    85332    IN    A    198.51.100.34
   
   ;; Query time: 1 msec
   ...

   Copy to Clipboard Toggle word wrap

   エントリーがキャッシュされるため、エントリーの有効期限が切れるまで、同じレコードに対するそれ以降のリクエストは大幅に高速化されます。

手順

1. IPv4 ネットワークを設定する場合:

   1. /etc/kea/kea-dhcp4.conf ファイルを編集し、次の設定を使用します。

      {
        "Dhcp4": {
          // Global settings that apply to all subnets unless overridden.
          "valid-lifetime": 86400,
          "option-data": [
            {
              "name": "domain-name",
      	"data": "example.com"
            },
            {
              "name": "domain-name-servers",
      	"data": "192.0.2.53"
            }
          ],
      
          // The network interfaces on which Kea will listen for DHCP traffic.
          "interfaces-config": {
            "interfaces": [ "enp1s0" ]
          },
      
          "subnet4": [
            // A definition of a subnet that is directly connected to the server
            {
              "id": 1,
              "subnet": "192.0.2.0/24",
              "pools": [
                { "pool": "192.0.2.20  - 192.0.2.100" },
                { "pool": "192.0.2.150 - 192.0.2.200" }
              ],
              "option-data": [
                { "name": "routers", "data": "192.0.2.1" }
              ],
            },
      
            // A definition of a remote subnet served through a DHCP relay
            {
              "id": 2,
              "subnet": "198.51.100.0/24",
              "pools": [
                { "pool": "198.51.100.20 - 198.51.100.100" }
              ],
      	// Allowed DHCP relay agents
      	"relay": {
                "ip-addresses": [ "198.51.100.5" ]
              },
              "option-data": [
                { "name": "routers", "data": "198.51.100.1" },
      	  { "name": "domain-name-servers", "data": "198.51.100.53" }
              ]
            }
          ]
        }
      }

      Copy to Clipboard Toggle word wrap

      この例では、2 つのサブネット (サーバーに直接接続されたサブネットと、DHCP リレーエージェントを使用するリモートサブネット) を提供するように Kea を設定しています。

      この例で指定されている設定は次のとおりです。

      interfaces

      Kea が DHCP リクエストをリッスンするネットワークインターフェイスを定義します。サブネットがサーバーに直接接続されていない場合は、サブネットに到達できるインターフェイスを必ずリストしてください。

      id

      サブネットの一意の整数を定義します。これは複数のサブネットを定義する場合に必須です。

      subnet

      サブネットを Classless Inter-Domain Routing (CIDR) 形式で定義します。

      pools

      Kea がクライアントに割り当てることができる IP アドレスの範囲を定義します。

      option-data

      デフォルトゲートウェイや DNS サーバーなど、クライアントに送信される DHCP オプションを定義します。サブネットごとのオプションデータ設定は、グローバル設定をオーバーライドします。

      relay

      DHCP リレーエージェントの IP アドレスを定義します。この設定はリモートサブネットでは任意ですが、転送されてくるリクエストを信頼できるエージェントだけに制限することで、セキュリティーが向上します。このパラメーターは、直接接続されたサブネットには使用しないでください。

   2. 設定ファイルの構文を検証します。

      # kea-dhcp4 -t /etc/kea/kea-dhcp4.conf

      Copy to Clipboard Toggle word wrap

      コマンドで Syntax check failed が返された場合は、レポートに表示されているエラーを修正します。

   3. 着信 DHCPv4 トラフィックを許可するように firewalld ルールを更新します。

      # firewall-cmd --permanent --add-service=dhcp
      # firewall-cmd --reload

      Copy to Clipboard Toggle word wrap

   4. サービスを有効にして起動します。

      # systemctl enable --now kea-dhcp4

      Copy to Clipboard Toggle word wrap

2. IPv6 ネットワークを設定する場合:

   1. /etc/kea/kea-dhcp6.conf ファイルを編集し、次の設定を使用します。

      {
        "Dhcp6": {
          // Global settings that apply to all subnets unless overridden.
          "valid-lifetime": 86400,
          "option-data": [
            {
              "name": "domain-name",
      	"data": "example.com"
            },
            {
              "name": "dns-servers",
      	"data": "2001:db8:0:1::53"
            }
          ],
      
          // The network interfaces on which Kea will listen for DHCP traffic.
          "interfaces-config": {
            "interfaces": [ "enp1s0" ]
          },
      
          "subnet6": [
            // A definition of a subnet that is directly connected to the server
            {
              "id": 1,
              "subnet": "2001:db8:0:1::/64",
              "pools": [
                { "pool": "2001:db8:0:1::1000 - 2001:db8:0:1::2000" },
                { "pool": "2001:db8:0:1::4000 - 2001:db8:0:1::5000" }
              ],
            },
      
            // A definition of a remote subnet served through a DHCP relay
            {
              "id": 2,
              "subnet": "2001:db8:0:2::/64",
              "pools": [
                { "pool": "2001:db8:0:2::1000 - 2001:db8:0:2::2000" }
              ],
      	// Allowed DHCP relay agents
      	"relay": {
                "ip-addresses": [ "2001:db8:0:2::5" ]
              },
              "option-data": [
      	  { "name": "dns-servers", "data": "2001:db8:0:1::53" }
              ]
            }
          ]
        }
      }

      Copy to Clipboard Toggle word wrap

      この例では、2 つのサブネット (サーバーに直接接続されたサブネットと、DHCP リレーエージェントを使用するリモートサブネット) を提供するように Kea を設定しています。

   2. 設定ファイルの構文を検証します。

      # kea-dhcp6 -t /etc/kea/kea-dhcp6.conf

      Copy to Clipboard Toggle word wrap

      コマンドで Syntax check failed が返された場合は、レポートに表示されているエラーを修正します。

   3. 着信 DHCPv6 トラフィックを許可するように firewalld ルールを更新します。

      # firewall-cmd --permanent --add-service=dhcpv6
      # firewall-cmd --reload

      Copy to Clipboard Toggle word wrap

   4. サービスを有効にして起動します。

      # systemctl enable --now kea-dhcp6

      Copy to Clipboard Toggle word wrap

検証

1. クライアント上で DHCP を使用してネットワーク接続を設定します。nmcli を使用したイーサネット接続の設定 を参照してください。
2. クライアントをネットワークに接続します。

3. クライアントが DHCP サーバーから IP アドレスを受信したかどうかを確認します。

   # ip address show <interface>
   2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
       link/ether 52:54:00:17:b8:b6 brd ff:ff:ff:ff:ff:ff
       inet 192.0.2.20/24 brd 192.0.2.255 scope global noprefixroute enp1s0
          valid_lft forever preferred_lft forever
       inet6 2001:db8:1::1000/64 scope global noprefixroute
          valid_lft forever preferred_lft forever

   Copy to Clipboard Toggle word wrap

手順

1. IPv4 ネットワークを設定する場合:

   1. /etc/kea/kea-dhcp4.conf ファイルを編集し、Dhcp4 パラメーターに loggers 設定を追加します。以下に例を示します。

      {
        "Dhcp4": {
          ...,
          "loggers":[
            {
              "name":"kea-dhcp4",
              "output-options":[
                 {
                  "output":"kea-dhcp4.log",
                  "maxsize":104857600,
                  "maxver":5
                 }
              ],
              "severity":"INFO",
            }
          ],
          ...

      Copy to Clipboard Toggle word wrap

      この例で指定されている設定は次のとおりです。

      name

      logger 設定を適用するバイナリーの名前を定義します。

      output

      /var/lib/kea/ ディレクトリー内のログファイル名を設定します。

      maxsize

      Kea がログファイルをローテーションするまでのログファイルの最大サイズを設定します。デフォルト値は 10240000 バイトです。

      maxver

      Kea が保持するローテーションされたバージョンの最大数を設定します。maxsize 値が 204800 バイト未満の場合、ローテーションが無効になることに注意してください。

      severity

      ログに記録されるメッセージのカテゴリーを指定します。NONE、FATAL、ERROR、WARN、INFO、および DEBUG のいずれかを値として設定できます。Kea は設定された重大度以上のメッセージのみをログに記録します。

   2. 設定ファイルの構文を検証します。

      # kea-dhcp4 -t /etc/kea/kea-dhcp4.conf

      Copy to Clipboard Toggle word wrap

      コマンドで Syntax check failed が返された場合は、レポートに表示されているエラーを修正します。

   3. kea-dhcp4 サービスを再起動します。

      # systemctl restart kea-dhcp4

      Copy to Clipboard Toggle word wrap

2. IPv6 ネットワークを設定する場合:

   1. /etc/kea/kea-dhcp6.conf ファイルを編集し、loggers 設定を Dhcp6 パラメーターに追加します。以下に例を示します。

      {
        "Dhcp6": {
          ...,
          "loggers":[
            {
              "name":"kea-dhcp6",
              "output-options":[
                 {
                  "output":"kea-dhcp6.log",
                  "maxsize":104857600,
                  "maxver":5
                 }
              ],
              "severity":"INFO",
            }
          ],
          ...

      Copy to Clipboard Toggle word wrap

   2. 設定ファイルの構文を検証します。

      # kea-dhcp6 -t /etc/kea/kea-dhcp6.conf

      Copy to Clipboard Toggle word wrap

      コマンドで Syntax check failed が返された場合は、レポートに表示されているエラーを修正します。

   3. kea-dhcp6 サービスを再起動します。

      # systemctl restart kea-dhcp6

      Copy to Clipboard Toggle word wrap

手順

1. IPv4 ネットワークを設定する場合:

   1. /etc/kea/kea-dhcp4.conf ファイルを編集し、subnet4 パラメーターに予約を追加します。

      {
        "Dhcp4": {
          "subnet4": [
            {
              "subnet": "192.0.2.0/24",
      	...,
              "reservations": [
                {
                  "hw-address": "52:54:00:72:2f:6e",
                  "ip-address": "192.0.2.130"
                }
              ],
      	...

      Copy to Clipboard Toggle word wrap

      この例では、52:54:00:72:2f:6e という MAC アドレスを持つホストに、常に 192.0.2.130 という IP アドレスを割り当てるように Kea を設定しています。

      その他の例は、kea-doc パッケージによって提供される /usr/share/doc/kea/examples/kea4/reservations.json ファイルを参照してください。

   2. 設定ファイルの構文を検証します。

      # kea-dhcp4 -t /etc/kea/kea-dhcp4.conf

      Copy to Clipboard Toggle word wrap

      コマンドで Syntax check failed が返された場合は、レポートに表示されているエラーを修正します。

   3. kea-dhcp4 サービスを再起動します。

      # systemctl restart kea-dhcp4

      Copy to Clipboard Toggle word wrap

2. IPv6 ネットワークを設定する場合:

   1. /etc/kea/kea-dhcp6.conf ファイルを編集し、subnet6 パラメーターに予約を追加します。

      {
        "Dhcp6": {
          "subnet6": [
            {
              "subnet": "2001:db8:0:1::/64",
      	...,
              "reservations": [
                {
                  "hw-address": "52:54:00:72:2f:6e",
                  "ip-address": "2001:db8:0:1::99"
                }
              ];
      	...

      Copy to Clipboard Toggle word wrap

      この例では、52:54:00:72:2f:6e という MAC アドレスを持つホストに、常に 2001:db8:0:1::99 という IP アドレスを割り当てるように Kea を設定しています。

      その他の例は、kea-doc パッケージによって提供される /usr/share/doc/kea/examples/kea6/reservations.json ファイルを参照してください。

   2. 設定ファイルの構文を検証します。

      # kea-dhcp6 -t /etc/kea/kea-dhcp6.conf

      Copy to Clipboard Toggle word wrap

      コマンドで Syntax check failed が返された場合は、レポートに表示されているエラーを修正します。

   3. kea-dhcp6 サービスを再起動します。

      # systemctl restart kea-dhcp6

      Copy to Clipboard Toggle word wrap

手順

1. IPv4 ネットワークを設定する場合:

   1. /etc/kea/kea-dhcp4.conf ファイルを編集し、次の変更を加えます。

      1. 次のクライアントクラスを Dhcp4 パラメーターに追加します。

         {
           "Dhcp4": {
             ...
             "client-classes": [
               {
                   "name": "VoIP-Phones",
                   "test": "substring(pkt4.mac, 0, 3) == 0x525400"
               },
               {
                   "name": "Others",
                   "test": "not member('VoIP-Phones')"
               }
             ],
             ...

         Copy to Clipboard Toggle word wrap

         この例では、MAC アドレスが 52:54:00 で始まるデバイスが、VoIP-Phones クライアントクラスにマッチします。このルールにマッチしないデバイスは、Others クライアントクラスに割り当てられます。

      2. pool 定義にクライアントクラスを割り当てます。

         {
           "Dhcp4": {
             "subnet4": [
               {
                 "subnet": "192.0.2.0/24",
         	"pools": [
                   {
                     "pool": "192.0.2.20  - 192.0.2.100",
                     "client-class": "Others"
                   },
                   {
                     "pool": "192.0.2.150 - 192.0.2.200",
                     "client-class": "VoIP-Phones"
                   }
                 ],
                 ...

         Copy to Clipboard Toggle word wrap

         ホストがどのクライアントクラスにマッチするかに応じて、Kea は対応するプールから IP を割り当てます。

   2. 設定ファイルの構文を検証します。

      # kea-dhcp4 -t /etc/kea/kea-dhcp4.conf

      Copy to Clipboard Toggle word wrap

      コマンドで Syntax check failed が返された場合は、レポートに表示されているエラーを修正します。

   3. kea-dhcp4 サービスを再起動します。

      # systemctl restart kea-dhcp4

      Copy to Clipboard Toggle word wrap

2. IPv6 ネットワークを設定する場合:

   1. /etc/kea/kea-dhcp6.conf ファイルを編集し、次の変更を加えます。

      1. Dhcp6 パラメーターに次のクライアントクラスを追加します。

         {
           "Dhcp6": {
             ...
             "client-classes": [
               {
                   "name": "VoIP-Phones",
                   "test": "option[16].exists and (substring(option[16].hex, 0, 8) == '00000009')",
               },
               {
                   "name": "Others",
                   "test": "not member('VoIP-Phones')"
               }
             ],
             ...

         Copy to Clipboard Toggle word wrap

         この例では、16 進値が 00000009 で始まる DHCPv6 ベンダークラスオプション (オプション 16) を送信するデバイスが、VoIP-Phones クライアントクラスにマッチします。このルールにマッチしないデバイスは、Others クライアントクラスに割り当てられます。

      2. pool 定義にクライアントクラスを割り当てます。

         {
           "Dhcp6": {
             "subnet6": [
               {
                 "subnet": "2001:db8:0:1::/64",
         	"pools": [
                   {
                     "pool": "2001:db8:0:1::1000 - 2001:db8:0:1::2000",
                     "client-class": "Others"
                   },
                   {
                     "pool": "2001:db8:0:1::4000 - 2001:db8:0:1::5000",
                     "client-class": "VoIP-Phones"
                   }
                 ],
                 ...

         Copy to Clipboard Toggle word wrap

         ホストがどのクライアントクラスにマッチするかに応じて、Kea は対応するプールから IP を割り当てます。

   2. 設定ファイルの構文を検証します。

      # kea-dhcp6 -t /etc/kea/kea-dhcp6.conf

      Copy to Clipboard Toggle word wrap

      コマンドで Syntax check failed が返された場合は、レポートに表示されているエラーを修正します。

   3. kea-dhcp6 サービスを再起動します。

      # systemctl restart kea-dhcp6

      Copy to Clipboard Toggle word wrap

手順

1. radvd パッケージをインストールします。

   # dnf install radvd

   Copy to Clipboard Toggle word wrap

2. /etc/radvd.conf ファイルを編集し、以下の設定を追加します。

   interface enp1s0
   {
     AdvSendAdvert on;
     AdvManagedFlag on;
     AdvOtherConfigFlag on;
   
     prefix 2001:db8:0:1::/64 {
     };
   };

   Copy to Clipboard Toggle word wrap

   この設定により、2001:db8:0:1::/64 サブネット用のルーター広告メッセージを enp1s0 デバイス上で送信するように radvd が設定されます。AdvManagedFlag on 設定は、クライアントが、DHCP サーバーから IP アドレスを受け取る必要があることを定義し、on に設定した AdvOtherConfigFlag パラメーターは、DHCP サーバーからもアドレス以外の情報を取得する必要があることを定義します。

   詳細は、システム上の radvd.conf(5) man ページと /usr/share/doc/radvd/radvd.conf.example ファイルを参照してください。

3. オプション: システムの起動時に radvd が自動的に起動するように設定します。

   # systemctl enable radvd

   Copy to Clipboard Toggle word wrap

4. radvd サービスを起動します。

   # systemctl start radvd

   Copy to Clipboard Toggle word wrap