네트워킹 인프라 서비스 관리

프로세스

1. bind 및 bind-utils 패키지를 설치합니다.

   # dnf install bind bind-utils

2. 변경 루트 환경에서 BIND를 실행하려면 bind-chroot 패키지를 설치합니다.

   # dnf install bind-chroot

   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; };

   2. allow-query 문을 업데이트하여 클라이언트가 이 DNS 서버를 쿼리할 수 있는 IP 주소 및 범위를 구성합니다.

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

   3. allow-recursion 문을 추가하여 BIND에서 재귀 쿼리를 허용하는 IP 주소 및 범위를 정의합니다.

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

      주의

      서버의 공용 IP 주소에 대한 재귀를 허용하지 마십시오. 그렇지 않으면 서버가 대규모 DNS 조정 공격의 일부가 될 수 있습니다.

   4. 기본적으로 BIND는 루트 서버에서 권한 있는 DNS 서버로 반복적으로 쿼리하여 쿼리를 확인합니다. 또는 공급자와 같은 다른 DNS 서버에 쿼리를 전달하도록 BIND를 구성할 수 있습니다. 이 경우 BIND에서 쿼리를 전달해야 하는 DNS 서버의 IP 주소 목록을 사용하여 forwarders 문을 추가합니다.

      forwarders { 198.51.100.1; 203.0.113.5; };

      역추적 동작으로 BIND는 전달자 서버가 응답하지 않는 경우 쿼리를 재귀적으로 확인합니다. 이 동작을 비활성화하려면 forward only; 문을 추가합니다.

4. /etc/named.conf 파일의 구문을 확인합니다.

   # named-checkconf

   명령이 출력을 표시하지 않으면 구문이 올바르게 됩니다.

5. 들어오는 DNS 트래픽을 허용하도록 firewalld 규칙을 업데이트합니다.

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

6. BIND를 시작하고 활성화합니다.

   # systemctl enable --now named

   변경 루트 환경에서 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
   ...

   이 예제에서는 BIND가 동일한 호스트에서 실행되고 localhost 인터페이스의 쿼리에 응답한다고 가정합니다.

   처음으로 레코드를 쿼리한 후 BIND에서 해당 캐시에 항목을 추가합니다.

2. 이전 쿼리를 반복합니다.

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

   캐시된 항목으로 인해 항목이 만료될 때까지 동일한 레코드에 대한 추가 요청이 훨씬 더 빨라집니다.

프로세스

1. /etc/named.conf 파일을 편집하고 범주 및 채널 구문을 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;
        };
   
        ...
   };

   이 예제 구성을 사용하면 BIND에서 /var/named/log/transfer.log 로 영역 전송과 관련된 메시지를 기록합니다. BIND는 로그 파일의 최대 10 개 버전을 생성하고 최대 50 MB의 크기에 도달하면 회전합니다.

   카테고리 문구는 BIND에서 카테고리의 메시지를 보내는 채널을 정의합니다.

   채널 구문은 버전 수, 최대 파일 크기, 심각도 수준 BIND에서 채널에 로깅하는 등 로그 메시지의 대상을 정의합니다. 이벤트의 타임스탬프, 카테고리 및 심각도를 로깅하는 것과 같은 추가 설정은 선택 사항이지만 디버깅 목적에 유용합니다.

2. 로그 디렉터리가 없는 경우 로그 디렉터리를 생성하고 이 디렉터리의 named 사용자에게 쓰기 권한을 부여합니다.

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

3. /etc/named.conf 파일의 구문을 확인합니다.

   # named-checkconf

   명령이 출력을 표시하지 않으면 구문이 올바르게 됩니다.

4. BIND를 다시 시작합니다.

   # systemctl restart named

   변경 루트 환경에서 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; };

   2. ACL의 닉네임을 지원하는 문에 사용합니다. 예를 들면 다음과 같습니다.

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

2. /etc/named.conf 파일의 구문을 확인합니다.

   # named-checkconf

   명령이 출력을 표시하지 않으면 구문이 올바르게 됩니다.

3. BIND를 다시 로드합니다.

   # systemctl reload named

   변경 루트 환경에서 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=";
      };

      이 명령은 tsig-keygen 명령의 출력을 표시하고 /etc/named.conf 에 자동으로 추가합니다.

      나중에 보조 서버에서 명령의 출력이 필요합니다.

   2. /etc/named.conf 파일에서 영역 정의를 편집합니다.

      1. allow-transfer 문에서 서버가 영역을 전송하기 위해 example-transfer-key 문에 지정된 키를 제공해야 함을 정의합니다.

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

         또는 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; };
         };

   3. /etc/named.conf 파일의 구문을 확인합니다.

      # named-checkconf

      명령이 출력을 표시하지 않으면 구문이 올바르게 됩니다.

   4. BIND를 다시 로드합니다.

      # systemctl reload named

      변경 루트 환경에서 BIND를 실행하는 경우 systemctl reload named-chroot 명령을 사용하여 서비스를 다시 로드합니다.

2. 향후 보조 서버에서 다음을 수행합니다.

   1. /etc/named.conf 파일을 다음과 같이 편집합니다.

      1. 기본 서버에서와 동일한 키 정의를 추가합니다.

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

      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;
             };
         };

         이러한 설정 상태:

         • 이 서버는 example.com 영역의 보조 서버(유형 슬레이브)입니다.
         • /var/named/slaves/example.com.zone 파일은 영역 파일입니다. 이 예에서와 같이 상대 경로를 설정하는 경우 이 경로는 options 문에서 디렉터리에 설정한 디렉터리 와 상대적입니다. 이 서버가 기본 서버와 보조인 영역 파일을 분리하려면 예를 들어 /var/named/slaves/ 디렉터리에 저장할 수 있습니다.
         • 모든 호스트에서 이 영역을 쿼리할 수 있습니다. 또는 IP 범위 또는 ACL 닉네임을 지정하여 액세스를 제한합니다.
         • 이 서버에서 영역을 전송할 수 있는 호스트는 없습니다.
         • 이 영역의 기본 서버의 IP 주소는 192.0.2.1 및 2001:db8:1::2 입니다. 또는 ACL 닉네임을 지정할 수 있습니다. 이 보조 서버는 example-transfer-key 라는 키를 사용하여 기본 서버를 인증합니다.

   2. /etc/named.conf 파일의 구문을 확인합니다.

      # named-checkconf

   3. BIND를 다시 로드합니다.

      # systemctl reload named

      변경 루트 환경에서 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)

   변경 루트 환경에서 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

   기본적으로 보조 서버는 영역 파일을 바이너리 원시 형식으로 저장합니다.

3. 보조 서버에서 전송된 영역의 레코드를 쿼리합니다.

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

   이 예제에서는 이 절차에서 설정한 보조 서버가 IP 주소 192.0.2.2 에서 수신 대기한다고 가정합니다.

프로세스

1. /etc/named.conf 파일을 편집하고 다음과 같이 변경합니다.

   1. options 문에 response-policy 정의를 추가합니다.

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

      response-policy 의 zone 문에서 RPZ의 사용자 지정 이름을 설정할 수 있습니다. 그러나 다음 단계의 영역 정의에 동일한 이름을 사용해야 합니다.

   2. 이전 단계에서 설정한 RPZ의 영역 정의를 추가합니다.

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

      이러한 설정 상태:

      • 이 서버는 rpz.local 이라는 RPZ의 기본 서버(유형 master)입니다.
      • /var/named/rpz.local 파일은 영역 파일입니다. 이 예에서와 같이 상대 경로를 설정하는 경우 이 경로는 options 문에서 디렉터리에 설정한 디렉터리 와 상대적입니다.
      • allow-query 에 정의된 모든 호스트는 이 RPZ를 쿼리할 수 있습니다. 또는 IP 범위 또는 BIND ACL(액세스 제어 목록) 닉네임을 지정하여 액세스를 제한합니다.
      • 호스트가 영역을 전송할 수 없습니다. 보조 서버를 설정하고 보조 서버의 IP 주소에 대해서만 영역 전송을 허용합니다.

2. /etc/named.conf 파일의 구문을 확인합니다.

   # named-checkconf

   명령이 출력을 표시하지 않으면 구문이 올바르게 됩니다.

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.

   이 영역 파일:

   • 리소스 레코드의 기본 TTL(Time-to-live) 값을 10분으로 설정합니다. 시간 접미사가 없는 경우 h for hour, BIND는 값을 초로 해석합니다.
   • 영역에 대한 세부 정보와 함께 필요한 권한 시작(SOA) 리소스 레코드가 포함되어 있습니다.
   • ns1.example.com 을 이 영역에 대해 권한 있는 DNS 서버로 설정합니다. 기능을 위해 영역에는 하나 이상의 이름 서버(NS) 레코드가 필요합니다. 그러나 RFC 1912를 준수하기 위해서는 적어도 두 개의 이름 서버가 필요합니다.
   • example.org 및 이 도메인의 호스트에 대한 NXDOMAIN 오류를 반환합니다.
   • 이 도메인의 example.net 및 호스트에 대한 쿼리를 삭제합니다.

   전체 작업 및 예제 목록은 IETF 초안:RPZ(DNS Response Policy Zones) 를 참조하십시오.

4. /var/named/rpz.local 파일의 구문을 확인합니다.

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

5. BIND를 다시 로드합니다.

   # systemctl reload named

   변경 루트 환경에서 BIND를 실행하는 경우 systemctl reload named-chroot 명령을 사용하여 서비스를 다시 로드합니다.

검증

1. RPZ에 구성된 example.org 의 호스트를 해결하여 NXDOMAIN 오류를 반환합니다.

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

   이 예제에서는 BIND가 동일한 호스트에서 실행되고 localhost 인터페이스의 쿼리에 응답한다고 가정합니다.

2. RPZ에 구성된 example.net 도메인의 호스트를 확인하여 쿼리를 삭제하십시오.

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

프로세스

1. options 블록에서 /etc/named.conf 파일을 편집하여 dnstap 및 대상 파일을 활성화합니다.

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

2. 로깅할 DNS 트래픽 유형을 지정하려면 /etc/named.conf 파일의 dnstap 블록에 dnstap 필터를 추가합니다. 다음 필터를 사용할 수 있습니다.

   • auth - 권한 있는 영역 응답 또는 응답.
   • 클라이언트 - 내부 클라이언트 쿼리 또는 응답.
   • Forwarder - 쿼리 또는 응답에서 전달합니다.
   • 해결자 - 반복적 해결 쿼리 또는 응답.
   • 업데이트 - 동적 영역 업데이트 요청.
   • All - 위 옵션 중 모두 입니다.
   • 쿼리 또는 응답 - 쿼리 또는 응답 키워드를 지정하지 않으면 dnstap 이 둘 다 기록합니다.
   참고

   dnstap 필터에는 dnstap {} 블록의 dnstap {} 블록의 dnstap {(모든 | auth | client | forwardr | update ) [(쿼리 | 응답 ) ] ; …​ }; dnstap {} 블록으로 구분되는 정의가 포함되어 있습니다.

3. 기록된 패킷에서 dnstap 유틸리티의 동작을 사용자 지정하려면 다음과 같이 추가 매개변수를 제공하여 dnstap-output 옵션을 수정합니다.

   • size (제한되지 않음 | <size>) - 크기가 지정된 제한에 도달하면 dnstap 파일을 자동으로 롤백할 수 있습니다.
   • 버전 (제한되지 않음 | <integer>) - 유지할 자동 롤오버된 파일 수를 지정합니다.

   • 접미사 (increment | timestamp ) - 롤아웃된 파일의 이름 지정 규칙을 선택합니다. 기본적으로 증가는 .0 으로 시작합니다. 또는 timestamp 값을 설정하여 UNIX 타임스탬프 를 사용할 수 있습니다.

     다음 예제에서는 자동 응답 만 요청, 클라이언트 쿼리, 동적 업데이트 의 쿼리 및 응답 모두:

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

4. 변경 사항을 적용하려면 named 서비스를 다시 시작하십시오.

   # systemctl restart named.service

5. 활성 로그에 대한 주기적인 롤아웃 구성

   다음 예에서 cron 스케줄러는 사용자가 편집한 스크립트의 콘텐츠를 하루에 한 번 실행합니다. 값이 3 인 roll 옵션은 dnstap 에서 최대 3개의 백업 로그 파일을 생성할 수 있음을 지정합니다. value 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

6. dnstap-read 유틸리티를 사용하여 사람이 읽을 수 있는 형식으로 로그를 처리하고 분석합니다.

   다음 예에서 dnstap-read 유틸리티는 YAML 파일 형식으로 출력을 출력합니다.

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

절차

1. unbound 패키지를 설치합니다.

   # dnf install unbound

2. /etc/cabundle/cabundle.conf 파일을 편집하고 server 절에서 다음과 같이 변경합니다.

   1. 인터페이스 매개변수를 추가하여 unbound 서비스에서 쿼리를 수신 대기하는 IP 주소를 구성합니다. 예를 들면 다음과 같습니다.

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

      이러한 설정을 사용하면 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

3. unbound 서비스를 원격으로 관리하기 위한 개인 키 및 인증서를 생성합니다.

   # systemctl restart unbound-keygen

   이 단계를 건너뛰면 다음 단계의 구성을 확인하면 누락된 파일이 보고됩니다. 그러나 바인딩되지 않은 서비스는 파일이 누락된 경우 자동으로 파일을 생성합니다.

4. 구성 파일을 확인합니다.

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

5. 들어오는 DNS 트래픽을 허용하도록 firewalld 규칙을 업데이트합니다.

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

6. unbound 서비스를 활성화하고 시작합니다.

   # systemctl enable --now unbound

검증

1. localhost 인터페이스에서 수신 대기하는 바인딩되지 않은 DNS 서버를 쿼리하여 도메인을 확인합니다.

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

   처음으로 레코드를 쿼리한 후 unbound 는 해당 캐시에 항목을 추가합니다.

2. 이전 쿼리를 반복합니다.

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

   캐시된 항목으로 인해 항목이 만료될 때까지 동일한 레코드에 대한 추가 요청이 훨씬 더 빨라집니다.

절차

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" }
              ]
            }
          ]
        }
      }

      이 예제에서는 서버에 직접 연결된 두 개의 서브넷과 DHCP 릴레이 에이전트를 사용하는 원격 원격 서브넷을 제공하도록 Kea를 구성합니다.

      예제에 지정된 설정은 다음과 같습니다.

      interfaces

      Kea가 DHCP 요청을 수신 대기하는 네트워크 인터페이스를 정의합니다. 서브넷이 서버에 직접 연결되지 않은 경우 서브넷에 연결할 수 있는 인터페이스를 나열해야 합니다.

      id

      서브넷의 고유한 정수를 정의합니다. 이는 서브넷을 두 개 이상 정의하는 경우 필요합니다.

      서브넷

      CIDR(Classless Inter-Domain Routing) 형식으로 서브넷을 정의합니다.

      풀

      Kea가 클라이언트에 주소를 할당할 수 있는 IP 주소 범위를 정의합니다.

      option-data

      기본 게이트웨이 및 DNS 서버와 같이 클라이언트에 전송된 DHCP 옵션을 정의합니다. 서브넷별 옵션-데이터 설정은 글로벌 설정을 재정의합니다.

      릴레이

      DHCP 릴레이 에이전트의 IP 주소를 정의합니다. 이 설정은 원격 서브넷의 경우 선택 사항이지만 보안이 개선되어 신뢰할 수 있는 에이전트에 전달된 요청을 제한합니다. 직접 연결된 서브넷에 이 매개변수를 사용하지 마십시오.

   2. 구성 파일의 구문을 확인합니다.

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

      명령에서 Syntax 검사를 실패한 경우 보고서에 표시된 오류를 수정합니다.

   3. 들어오는 DHCPv4 트래픽을 허용하도록 firewalld 규칙을 업데이트합니다.

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

   4. 서비스를 활성화하고 시작합니다.

      # systemctl enable --now kea-dhcp4

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" }
              ]
            }
          ]
        }
      }

      이 예제에서는 서버에 직접 연결된 두 개의 서브넷과 DHCP 릴레이 에이전트를 사용하는 원격 원격 서브넷을 제공하도록 Kea를 구성합니다.

   2. 구성 파일의 구문을 확인합니다.

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

      명령에서 Syntax 검사를 실패한 경우 보고서에 표시된 오류를 수정합니다.

   3. 들어오는 DHCPv6 트래픽을 허용하도록 firewalld 규칙을 업데이트합니다.

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

   4. 서비스를 활성화하고 시작합니다.

      # systemctl enable --now kea-dhcp6

검증

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

절차

1. IPv4 네트워크를 구성하는 경우:

   1. /etc/kea/kea-dhcp4.conf 파일을 편집하고 로거 구성을 Dhcp4 매개변수에 추가합니다. 예를 들면 다음과 같습니다.

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

      예제에 지정된 설정은 다음과 같습니다.

      name

      로거 설정이 적용되는 바이너리의 이름을 정의합니다.

      output

      /var/lib/kea/ 디렉터리에 로그 파일 이름을 설정합니다.

      maxSize

      Kea가 회전하기 전에 로그 파일의 최대 크기를 설정합니다. 기본값은 10240000 바이트입니다.

      maxver

      Kea가 유지할 최대 순환 버전 수를 설정합니다. maxsize 값은 204800 바이트 미만의 회전을 비활성화합니다.

      심각도

      로깅된 메시지의 범주를 지정합니다. 다음 값 중 하나를 설정할 수 있습니다. NONE,FATAL,ERROR,WARN,INFO, DEBUG. Kea는 구성된 심각도 이상의 메시지만 기록합니다.

   2. 구성 파일의 구문을 확인합니다.

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

      명령에서 Syntax 검사를 실패한 경우 보고서에 표시된 오류를 수정합니다.

   3. kea-dhcp4 서비스를 다시 시작합니다.

      # systemctl restart kea-dhcp4

2. IPv6 네트워크를 구성하는 경우:

   1. /etc/kea/kea-dhcp6.conf 파일을 편집하고 로거 구성을 Dhcp6 매개변수에 추가합니다. 예를 들면 다음과 같습니다.

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

   2. 구성 파일의 구문을 확인합니다.

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

      명령에서 Syntax 검사를 실패한 경우 보고서에 표시된 오류를 수정합니다.

   3. kea-dhcp6 서비스를 다시 시작합니다.

      # systemctl restart kea-dhcp6

절차

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"
                }
              ],
      	...

      이 예제에서는 Kea를 구성하여 항상 192.0.2.130 IP 주소를 52:54:00:72:2f:6e MAC 주소가 있는 호스트에 할당합니다.

      추가 예제는 kea-doc 패키지에서 제공하는 /usr/share/doc/kea/examples/kea4/reservations.json 파일을 참조하십시오.

   2. 구성 파일의 구문을 확인합니다.

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

      명령에서 Syntax 검사를 실패한 경우 보고서에 표시된 오류를 수정합니다.

   3. kea-dhcp4 서비스를 다시 시작합니다.

      # systemctl restart kea-dhcp4

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"
                }
              ];
      	...

      이 예제에서는 Kea가 항상 2001:db8:0:1::99 IP 주소를 52:54:00:72:2f:6e MAC 주소가 있는 호스트에 할당하도록 구성합니다.

      자세한 내용은 kea-doc 패키지에서 제공하는 /usr/share/doc/kea/kea6/reservations.json 파일을 참조하십시오.

   2. 구성 파일의 구문을 확인합니다.

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

      명령에서 Syntax 검사를 실패한 경우 보고서에 표시된 오류를 수정합니다.

   3. kea-dhcp6 서비스를 다시 시작합니다.

      # systemctl restart kea-dhcp6

절차

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')"
               }
             ],
             ...

         이 예에서 52:54:00 으로 시작하는 MAC 주소가 있는 장치는 Cryostat - phones 클라이언트 클래스와 일치합니다. 규칙과 일치하지 않는 장치는 Others 클라이언트 클래스에 할당됩니다.

      2. 클라이언트 클래스를 풀 정의에 할당합니다.

         {
           "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"
                   }
                 ],
                 ...

         호스트가 일치하는 클라이언트 클래스에 따라 Kea는 해당 풀의 IP를 할당합니다.

   2. 구성 파일의 구문을 확인합니다.

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

      명령에서 Syntax 검사를 실패한 경우 보고서에 표시된 오류를 수정합니다.

   3. kea-dhcp4 서비스를 다시 시작합니다.

      # systemctl restart kea-dhcp4

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')"
               }
             ],
             ...

         이 예제에서 16진수 값이 00000009 로 시작하는 DHCPv6 공급업체 클래스 옵션(옵션 16)을 전송하는 장치는 Cryostat - phones 클라이언트 클래스와 일치합니다. 규칙과 일치하지 않는 장치는 Others 클라이언트 클래스에 할당됩니다.

      2. 클라이언트 클래스를 풀 정의에 할당합니다.

         {
           "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"
                   }
                 ],
                 ...

         호스트가 일치하는 클라이언트 클래스에 따라 Kea는 해당 풀의 IP를 할당합니다.

   2. 구성 파일의 구문을 확인합니다.

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

      명령에서 Syntax 검사를 실패한 경우 보고서에 표시된 오류를 수정합니다.

   3. kea-dhcp6 서비스를 다시 시작합니다.

      # systemctl restart kea-dhcp6

절차

1. radvd 패키지를 설치합니다.

   # dnf install radvd

2. /etc/radvd.conf 파일을 편집하고 다음 구성을 추가합니다.

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

   이러한 설정은 2001:db8:0:1::/64 서브넷의 enp1s0 장치에 라우터 알림 메시지를 전송하도록 radvd 를 구성합니다. AdvManagedFlag on 설정은 클라이언트에서 DHCP 서버에서 IP 주소를 수신하도록 정의하고 AdvOtherConfigFlag 매개변수는 클라이언트가 DHCP 서버에서 비 주소 정보를 수신해야 함을 정의합니다.

   자세한 내용은 시스템의 radvd.conf(5) 도움말 페이지 및 /usr/share/doc/radvd/radvd.conf.example 파일을 참조하십시오.

3. 선택 사항: 시스템이 부팅될 때 radvd 가 자동으로 시작되도록 구성합니다.

   # systemctl enable radvd

4. radvd 서비스를 시작합니다.

   # systemctl start radvd