Управление службами сетевой инфраструктуры#

Установка и настройка DNS-сервера BIND#

Система доменных имен (DNS) - это метод, используемый для перевода удобочитаемых доменных имен (или полных доменных имен (FQDN)) в машиночитаемые IP-адреса для определения местоположения машины в сети, такой как Интернет.

В компьютерных и сетевых системах это необходимо, потому что, хотя людям легко запомнить и использовать полные доменные имена, компьютеры (клиенты) получают доступ к ресурсам или службам на других компьютерах (серверах) на основе IP-адресов.

В связи с этим DNS-сервер (также известный как сервер имен) поддерживает каталог полных доменных имен и переводит их в IP-адреса; он также может возвращать IP-адрес, если указано имя хоста/полное доменное имя. Существуют различные типы DNS-серверов, включая авторитетный сервер имен, кеширующий сервер имен и многие другие.

Для установки и настройка DNS-сервера BIND выполните следующие шаги:

1. Чтобы установить bind и его утилиты на сервер, выполните следующую команду cdnf.

   dnf install bind bind-utils
   

   

2. Запустите службу DNS, включите автоматический запуск при загрузке системы и проверьте с помощью команды systemctl:

   systemctl start <service_name>
   systemctl enable <service_name>
   systemctl status <service_name>
   

   

3. Чтобы настроить DNS-сервер Bind, сделайте резервную копию исходного файла конфигурации /etc/ named.conf, используя команду cp.

   cp /etc/named.conf /etc/named.conf.orig
   

4. Откройте файл конфигурации /etc/ named.conf для редактирования с помощью текстового редактора командной строки, как показано ниже.

   vi /etc/named.conf
   

   В разделе конфигурации options закомментируйте следующие строки.

   options {
   #listen-on port 53 { 127.0.0.1; };
   #listen-on-v6 port 53 { ::1; };
   directory "/var/named";
   

5. Найдите параметр allow-query и установите его значение для сети, чтобы только хосты в настроенной локальной сети могли запрашивать DNS-сервер.

   allow-query {localhost; <ip-address4>/24}
   

   Зона пересылки – это место, где хранятся отношения между именем хоста (или FQDN) и IP-адресом; он возвращает IP-адрес, используя имя хоста. Обратите внимание, что обычные запросы DNS являются запросами прямого просмотра. С другой стороны, обратная зона возвращает полное доменное имя хоста на основе его IP-адреса.

6. Чтобы определить прямую и обратную зоны, добавьте следующие строки в конец файла /etc/ named.conf.

   //forward zone
   zone "tecmint.lan" IN {
        type master;
        file "tecmint.lan.db";
        allow-update { none; };
       allow-query {any; }
   };
   //backward zone
   zone "56.168.192.in-addr.arpa" IN {
        type master;
        file "tecmint.lan.rev";
        allow-update { none; };
       allow-query { any; }
   };
   

   Параметры в конфигурациях вышеупомянутых зон:

   • type: определяет роль этого сервера для зоны. Значение master означает, что это полномочный сервер, на котором хранится главная копия данных зоны.

   • file: указывает файл базы данных зоны.

   • allow-update: указывает узлы, которым разрешено отправлять обновления динамического DNS для основных зон. В данном случае нет.

7. Создайте файл зоны пересылки в каталоге /var/named.

   vi /var/named/tecmint.lan.db
   

   Добавьте в него следующую конфигурацию.

   $TTL 86400
   @ IN SOA dns-primary.tecmint.lan. admin.tecmint.lan. (
       2019061800 ;Serial
       3600 ;Refresh
       1800 ;Retry
       604800 ;Expire
       86400 ;Minimum TTL
    )
   
    ;Name Server Information
    @ IN NS dns-primary.tecmint.lan.
   
    ;IP for Name Server
    dns-primary IN A <ip-address>
   
    ;A Record for IP address to Hostname
    www IN A <ip-address>
    mail IN A <ip-address>
    docs  IN A <ip-address>
   

   • TTL: указывает время действия RR, а директива $TTL дает значение TTL по умолчанию для каждого RR без определенного набора TTL.

   • @: это псевдоним для имени домена (например, tecmint.lan), определенного в основном файле конфигурации.

   • IN: означает Интернет.

   • SOA: указывает начало полномочий: авторитетный сервер имен (dns-primary.tecmint.lan), контактную информацию администратора (admin.tecmint.lan, знак @ заменяется точкой) и другие связанные информация.

   • NS: означает сервер имен.

   • Serial: используется DNS-сервером для проверки актуальности содержимого определенного файла зоны.

   • Refresh: указывает, как часто подчиненный DNS-сервер должен выполнять передачу зоны от главного.

   • Retry: указывает, как часто ведомое устройство должно повторять неудачную передачу зоны.

   • Expire: определяет, как долго подчиненный сервер должен ждать перед ответом на запрос клиента, когда главный сервер недоступен.

   • Minimum TTL: устанавливает минимальный TTL для зоны.

   • A: адрес хоста.

8. Аналогичным образом создайте файл обратной зоны в каталоге /var/named.

   vi /var/named/tecmint.lan.rev
   

9. Добавьте в него следующие строки. Здесь PTR - это противоположность записи A, используемой для сопоставления IP-адреса с именем хоста.

   $TTL 86400
   @ IN SOA dns-primary.tecmint.lan. admin.tecmint.lan. (
       2019061800 ;Serial
       3600 ;Refresh
       1800 ;Retry
       604800 ;Expire
       86400 ;Minimum TTL
    )
    ;Name Server Information
    @ IN NS dns-primary.tecmint.lan.
   
    ;Reverse lookup for Name Server
    100 IN PTR dns-primary.tecmint.lan.
   
    ;PTR Record IP address to HostName
    5 IN PTR www.tecmint.lan.
    10 IN PTR mail.tecmint.lan.
    20 IN PTR docs.tecmint.lan.
   

10. Установите правильные права собственности на файлы зоны, как показано ниже.

    chown :named /var/named/tecmint.lan.db
    
    chown :named /var/named/tecmint.lan.rev
    

11. Наконец, проверьте конфигурацию DNS и правильность синтаксиса файлов зоны после внесения вышеуказанных изменений с помощью утилиты named-checkconf (отсутствие выхода означает отсутствие ошибки):

    named-checkconf
    named-checkzone tecmint.lan /var/named/tecmint.lan.db
    named-checkzone <ip-address3> /var/named/tecmint.lan.rev
    

    

12. После того как выполнится вся необходимая настройка, необходимо перезапустить службу DNS, чтобы последние изменения вступили в силу.

    systemctl restart named
    

13. Затем, прежде чем какие-либо клиенты смогут получить доступ к конфигурациям службы DNS на сервере, необходимо добавить службу DNS в конфигурацию системного межсетевого экрана и перезагрузить настройки межсетевого экрана с помощью служебной программы firewall-cmd следующим образом:

    firewall-cmd --permanent --zone=public --add-service=dns
    firewall-cmd --reload
    

14. Откройте файл /etc/resolve.conf с помощью текстового редактора.

    vi /etc/resolve.conf
    

15. Добавьте в него следующую запись, которая сообщает преобразователю использовать указанный сервер имен.

    nameserver <ip-address3>
    

16. Сохраните файл и закройте его. Обратите внимание, что также необходимо указать DNS-сервер в файле конфигурации сетевого интерфейса.

17. Добавьте IP-адрес DNS-сервера <ip-address3> в качестве преобразователя в файл конфигурации сетевого интерфейса /etc/sysconfig/network-scripts/ifcfg-enp0s3 клиентского компьютера.

18. Используйте утилиту nslookup для запроса IP-адреса с использованием имени хоста и, наоборот, серверов www, почты и документации в сети.

Защита BIND с помощью SELinux или его запуск в среде с измененным пользователем с административными полномочиями#

Чтобы обеспечить надежную установку привязки BIND, запустите именованную службу без изменения корневой среды. В этом случае SELinux в принудительном режиме предотвращает использование известных уязвимостей безопасности BIND. По умолчанию ОС SberLinux OS Server использует SELinux в принудительном режиме.

1. Запустите службу named-chroot в среде с измененным пользователем с административными полномочиями.

Используя функцию изменения корневого каталога, администраторы могут определить, что корневой каталог процесса и его подпроцессов отличается от каталога /. Когда запускается служба named-chroot, BIND переключает ее корневой каталог на /var/named/chroot/. Как следствие, служба использует команды mount --bind для создания файлов и каталогов, перечисленных в /etc/named-chroot. Эти файлы доступны в /var/named/chroot/, и процесс не имеет доступа к файлам за пределами /var/named/chroot/.

Для использования BIND:

В обычном режиме используйте именованную службу.

В среде с измененным пользователем с административными полномочиями используйте службу named-chroot. Для этого необходимо дополнительно установить пакет named-chroot.

Справочное руководство администратора BIND#

Всесторонний BIND Administrator Reference Manual, который включен в bind пакет, обеспечивающий:

• примеры конфигурации;

• документацию по расширенным функциям;

• ссылку на конфигурацию;

• соображения безопасности.

Для отображения BIND Administrator Reference Manual на хосте, который имеет bind пакет установлен, откройте /usr/share/doc/bind/Bv9ARM.html файл в браузере.

Настройка BIND в качестве кеширующего DNS-сервера#

По умолчанию DNS-сервер BIND разрешает и кеширует успешные и неудачные запросы. Затем служба отвечает на запросы к тем же записям из своего кеша. Это значительно повышает скорость поиска в DNS.

Для настройки BIND выполните следующий сценарий:

1. Установите bind bindutils и пакеты:

   yum install bind bind-utils
   

   Эти пакеты предоставляют BIND 9.11. Если требуется BIND 9.16, установите bind9.16bind9.16 - утилиты и пакеты.

2. Если можно запустить BIND в среде с измененным пользователем с административными полномочиями, установите пакет bind-chroot:

   yum install bind-chroot
   

   Обратите внимание, что запуск BIND на хосте с SELinux в принудительном режиме, который установлен по умолчанию, является более безопасным.

3. Отредактируйте файл /etc/named.conf и внесите следующие изменения в options инструкцию:

   • Обновите инструкции listen-on, listen-on-v6, чтобы указать, какие интерфейсы IPv4 и IPv6 должны прослушиваться BIND:

   listen-on port 53 { 127.0.0.1; <ip-address>; };
   listen-on-v6 port 53 { ::1; 2001:db8:1::1; };
   

   • Разрешите запрос, чтобы настроить, с каких IP-адресов и диапазонов клиенты могут запрашивать этот DNS-сервер:

   allow-query { localhost; <ip-address2>/24; 2001:db8:1::/64; };
   

4. Добавьте оператор allow-recursion, чтобы определить, с каких IP-адресов и диапазонов BIND принимает рекурсивные запросы:

   allow-recursion { localhost; <ip-address2>/24; 2001:db8:1::/64; };
   

   Не разрешайте рекурсию по общедоступным IP-адресам сервера. В противном случае сервер может стать частью крупномасштабных атак по усилению DNS.

   • По умолчанию BIND разрешает запросы путем рекурсивного запроса от корневых серверов к авторитетному DNS-серверу. В качестве альтернативы можно настроить привязку для пересылки запросов на другие DNS-серверы, например, установленного провайдера. В этом случае добавьте инструкцию forwarders со списком IP-адресов DNS-серверов, на которые BIND должен пересылать запросы:

   forwarders { <ip-address5>; <ip-address6>; };
   

   В качестве запасного варианта BIND разрешает запросы рекурсивно, если серверы пересылки не отвечают. Чтобы отключить это поведение, добавьте оператор forward only;

5. Проверьте синтаксис файла /etc/named.conf:

   named-checkconf
   

   Если команда не выводит никаких выходных данных, синтаксис правильный.

6. Обновите правила межсетевого экрана, чтобы разрешить входящий DNS-трафик:

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

7. Запустите и включите BIND:

   systemctl enable --now named
   

   Если можно запустить BIND в среде с измененным пользователем с административными полномочиями, используйте команду systemctl enable --now named-chroot для включения и запуска службы.

Для проверки выполните следующий сценарий:

1. Используйте недавно настроенный DNS-сервер для разрешения домена:

   dig @localhost www.example.org
   ...
   www.example.org.    86400 IN A <ip-address7>
   
   ;; Query time: 917 msec
   ...
   

   В этом примере предполагается, что BIND выполняется на том же хосте и отвечает на запросы в localhost интерфейсе.

   После первого запроса записи BIND добавляет запись в свой кеш.

2. Повторите предыдущий запрос:

   dig @localhost www.example.org
   ...
   www.example.org.    85332 IN A <ip-address7>
   
   ;; Query time: 1 msec
   ...
   

   Из-за кешированной записи дальнейшие запросы к той же записи выполняются значительно быстрее, пока срок действия записи не истечет.

   Настройте клиентов в сети на использование этого DNS-сервера. Если DHCP-сервер предоставляет клиентам настройки DNS-сервера, соответствующим образом обновите конфигурацию DHCP-сервера.

Настройка ведения журнала на DNS-сервере BIND#

Конфигурация в файле /etc/named.conf по умолчанию, предоставляемая пакетом bind, использует канал default_debug и записывает сообщения в /var/named/data/named.run файл. Канал Default_debug регистрирует записи только тогда, когда уровень отладки сервера отличен от нуля.

Используя различные каналы и категории, можно настроить BIND для записи различных событий с серьезностью Syslog в отдельные файлы.

Для настройки ведения журнала на DNS-сервере BIND используйте следующий сценарий:

1. Отредактируйте файл /etc/named.conf и добавьте канал категории и фразы в инструкцию ведения журнала, например:

   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 МБ.

   Фраза категории определяет, по каким каналам BIND отправляет сообщения определенной категории.

   Фраза канала определяет назначение сообщений журнала, включая количество версий, максимальный размер файла и уровень серьезности, с которым нужно регистрироваться в канале.

   Дополнительные настройки, такие как включение регистрации метки времени, категории и серьезности события, необязательны, но полезны для целей отладки.

2. Создайте каталог журнала, если он не существует, и предоставьте разрешения на запись именованному пользователю в этом каталоге:

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

   Проверьте синтаксис файла /etc/named.conf:

   named-checkconf
   

   Если команда не выводит никаких выходных данных, синтаксис правильный.

3. Перезапустите BIND:

   systemctl restart named
   

   Если BIND запускается в среде с измененным пользователем с административными полномочиями, используйте команду systemctl restart named-chroot для перезапуска службы.

Для проверки отобразите содержимое файла журнала:

cat /var/named/log/transfer.log
...
06-Jul-2022 15:08:51.261 xfer-out: info: client @0x7fecbc0b0700 <ip-address8>
#36121/key example-transfer-key (example.ru): transfer of 'example.ru/IN':
AXFR started: TSIG example-transfer-key (serial 2022070603)
06-Jul-2022 15:08:51.261 xfer-out: info: client @0x7fecbc0b0700 <ip-address8>#36121/key example-transfer-key (example.ru): transfer of 'example.ru/IN':
AXFR ended

Написание ACL BIND#

Контроль доступа к определенным функциям BIND может предотвратить несанкционированный доступ и атаки, такие как отказ в обслуживании (DoS). Инструкции BIND access control list (acl) представляют собой списки IP-адресов и диапазонов. Каждый список управления доступом имеет псевдоним, который можно использовать в нескольких операторах, например, allow-query, для ссылки на указанные IP-адреса и диапазоны.

BIND имеет следующие встроенные списки управления доступом:

• none - не соответствует ни одному хосту.

• any - соответствует всем хостам.

• localhost - соответствует адресам обратной 127.0.0.1 связи и ::1, а также IP-адресам всех интерфейсов на сервере, на котором выполняется привязка.

• localnets - соответствует адресам обратной 127.0.0.1 связи и ::1, а также всем подсетям, к которым напрямую подключен сервер, где выполняется привязка.

1. Отредактируйте файл /etc/named.conf и внесите следующие изменения:

   • Добавьте ACL инструкции в файл. Например, чтобы создать список управления доступом с именем internal-networks для 127.0.0.1, <ip-address2>/24, и 2001:db8:1::/64, введите:

   acl internal-networks { 127.0.0.1; <ip-address2>/24; 2001:db8:1::/64; }
   acl dmz-networks { <ip-address9>/24; 2001:db8:2::/64; };
   

   • Используйте псевдоним ACL в операторах, которые их поддерживают, например:

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

   • Проверьте синтаксис файла /etc/named.conf:

   named-checkconf
   

   Если команда не выводит никаких выходных данных, значит, синтаксис правильный.

   • Перезагрузите BIND:

   systemctl reload named
   

   Если запускаете BIND в среде с измененным пользователем с административными полномочиями, используйте команду systemctl reload named-chroot для перезагрузки службы.

Для проверки выполните действие, которое запускает функцию, использующую настроенный список управления доступом. Например, список управления доступом в этой процедуре допускает только рекурсивные запросы с определенных IP-адресов. В этом случае введите следующую команду на узле, который не входит в определение списка управления доступом, чтобы попытаться разрешить внешний домен:

dig +short @<ip-address> www.example.ru

Если команда не возвращает выходные данные, BIND отказывает в доступе, и ACL работает. Для подробного вывода на клиенте используйте команду без short параметра:

dig @<ip-address> www.example.ru
...
;; WARNING: recursion requested but not available
...

Настройка зон на DNS-сервере BIND#

Зона DNS - это база данных с записями ресурсов для определенного поддерева в доменном пространстве. Например, если необходима ответственность за example.ru домен, можно настроить для него зону в BIND. В результате клиенты могут перейти www.example.ru на IP-адрес, настроенный в этой зоне.

Запись SOA в файлах зон#

Запись начала полномочий (SOA) является обязательной записью в зоне DNS. Эта запись важна, например, если несколько DNS-серверов являются авторитетными для зоны, а также для DNS-преобразователей.

Запись SOA в BIND имеет следующий синтаксис:

name class type mname rname serial refresh retry expire minimum

Для удобства чтения администраторы обычно разделяют запись в файлах зон на несколько строк с комментариями, начинающимися с точки с запятой (;). Обратите внимание, что при разделении записи SOA круглые скобки сохраняют запись вместе:

@ IN SOA ns1.example.ru. hostmaster.example.ru. (
                          2022070601 ; serial number
                         1d         ; refresh period
                         3h         ; retry period
                          3d         ; expire time
                          3h )       ; minimum TTL

Поля в записи SOA:

• name: Название зоны, так называемой origin. Если задать значение этому полю @, BIND расширит его до имени зоны, определенного в /etc/named.conf.

• class: В записях SOA нужно всегда устанавливать для этого поля значение Internet (IN).

• type: В записях SOA нужно всегда устанавливать это поле равным SOA.

• mname (главное имя): имя хоста основного сервера имен этой зоны.

• rname (имя ответственного): адрес электронной почты ответственного за эту зону. Обратите внимание, что формат отличается. Можно должны заменить знак at (@) точкой (.).

• serial: Номер версии этого файла зоны. Вторичные серверы имен обновляют свои копии зоны только в том случае, если серийный номер на основном сервере выше. Формат может быть любым числовым значением. Обычно используемый формат – это < year >< month >< day ><two-digit-number>. С помощью этого формата можно, теоретически, изменять файл зоны до ста раз в день.

• refresh: Количество времени, которое вторичные серверы должны ждать, прежде чем проверять основной сервер на предмет обновления зоны.

• retry: Количество времени, через которое вторичный сервер повторяет попытку запроса к основному серверу после неудачной попытки.

• expire: Количество времени, через которое вторичный сервер прекращает запрашивать основной сервер, если все предыдущие попытки не увенчались успехом.

• minimum: RFC 2308 изменил значение этого поля на отрицательное время кеширования. Кеширующие распознаватели используют его, чтобы определить, как долго кешировать NXDOMAIN ошибки имен.

Настройка зоны переадресации на основном сервере BIND#

Перенаправление зон сопоставляет имена с IP-адресами и другой информацией. Например, если необходима ответственность за домен example.ru, можно настроить зону пересылки в BIND для разрешения имен, таких как www.example.ru.

Для настройки зоны переадресации выполните следующие действия:

1. Добавьте определение зоны в файл /etc/named.conf:

    zone "example.ru" {
        type master;
        file "example.ru.zone";
        allow-query { any; };
        allow-transfer { none; };
    };
   

   Эти параметры определяют:

   • Этот сервер является основным сервером (type master) для example.ru зоны.

   • Файл /var/named/example.ru.zone - это файл зоны. Если задан относительный путь, как в этом примере, этот путь относится к каталогу, в котором указана directory в options инструкции.

   • Любой хост может запросить эту зону. В качестве альтернативы можно указать диапазоны IP-адресов или BIND псевдонимы списка управления доступом (ACL), чтобы ограничить доступ.

   • Ни один хост не может перенести зону. Разрешайте передачу зон только при настройке дополнительных серверов и только для IP-адресов дополнительных серверов.

2. Проверьте синтаксис /etc/named.conf файла:

   named-checkconf
   

   Если команда не выводит никаких выходных данных, значит, синтаксис правильный.

3. Создайте /var/named/example.ru .zone файл, например, со следующим содержимым:

   $TTL 8h
    @ IN SOA ns1.example.ru. hostmaster.example.ru. (
                              2022070601 ; serial number
                              1d         ; refresh period
                              3h         ; retry period
                              3d         ; expire time
                              3h )       ; minimum TTL
   
                     IN NS   ns1.example.ru.
                     IN MX   10 mail.example.ru.
   
    www               IN A    <ip-address10>
    www               IN AAAA 2001:db8:1::30
    ns1               IN A    <ip-address>
    ns1               IN AAAA 2001:db8:1::1
    mail              IN A    <ip-address11>
    mail              IN AAAA 2001:db8:1::20
   

   Файл зоны:

   • Устанавливает значение промежутка времени по умолчанию (TTL) для записей ресурсов равным 8 часам. Без суффикса времени, такого как h для обозначения часа, BIND интерпретирует значение как секунды.

   • Содержит требуемую запись ресурса SOA с подробной информацией о зоне.

   • Наборы ns1.example.ru в качестве авторитетного DNS-сервера для этой зоны. Чтобы зона функционировала, требуется по крайней мере одна запись сервера имен (NS). Однако, чтобы быть совместимым с RFC 1912, требуется по крайней мере два сервера имен.

   • Наборы mail.example.ru, как почтовый шлюз (MX) из example.ru домен. Числовое значение перед именем хоста является приоритетом записи. Записи с меньшим значением имеют более высокий приоритет.

   • Задает IPv4 и IPv6-адреса www.example.ru, mail.example.ru и ns1.example.ru.

4. Установите безопасные разрешения для файла зоны, которые позволяют читать его только группе named:

   chown root:named /var/named/example.ru.zone
   chmod 640 /var/named/example.ru.zone
   

5. Проверьте синтаксис /var/named/example.ru.zone файла:

6. Перезагрузите BIND:

   systemctl reload named
   

Если запускается BIND в среде с измененным пользователем с административными полномочиями, используйте эту systemctl reload named-chroot команду для перезагрузки службы.

Для проверки выполните следующий сценарий:

Запрашивайте разные записи из example.ru зоны и убедитесь, что выходные данные соответствуют записям, которые настроены в файле зоны:

dig +short @localhost AAAA www.example.ru
2001:db8:1::30

dig +short @localhost NS example.ru
ns1.example.ru.

dig +short @localhost A ns1.example.ru
<ip-address>

В этом примере предполагается, что BIND выполняется на том же хосте и отвечает на запросы в localhost интерфейсе.

Настройка обратной зоны на основном сервере BIND#

Обратные зоны сопоставляют IP-адреса с именами. Например, если отвечаете за диапазон IP<ip-address2>/24-адресов, можно настроить обратную зону в BIND для преобразования IP-адресов из этого диапазона в имена хостов.

Для настройки обратной зоны выполните следующие действия:

1. Добавьте определение зоны в /etc/named.conf файл:

    zone "2.0.192.in-addr.arpa" {
       type master;
       file "2.0.192.in-addr.arpa.zone";
       allow-query { any; };
       allow-transfer { none; };
    };
   

   Эти параметры определяют:

   • Этот сервер в качестве основного сервера (типа master) для 2.0.192.in-addr.arpa обратной зоны.

   • Файл /var/named/2.0.192.in-addr.arpa.zone является файлом зоны. Если задается относительный путь, как в этом примере, этот путь относится к каталогу, который задан в разделе directory в инструкции options.

   • Любой хост может запросить эту зону. В качестве альтернативы, укажите диапазоны IP-адресов или BIND псевдонимы списка управления доступом (ACL), чтобы ограничить доступ.

   • Ни один хост не может перенести зону. Разрешайте передачу зон только при настройке вторичных серверов и только для IP-адресов вторичных серверов.

2. Проверьте синтаксис файла /etc/named.conf:

   named-checkconf
   

   Если команда не выводит никаких выходных данных, значит, синтаксис правильный.

3. Создайте /var/named/2.0.192.in-addr.arpa .zone файл, например, со следующим содержимым:

    $TTL 8h
    @ IN SOA ns1.example.ru. hostmaster.example.ru. (
                              2022070601 ; serial number
                              1d         ; refresh period
                              3h         ; retry period
                              3d         ; expire time
                              3h )       ; minimum TTL
   
                     IN NS   ns1.example.ru.
   
    1                 IN PTR  ns1.example.ru.
    30                IN PTR  www.example.ru.
   

   Этот файл зоны:

   • Устанавливает значение времени жизни по умолчанию (TTL) для записей ресурсов равным 8 часам. Без суффикса времени, такого как h для обозначения часа, BIND интерпретирует значение как секунды.

   • Содержит требуемую запись ресурса SOA с подробной информацией о зоне.

   • Содержит наборы ns1.example.ru в качестве авторитетного DNS-сервера для этой обратной зоны. Чтобы зона функционировала, требуется минимум одна запись сервера имен (NS). Однако чтобы быть совместимым с RFC 1912, требуется минимум два сервера имен.

   • Устанавливает запись указателя (PTR) для <ip-address> и <ip-address10> адресов.

4. Установите безопасные разрешения для файла зоны, которые позволяют читать его только названной группе:

   chown root:named /var/named/2.0.192.in-addr.arpa.zone
   chmod 640 /var/named/2.0.192.in-addr.arpa.zone
   

5. Проверьте синтаксис /var/named/2.0.192.in-addr.arpa.zone файла:

   named-checkzone 2.0.192.in-addr.arpa /var/named/2.0.192.in-addr.arpa.zone
   zone 2.0.192.in-addr.arpa/IN: loaded serial 2022070601
   OK
   

6. Перезагрузите BIND:

systemctl reload named

Если запускается BIND в среде с измененным пользователем с административными полномочиями, используйте systemctl reload named-chroot команду для перезагрузки службы.

Для проверки запросите разные записи из обратной зоны и убедитесь, что выходные данные соответствуют записям, настроенным в файле зоны:

dig +short @localhost -x <ip-address>
ns1.example.ru.

dig +short @localhost -x <ip-address10>
www.example.ru.

В этом примере предполагается, что BIND выполняется на том же хосте и отвечает на запросы в localhost интерфейсе.

Обновление файла зоны BIND#

В определенных ситуациях, например, при изменении IP-адреса сервера, необходимо обновить файл зоны. Если за зону отвечают несколько DNS-серверов, выполните эту процедуру только на основном сервере. Другие DNS-серверы, на которых хранится копия зоны, получат обновление посредством передачи зоны.

Для обновления файла зоны BIND выполните следующий сценарий:

1. При необходимости укажите путь к файлу зоны в /etc/named.conf файле:

    options {
       ...
       directory       "/var/named";
   }
   
   zone "example.ru" {
       ...
       file "example.ru.zone";
   };
   

   Найдите путь к файлу зоны в инструкции file в определении зоны. Относительный путь относится к каталогу directory, указанному в инструкции options.

2. Отредактируйте файл зоны:

   • Внесите необходимые изменения.

   • Увеличьте серийный номер в записи начала полномочий (SOA).

   Примечание

   Если серийный номер равен или меньше предыдущего значения, вторичные серверы не будут обновлять свою копию зоны.

3. Проверьте синтаксис файла зоны:

   named-checkzone example.ru /var/named/example.ru.zone
   zone example.ru/IN: loaded serial 2022062802
   OK
   

4. Перезагрузите BIND:

   systemctl reload named
   

   Если запускается BIND в среде с измененным пользователем с административными полномочиями, используйте systemctl reload named-chroot команду для перезагрузки службы.

Для проверки запросите запись, которую добавили, изменили или удалили, например:

dig +short @localhost A ns2.example.ru
<ip-address8>

В этом примере предполагается, что BIND выполняется на том же хосте и отвечает на запросы в localhost интерфейсе.

Подписание зоны DNSSEC с использованием функций автоматической генерации ключей и обслуживания зоны#

Можно подписывать зоны с помощью расширений безопасности системы доменных имен (DNSSEC) для обеспечения аутентификации и целостности данных. Такие зоны содержат дополнительные записи ресурсов. Клиенты могут использовать их для проверки подлинности информации о зоне.

Если включена функция политики DNSSEC для зоны, BIND автоматически выполняет следующие действия:

• создает ключи;

• подписывает зону;

• поддерживает зону, включая повторную подпись и периодическую замену ключей.

Эта процедура использует встроенную политику DNSSEC по умолчанию в BIND. Эта политика использует единственные подписи ключей ECDSAP256SHA. В качестве альтернативы создайте свою собственную политику для использования пользовательских ключей, алгоритмов и таймингов.

Для подписания зоны DNSSEC с использованием функций автоматической генерации ключей выполните следующие шаги:

1. Отредактируйте файл /etc/named.conf и добавьте dnssec-policy default; в зону, для которой можно включить DNSSEC:

   zone "example.ru" {
       ...
       dnssec-policy default;
   };
   

2. Перезагрузите BIND:

   systemctl reload named
   

   Если запускается BIND в среде с измененным пользователем с административными полномочиями, используйте systemctl reload named-chroot команду для перезагрузки службы.

3. BIND хранит открытый ключ в /var/named/K<zone_name>.+< algorithm>+<key_ID>.key файле. Используйте этот файл для отображения открытого ключа зоны в формате, который требуется «родительской зоне»:

   • Формат записи DS:

   dnssec-dsfromkey /var/named/Kexample.ru.+013+61141.key
   example.ru. IN DS 61141 13 2 3E184188CF6000007CFEE8D0195AACBD00000068BAE0000008B4B1B0000
   

   • Формат DNSKEY:

   grep DNSKEY /var/named/Kexample.ru.+013+61141.key
   example.ru. 3600 IN DNSKEY 257 3 13 sjzT3jNEp120aSO4mPEHHSkReHUf7AABNnT8hNRTzD5cKMQSjDJin2I3 5CaKVcWO1pm+HltxUEt+X9dfp8OZkg==
   

4. Запросите добавить открытый ключ зоны в «родительскую зону». Обратитесь к поставщику домена или в реестр для получения дополнительной информации о том, как это сделать.

Для проверки выполните следующий сценарий:

1. Запросите у собственного DNS-сервера запись из зоны, для которой включена подпись DNSSEC:

   dig +dnssec +short @localhost A www.example.ru
   <ip-address10>
   А 13 3 28800 20220718081258 20220705120353 61141 example.ru . e7Cfh6GuOBMAWsgsHSVTPh+JJSOI/Y6zctzIuqIU1JqEgOOAfL/Qz474 M0sgi54m1Kmnr2ANBKJN9uvOs5eXYw==
   

   В этом примере предполагается, что BIND выполняется на том же хосте и отвечает на запросы в localhost интерфейсе.

2. После добавления открытого ключа в «родительскую зону» и распространения его на другие серверы убедитесь, что сервер устанавливает флаг authenticated data (ad) для запросов к подписанной зоне:

   dig @localhost example.ru +dnssec
   ...
   ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
   ...
   

Настройка передачи зон между DNS-серверами BIND#

Передача зон гарантирует, что все DNS-серверы, на которых есть копия зоны, используют актуальные данные.

Чтобы настроить передачу зон между DNS-серверами, выполните следующие шаги:

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.

   Вывод команды потребуется позже и на вторичном сервере.

   • Отредактируйте определение зоны в /etc/named.conf файле. В allow-transfer инструкции определите, что серверы должны предоставлять ключ, указанный в example-transfer-key инструкции, для передачи зоны:

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

   При необходимости используйте псевдонимы списка управления доступом (ACL) в allow-transfer инструкции.

   • По умолчанию после обновления зоны BIND уведомляет все серверы имен, у которых есть запись сервера имен (NS) в этой зоне. Если не планируете добавлять NS запись для дополнительного сервера в зону, можно настроить, чтобы BIND уведомляла этот сервер в любом случае. Для этого добавьте в also-notify зону инструкцию с IP-адресами этого вторичного сервера:

   zone "example.ru" {
      ...
       also-notify { <ip-address8>; 2001:db8:1::2; };
   };
   

   • Проверьте синтаксис /etc/named.conf файла:

   named-checkconf
   

   Если команда не выводит никаких выходных данных, значит, синтаксис правильный.

   • Перезагрузите BIND:

   systemctl reload named
   

   Если запущена BIND в среде с измененным корневым каталогом, используйте команду systemctl reload named-chroot для перезагрузки службы.

2. На будущем вторичном сервере:

   • Отредактируйте /etc/named.conf файл следующим образом:

     • Добавьте то же определение ключа, что и на основном сервере.

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

   • Добавьте определение зоны в /etc/named.conf файл.

     zone "example.ru" {
          type slave;
          file "slaves/example.ru.zone";
          allow-query { any; };
          allow-transfer { none; };
          masters {
            <ip-address> key example-transfer-key;
            2001:db8:1::1 key example-transfer-key;
         };
     };
     

   Эти настройки указывают:

   • Этот сервер является вторичным сервером (типа slave) для example.ru зоны:

     • Файл /var/named/slaves/example.ru .zone является файлом зоны. Если задается относительный путь, как в этом примере, этот путь относится к каталогу, который задан в разделе directory в инструкции options. Чтобы отделить файлы зоны, для которых этот сервер является вторичным, от первичных, сохранить их, например, в каталоге /var/named/slaves/.

     • Любой хост может запросить эту зону. В качестве альтернативы, укажите диапазоны IP-адресов или псевдонимы ACL, чтобы ограничить доступ.

     • Ни один хост не может перенести зону с этого сервера.

     • IP-адреса основного сервера этой зоны - <ip-address> и 2001:db8:1::2. В качестве альтернативы можно указать псевдонимы ACL. Этот вторичный сервер будет использовать ключ с именем example-transfer-key для аутентификации на первичном сервере.

   • Проверьте синтаксис файла /etc/named.conf:

   named-checkconf
   

   • Перезагрузите BIND:

   systemctl reload named
   

   Если запускаете BIND в среде с измененным пользователем с административными полномочиями, используйте эту systemctl reload named-chroot команду для перезагрузки службы.

3. При необходимости измените файл зоны на основном сервере и добавьте NS запись для нового дополнительного сервера.

Для проверки на вторичном сервере выполните следующий сценарий:

1. Отображение записей systemd журнала named службы:

   journalctl -u named...
   Jul 06 15:08:51 ns2.example.ru named[2024]: zone example.ru/IN: Transfer started.
   Jul 06 15:08:51 ns2.example.ru named[2024]: transfer of 'example.ru/IN' from <ip-address>#53: connected using <ip-address8>#45803
   Jul 06 15:08:51 ns2.example.ru named[2024]: zone example.ru/IN: transferred serial 2022070101Jul 06 15:08:51 ns2.example.ru named[2024]: transfer of 'example.ru/IN' from <ip-address>#53: Transfer status: success
   Jul 06 15:08:51 ns2.example.ru named[2024]: transfer of 'example.ru/IN' from <ip-address>#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.ru.zone
   

   Обратите внимание, что по умолчанию вторичные серверы хранят файлы зон в двоичном формате raw.

3. Запросите запись о перенесенной зоне с сервера-получателя:

   dig +short @<ip-address8> AAAA www.example.ru
   
   2001:db8:1::30
   

   В приведенном выше примере предполагается, что вторичный сервер, который настроен в этой процедуре, прослушивает IP - адрес <ip-address8>.

Настройка зон политики ответа в BIND для переопределения записей DNS#

Используя блокировку и фильтрацию DNS, администраторы могут переписать DNS-ответ, чтобы заблокировать доступ к определенным доменам или хостам. В BIND зоны политики реагирования (RPZS) предоставляют эту функцию. Можно настроить различные действия для заблокированных записей, такие как возврат ошибки NXDOMAIN или отсутствие ответа на запрос.

Если в среде имеется несколько DNS-серверов, используйте эту процедуру для настройки RPZ на основном сервере, а затем настройте передачу зон, чтобы сделать RPZ доступной на вторичных серверах.

Для настройки зон политики ответа выполните следующий сценарий:

1. Отредактируйте файл /etc/named.conf и внесите следующие изменения:

   • Добавьте определение политики ответа в options инструкцию:

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

   Можно задать пользовательское имя для RPZ в zone инструкции in response-policy. Однако на следующем шаге необходимо использовать то же имя в определении зоны.

   • Добавьте zone определение для RPZ, которое задано на предыдущем шаге:

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

   Эти настройки указывают:

   • Этот сервер является основным сервером (тип master) для RPZ с именем rpz.local.

   • Файл /var/named/rpz.local является файлом зоны. Если задан относительный путь, как в этом примере, этот путь относится к каталогу, который задан в разделе directory в инструкции 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.ru. hostmaster.example.ru. (
                              2022070601 ; serial number
                              1h         ; refresh period
                              1m         ; retry period
                              3d         ; expire time
                              1m )       ; minimum TTL
   
                     IN NS    ns1.example.ru.
   
    example.org      IN CNAME .
    *.example.org    IN CNAME .
    example.net      IN CNAME rpz-drop.
    *.example.net    IN CNAME rpz-drop.
   

   Этот файл зоны:

   • Устанавливает значение времени действия по умолчанию (TTL) для записей ресурсов равным 10 минутам. Без суффикса времени, такого как h для обозначения часа, BIND интерпретирует значение как секунды.

   • Содержит требуемую запись ресурса start of authority (SOA) с подробной информацией о зоне.

   • Содержит наборы ns1.example.ru в качестве авторитетного DNS-сервера для этой зоны. Чтобы зона функционировала, требуется одна запись сервера имен (NS). Однако, чтобы быть совместимым с RFC 1912, требуется две записи сервера имен.

   • Возвращает ошибку NXDOMAIN для запросов к example.org и хосты в этом домене.

   • Отбрасывает запросы в example.net и хосты в этом домене.

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
   

   Eсли запущен BIND в среде с измененным пользователем с административными полномочиями, используйте команду systemctl reload named-chroot для перезагрузки службы.

Для проверки выполните следующие шаги:

1. Разрешите узел в example.org, который настроен в RPZ для возврата ошибки NXDOMAIN:

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

   В приведенном выше примере предполагается, что BIND выполняется на том же хосте и отвечает на запросы в интерфейсе localhost.

   Попытка разрешить узел в example.net домен, который настроен в RPZ для отбрасывания запросов, приведена ниже:

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

Инфраструктурные сервисы#

Synce4l

В системе присутствует synce4l – пакет для частотной синхронизации, который обеспечивает поддержку SyncE. SyncE (синхронный Ethernet) - это аппаратная функция, которая позволяет PTP-тактам достигать точной синхронизации частоты на физическом уровне. Синхронизация поддерживается в некоторых сетевых интерфейсных платах (NIC) и сетевых коммутаторах.

tuned версии 2.20.0

tuned - настроенная утилита для оптимизации производительности приложений и рабочих нагрузок.

• Расширение API перемещает устройства между экземплярами подключаемых модулей во время выполнения.

• Модуль plugin_cpu, который обеспечивает точную настройку параметров производительности, связанных с процессором, содержит следующие возможности:

  • Функция pm_qos_resume_latency_us позволяет ограничить максимальное время, разрешенное каждому процессору для перехода из состояния ожидания в активное состояние;

  • Tuned поддерживает драйвер масштабирования intel_pstate, который предоставляет алгоритмы масштабирования для настройки управления питанием систем на основе различных сценариев использования.

• API сокетов для управления настройками через доменный сокет Unix доступен в качестве предварительного просмотра технологии.

Настройка несвязанного DNS-сервера#

DNS-сервер unbound - это проверяющий, рекурсивный и кеширующий преобразователь DNS. Кроме того, основное внимание unbound уделяется безопасности и по умолчанию включает расширения безопасности доменных имен (DNSSEC).

Настройка Unbound в качестве кеширующего DNS-сервера#

По умолчанию служба DNS unbound разрешает и кеширует успешные и неудачные запросы. Затем служба отвечает на запросы к тем же записям из своего кеша. Для настройки выполните следующие шаги:

1. Установите unbound пакет:

   yum install unbound
   

2. Отредактируйте /etc/unbound/unbound.conf файл и внесите следующие изменения в server предложение:

   • Добавьте interface параметры, на каких IP-адресах служба unbound прослушивает запросы, например:

   interface: 127.0.0.
   interface: <ip-address>
   interface: 2001:db8:1::1
   

   С этими настройками unbound прослушивает только указанные адреса IPv4 и IPv6.

   Ограничение интерфейсов не позволяет клиентам из неавторизованных сетей, таких как Интернет, отправлять запросы на этот DNS-сервер.

   • Добавьте access-control параметры для настройки, из каких подсетей клиенты могут запрашивать службу DNS, например:

   access-control: 127.0.0.0/8 allow
   access-control: <ip-address2>/24 allow
   access-control: 2001:db8:1::/64 allow
   

3. Создайте закрытые ключи и сертификаты для удаленного управления unbound:

   systemctl restart unbound-keygen
   

   Если пропустили этот шаг, проверка конфигурации на следующем шаге приведет к обнаружению отсутствующих файлов. Однако unbound автоматически создает файлы, если они отсутствуют.

4. Проверьте файл конфигурации:

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

5. Обновите правила межсетевого экрана, чтобы разрешить входящий DNS-трафик:

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

6. Включите и запустите unbound службу:

   systemctl enable --now unbound
   

Для проверки выполните следующий сценарий:

1. Запросите unbound DNS-сервер, прослушивающий *localhost интерфейс, чтобы разрешить домен:

   dig @localhost www.example.ru
   ...
   www.example.ru.    86400 IN A <ip-address7>
   
   ;; Query time: 330 msec
   ...
   

   После первого запроса записи unbound добавляет запись в свой кеш.

2. Повторите предыдущий запрос:

   dig @localhost www.example.ru
   ...
   www.example.ru.    85332 IN A <ip-address7>
   
   ;; Query time: 1 msec
   ...
   

Из-за кешированной записи дальнейшие запросы к той же записи выполняются значительно быстрее, пока срок действия записи не истечет.

Следующие шаги:

Настройте клиентов в сети на использование этого DNS-сервера. Например, используйте nmcli утилиту для установки IP-адреса DNS-сервера в NetworkManager профиле подключения:

nmcli connection modify Example_Connection ipv4.dns <ip-address>
nmcli connection modify Example_Connection ipv6.dns 2001:db8:1::1

Предоставление DHCP-сервисов#

Протокол динамической настройки хоста (DHCP) - это сетевой протокол, который автоматически присваивает IP-информацию клиентам.

В этом разделе объясняется общая информация о службе dhcpd, а также о том, как настроить DHCP-сервер и DHCP-ретранслятор.

Если процедура требует различных шагов для предоставления DHCP в сетях IPv4 и IPv6, разделы этой главы содержат процедуры для обоих протоколов.

Разница между статической и динамической IP-адресацией#

Статическая IP-адресация#

Когда устройству назначен статический IP-адрес, адрес не меняется с течением времени, если не изменить его вручную. Используйте статическую IP-адресацию, если необходимо:

• обеспечить согласованность сетевых адресов для таких серверов, как DNS и серверов аутентификации;

• использовать устройства внеполосного управления, которые работают независимо от другой сетевой инфраструктуры.

Динамическая IP-адресация#

Когда устройство настраивается на использование динамического IP-адреса, адрес может меняться с течением времени. По этой причине динамические адреса обычно используются для устройств, которые время от времени подключаются к сети, поскольку IP-адрес может отличаться после перезагрузки хоста.

Динамические IP-адреса более гибкие, их проще настраивать и администрировать. Протокол динамического управления хостом (DHCP) - это традиционный метод динамического назначения сетевых конфигураций хостам.

Фазы транзакции DHCP#

DHCP работает в четыре этапа: обнаружение, предложение, запрос, подтверждение, также называемый процессом DORA. DHCP использует этот процесс для предоставления IP-адресов клиентам.

Обнаружение:

DHCP-клиент отправляет сообщение для обнаружения DHCP-сервера в сети. Это сообщение транслируется на сетевом уровне и уровне канала передачи данных.

Предложение:

DHCP-сервер получает сообщения от клиента и предлагает IP-адрес DHCP-клиенту. Это сообщение является одноадресным на уровне канала передачи данных, но широковещательным на сетевом уровне.

Запрос:

DHCP-клиент запрашивает у DHCP-сервера предлагаемый IP-адрес. Это сообщение является одноадресным на уровне канала передачи данных, но широковещательным на сетевом уровне.

Подтверждение:

DHCP-сервер отправляет подтверждение DHCP-клиенту. Это сообщение является одноадресным на уровне канала передачи данных, но широковещательным на сетевом уровне. Это заключительное сообщение процесса DHCP DORA.

Различия при использовании dhcpd для DHCPv4 и DHCPv6#

Служба dhcpd поддерживает предоставление как DHCPv4, так и DHCPv6 на одном сервере. Однако нужен отдельный экземпляр dhcpd с отдельными файлами конфигурации, чтобы обеспечить DHCP для каждого протокола.

DHCPv4

• Файл конфигурации: /etc/dhcp/dhcpd.conf

• Имя службы Systemd: *dhcpd

DHCPv6

• Файл конфигурации: /etc/dhcp/dhcpd6.conf

• Имя службы Systemd: *dhcpd6

База данных аренды сетевого адреса службой dhcpd#

Аренда DHCP - это период времени, на который служба dhcpd выделяет сетевой адрес клиенту. Служба dhcpd хранит договоры аренды DHCP (list leases) в следующих базах данных:

• Для DHCPv4: /var/lib/dhcpd/dhcpd.leases

• Для DHCPv6: /var/lib/dhcpd/dhcpd6.leases

Ручное обновление файлов базы данных может привести к повреждению баз данных.

Базы данных аренды содержат информацию о выделенных договорах аренды, такую как IP-адрес, присвоенный адресу управления доступом к мультимедиа (MAC), или отметка времени истечения срока аренды. Обратите внимание, что все временные метки в базах данных аренды указаны по Всемирному координированному времени (UTC).

Служба dhcpd периодически воссоздает базы данных:

1. Служба переименовывает существующие файлы:

   • /var/lib/dhcpd/dhcpd.leases в /var/lib/dhcpd/dhcpd.leases~;

   • /var/lib/dhcpd/dhcpd6.leases в /var/lib/dhcpd/dhcpd6.leases~.

2. Служба записывает все известные договоры аренды во вновь созданные файлы:

/var/lib/dhcpd/dhcpd.leases и /var/lib/dhcpd/dhcpd6.leases.

Сравнение DHCPv6 с radvd#

В сети IPv6 только рекламные сообщения маршрутизатора предоставляют информацию о шлюзе IPv6 по умолчанию. Как следствие, если можно использовать DHCPv6 в подсетях, для которых требуется настройка шлюза по умолчанию, необходимо дополнительно настроить службу рекламы маршрутизатора, такую как демон рекламы маршрутизатора (radvd).

Служба radvd использует флаги в рекламных пакетах маршрутизатора, чтобы объявить о доступности сервера DHCPv6.

В этом разделе сравниваются DHCPv6 и radvd и предоставляется информация о настройке radvd (см. таблицу ниже).

Настройка службы radvd для маршрутизаторов IPv6#

Демон рекламы маршрутизатора (radvd) отправляет рекламные сообщения маршрутизатора, которые требуются для автоматической настройки IPv6 без состояния. Это позволяет пользователям автоматически настраивать свои адреса, параметры, маршруты и выбирать маршрутизатор по умолчанию на основе этих рекламных объявлений.

Процедура, описанная в этом разделе, объясняет как выполнить настройку radvd:

1. Установите radvd упаковку:

   yum install radvd
   

2. Отредактируйте /etc/radvd.conf файл и добавьте следующую конфигурацию:

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

   Эти параметры настраивают radvd на отправку сообщений маршрутизатора на устройство enp1s0 для подсети 2001:db8:0:1::/64. Параметр AdvManagedFlagon определяет, что клиент должен получать IP-адрес от DHCP-сервера, а параметр AdvOtherConfigFlag, установленный в значение on, определяет, что клиенты должны получать неадресную информацию от DHCP-сервера.

3. При необходимости настройте, чтобы radvd автоматически запускался при загрузке системы:

   systemctl enable radvd
   

4. Запустите radvd службу:

   systemctl start radvd
   

5. При необходимости отобразите содержимое рекламных пакетов маршрутизатора и отправьте настроенные значения radvd:

   radvdump
   

Настройка сетевых интерфейсов для DHCP-серверов#

По умолчанию служба dhcp обрабатывает запросы только на сетевых интерфейсах, которые имеют IP-адрес в подсети, определенной в файле конфигурации службы.

Например, в следующем сценарии dhcpd прослушивает только сетевой enp0s1 интерфейс:

• определение подсети существует для сети <ip-address2>/24 в файле /etc/dhcp/dhcpd.conf.

• сетевой интерфейс enp0s1 подключен к подсети <ip-address2>/24.

• интерфейс enp7s0 подключен к другой подсети.

Следуйте процедуре, описанной в этом разделе, только в том случае, если DHCP-сервер содержит несколько сетевых интерфейсов, подключенных к одной сети, и служба должна прослушивать только определенные интерфейсы.

В зависимости от того, нужно ли предоставить DHCP для IPv4, IPv6 или обоих протоколов, см. процедуру для:

• Сети IPv4

• Сети IPv6

Для настройки сетевых интерфейсов выполните следующие действия:

Для сетей IPv4:

1. Скопируйте /usr/lib/systemd/system/dhcpd.service файл в каталог /etc/systemd/system/:

   cp /usr/lib/systemd/system/dhcpd.service /etc/systemd/system/
   

   Не редактируйте файл /usr/lib/systemd/system/dhcpd.service. Будущие обновления пакета dhcp-сервера могут переопределить изменения.

2. Отредактируйте файл /etc/systemd/system/dhcpd.service и добавьте имена интерфейса, который dhcpd должен прослушивать для команды в ExecStart параметре:

   ExecStart=/usr/sbin/dhcpd -f -cf /etc/dhcp/dhcpd.conf -user dhcpd -group dhcpd --no-pid $DHCPDARGS enp0s1enp7s0
   

   В этом примере настраивается возможность dhcpd прослушивать только enp0s1 и enp7s0.

3. Перезагрузите конфигурацию системного менеджера:

   systemctl daemon-reload
   

4. Перезапустите службу dhcpd:

   systemctl restart dhcpd.service
   

Для сетей IPv6:

1. Скопируйте файл /usr/lib/systemd/system/dhcpd6.service в каталог /etc/systemd/system/:

   cp /usr/lib/systemd/system/dhcpd6.service /etc/systemd/system/
   

   Не редактируйте файл /usr/lib/systemd/system/dhcpv6.service. Будущие обновления пакета dhcp-сервера могут переопределить изменения.

2. Отредактируйте файл /etc/systemd/system/dhcpd6.service и добавьте имена интерфейса, который dhcpd должен прослушивать для команды в параметре ExecStart:

   ExecStart=/usr/sbin/dhcpd -f -6 -cf /etc/dhcp/dhcpd6.conf -user dhcpd -group dhcpd --no-pid $DHCPDARGS enp0s1enp7s0
   

   В этом примере настраивается, что dhcpd прослушивает только enp0s1 и enp7s0.

3. Перезагрузите конфигурацию системного менеджера:

   systemctl daemon-reload
   

4. Перезапустите dhcpd6 службу:

   systemctl restart dhcpd6.service
   

Настройка службы DHCP для подсетей, напрямую подключенных к серверу DHCP#

Используйте следующую процедуру, если DHCP-сервер напрямую подключен к подсети, для которой сервер должен отвечать на запросы DHCP. Это происходит в том случае, если сетевому интерфейсу сервера присвоен IP-адрес этой подсети.

В зависимости от того, нужно ли предоставить DHCP для IPv4, IPv6 или обоих протоколов, см. процедуру для:

• Сети IPv4.

• Сети IPv6.

Для настройки сетевых интерфейсов выполните следующие действия:

Для сетей IPv4:

1. Отредактируйте файл /etc/dhcp/dhcpd.conf:

   • При необходимости добавьте глобальные параметры, которые dhcpd использует по умолчанию, если никакие другие директивы не содержат этих параметров:

   option domain-name "example.ru";
   
   default-lease-time 86400;
   

   В этом примере задается доменное имя по умолчанию для подключения к example.ru, а время аренды по умолчанию равно 86400 секундам (1 день).

   • Добавьте авторитетное утверждение в новую строку:

   authoritative;
   

   Примечание

   Без утверждения authority служба dhcpd не отвечает на сообщения DHCPREQUEST с помощью DHCPNAK, если клиент запрашивает адрес, который находится за пределами пула.

   • Для каждой подсети IPv4, непосредственно подключенной к интерфейсу сервера, добавьте объявление подсети:

    subnet <ip-address2> netmask <ip-address15> {
     range <ip-address11> <ip-address13>;
     option domain-name-servers <ip-address>;
     option routers <ip-address>;
     option broadcast-address <ip-address14>;
     max-lease-time 172800;
    }
   

   В этом примере добавляется объявление подсети для сети <ip-address2>/24. При такой конфигурации DHCP-сервер назначает следующие параметры клиенту, который отправляет DHCP-запрос из этой подсети:

   • свободный IPv4-адрес из диапазона, определенного в параметре range;

   • IP DNS-сервера для этой подсети: <ip-address>;

   • шлюз по умолчанию для этой подсети: <ip-address>;

   • широковещательный адрес для этой подсети: <ip-address14>;

   • максимальное время аренды IP-адреса, по истечении которого клиенты в этой подсети освобождают IP и отправляют новый запрос на сервер: 172800 секунд (2 дня).

2. При необходимости настройте, чтобы dhcpd запускался автоматически при загрузке системы:

   systemctl enable dhcpd
   

3. Запустите dhcpd службу:

   systemctl start dhcpd
   

Для сетей IPv6:

1. Отредактируйте /etc/dhcp/dhcpd6.conf файл:

   • При необходимости добавьте глобальные параметры, которые dhcpd использует по умолчанию, если никакие другие директивы не содержат этих параметров:

   option dhcp6.domain-search "example.ru";
   
   default-lease-time 86400;
   

   В этом примере задается доменное имя по умолчанию для подключения к example.ru, а время аренды по умолчанию равно 86400 секундам (1 день).

   • Добавьте авторитетное утверждение в новую строку:

   authoritative;
   

   Примечание

   Без утверждения authority служба dhcpd не отвечает на сообщения DHCPREQUEST с помощью DHCPNAK, если клиент запрашивает адрес, который находится за пределами пула.

   • Для каждой подсети IPv6, непосредственно подключенной к интерфейсу сервера, добавьте объявление подсети:

    subnet6 2001:db8:0:1::/64 {
      range6 2001:db8:0:1::20 2001:db8:0:1::100;
      option dhcp6.name-servers 2001:db8:0:1::1;
      max-lease-time 172800;
    }
   

   В этом примере добавляется объявление подсети для сети 2001:db8:0:1::/64. При такой конфигурации DHCP-сервер назначает следующие параметры клиенту, который отправляет DHCP-запрос из этой подсети:

   • Свободный IPv6-адрес из диапазона, определенного в параметре range 6.

   • IP DNS-сервера для этой подсети - 2001:db8:0:1::1.

   • Максимальное время аренды IP-адреса, по истечении которого клиенты в этой подсети освобождают IP и отправляют новый запрос на сервер, составляет 172800 секунд (2 дня).

   Обратите внимание, что IPv6 требует использования рекламных сообщений маршрутизатора для идентификации шлюза по умолчанию.

2. При необходимости настройте, чтобы dhcpv6 запускался автоматически при загрузке системы:

   systemctl enable dhcpd6
   

3. Запустите службу dhcpv6:

   systemctl start dhcpd6
   

Настройка службы DHCP для подсетей, не подключенных напрямую к DHCP-серверу#

Используйте следующую процедуру, если DHCP-сервер напрямую не подключен к подсети, для которой сервер должен отвечать на запросы DHCP. Это необходимо, если агент ретрансляции DHCP пересылает запросы на DHCP-сервер, поскольку ни один из интерфейсов DHCP-сервера напрямую не подключен к подсети, которую должен обслуживать сервер.

В зависимости от того, нужно ли предоставить DHCP для IPv4, IPv6 или обоих протоколов, см. Процедуру для:

• Сети IPv4

• Сети IPv6

Для настройки службы DHCP для подсетей выполните следующие действия:

Для сетей IPv4:

1. Отредактируйте файл /etc/dhcp/dhcpd.conf.

   • При необходимости добавьте глобальные параметры, которые dhcpd использует по умолчанию, если никакие другие директивы не содержат этих параметров:

   option domain-name "example.ru";
   default-lease-time 86400;
   

   В этом примере задается доменное имя по умолчанию для подключения к example.ru, а время аренды по умолчанию равно 86400 секундам (1 день).

   • Добавьте авторитетное утверждение в новую строку:

   authoritative;
   

   Примечание

   Без утверждения authority служба dhcpd не отвечает на сообщения DHCPREQUEST с помощью DHCPNAK, если клиент запрашивает адрес, который находится за пределами пула.

   • Добавьте объявление общей сети, например следующее, для подсетей IPv4, которые напрямую не подключены к интерфейсу сервера:

    shared-network example {
      option domain-name-servers <ip-address>;
      ...
   
      subnet <ip-address2> netmask <ip-address12> {
        range <ip-address11> <ip-address13>;
        option routers <ip-address>;
      }
   
      subnet <ip-address9> netmask <ip-address15> {
        range <ip-address16> <ip-address17>;
        option routers <ip-address5>;
      }
      ...
    }
   

   В этом примере добавляется объявление общей сети, которое содержит объявление подсети как для сетей <ip-address2>/24, так и для сетей <ip-address9>/24. При такой конфигурации DHCP-сервер назначает следующие параметры клиенту, который отправляет DHCP-запрос из одной из этих подсетей:

   • IP DNS-сервера для клиентов из обеих подсетей: <ip-address>.

   • Свободный IPv4-адрес из диапазона, определенного в параметре range, в зависимости от того, из какой подсети клиент отправил запрос.

   • Шлюз по умолчанию – либо <ip-address>, либо <ip-address5> в зависимости от того, из какой подсети клиент отправил запрос.

   • Добавьте объявление для подсети, к которой сервер подключен напрямую, и используйте для доступа к удаленным подсетям, указанным в разделе общая сеть выше:

   subnet <ip-address18> netmask <ip-address15> {
   }
   

   Примечание

   Если сервер не предоставляет службу DHCP для этой подсети, объявление подсети должно быть пустым, как показано в примере. Без объявления непосредственно подключенной подсети dhcpd не запускается.

2. При необходимости настройте, чтобы dhcpd запускался автоматически при загрузке системы:

   systemctl enable dhcpd
   

3. Запустите dhcpd службу:

systemctl start dhcpd

Для сетей IPv6:

1. Отредактируйте файл /etc/dhcp/dhcpd6.con.

   • При необходимости добавьте глобальные параметры, которые dhcpd использует по умолчанию, если никакие другие директивы не содержат этих параметров:

   option dhcp6.domain-search "example.ru";
   default-lease-time 86400;
   

   В этом примере задается доменное имя по умолчанию для подключения к example.ru, а время аренды по умолчанию равно 86400 секундам (1 день).

   • Добавьте авторитетное утверждение в новую строку:

   authoritative;
   

   Примечание

   Без утверждения authority служба dhcpd не отвечает на сообщения DHCPREQUEST с помощью DHCPNAK, если клиент запрашивает адрес, который находится за пределами пула.

   • Добавьте объявление общей сети, например следующее, для подсетей IPv6, которые напрямую не подключены к интерфейсу сервера:

    shared-network example {
     option domain-name-servers 2001:db8:0:1::1:1
      ..
   
      subnet6 2001:db8:0:1::1:0/120 {
        range6 2001:db8:0:1::1:20 2001:db8:0:1::1:100
      }
   
      subnet6 2001:db8:0:1::2:0/120 {
        range6 2001:db8:0:1::2:20 2001:db8:0:1::2:100
      }
      ...
    }
   

   В этом примере добавляется объявление общей сети, содержащее объявление подсети 6 как для сетей 2001:db8:0:1::1:0/120, так и для сетей 2001:db8:0:1::2:0/120. При такой конфигурации DHCP-сервер назначает следующие параметры клиенту, который отправляет DHCP-запрос из одной из этих подсетей:

   • IP DNS-сервера для клиентов из обеих подсетей - 2001:db8:0:1::1:1.

   • Свободный IPv6-адрес из диапазона, определенного в параметре range6, в зависимости от того, из какой подсети клиент отправил запрос.

   Обратите внимание, что IPv6 требует использования рекламных сообщений маршрутизатора для идентификации шлюза по умолчанию.

   • Добавьте объявление subnet6 для подсети, к которой сервер подключен напрямую, и используйте для доступа к удаленным подсетям, указанным выше в разделе shared-network:

   subnet6 2001:db8:0:1::50:0/120 {
   }
   

   Примечание

   Если сервер не предоставляет службу DHCP для этой подсети, объявление subnet6 должно быть пустым, как показано в примере. Без объявления непосредственно подключенной подсети dhcpd не запускается.

2. При необходимости настройте, чтобы dhcpd6 запускался автоматически при загрузке системы:

   systemctl enable dhcpd6
   

3. Запустите dhcpd6 службу:

   systemctl start dhcpd6
   

Назначение статического адреса хосту с помощью DHCP#

Используя назначение хоста, можно настроить DHCP-сервер так, чтобы тот назначал MAC-адресу фиксированный IP-адрес управления доступом к multimedia файлу хоста. Используйте этот метод, чтобы всегда назначать один и тот же IP-адрес серверу или сетевому устройству.

В зависимости от того, нужно ли настроить фиксированные адреса для IPv4, IPv6 или обоих протоколов, см. процедуру для:

• Сети IPv4

• Сети IPv6

Для настройки назначения статического адреса хоста выполните следующие действия:

Для сетей IPv4:

1. Отредактируйте файл /etc/dhcp/dhcpd.conf:

   • Добавьте назначение хоста:

    host server.example.ru {
        hardware ethernet 52:54:00:72:2f:6e;
        fixed-address <ip-address19>;
    }
   

   В этом примере DHCP-сервер настраивается таким образом, чтобы он всегда назначал IP-адрес <ip-address19> хосту с MAC-адресом 52:54:00:72:2f:6e.

   Служба dhcpd идентифицирует системы по MAC-адресу, указанному в параметре фиксированного адреса, а не по имени в объявлении хоста. Как следствие, можно присвоить этому имени любую строку, которая не соответствует другим назначениям хоста. Чтобы настроить одну и ту же систему для нескольких сетей, используйте другое имя, в противном случае dhcpd не запустится.

   • При необходимости добавьте дополнительные настройки к назначению хоста, которые специфичны для этого хоста.

2. Перезапустите службу dhcpd:

   systemctl start dhcpd
   

Для сетей IPv6:

1. Отредактируйте файл /etc/dhcp/dhcpd6.conf:

   • Добавьте назначение хоста:

    host server.example.ru {
        hardware ethernet 52:54:00:72:2f:6e;
        fixed-address6 2001:db8:0:1::200;
    }
   

   В этом примере DHCP-сервер настраивается так, чтобы он всегда назначал хосту IP-адрес 2001:db8:0:1::20 с MAC-адресом 52:54:00:72:2f:6e.

   Служба dhcpd идентифицирует системы по MAC-адресу, указанному в параметре fixed-address6, а не по имени в объявлении хоста. Как следствие, можно присвоить этому имени любую строку, если оно уникально для других объявлений хоста. Чтобы настроить одну и ту же систему для нескольких сетей, используйте другое имя, поскольку в противном случае dhcpd не запустится.

   • При необходимости добавьте дополнительные настройки к объявлению хоста, которые специфичны для этого хоста.

2. Перезапустите службу dhcpd6:

   systemctl start dhcpd6
   

Использование объявления группы для одновременного применения параметров к нескольким хостам, подсетям и общим сетям#

Используя назначение группы, можно применить одни и те же параметры к нескольким хостам, подсетям и общим сетям.

Обратите внимание, что процедура в этом разделе описывает использование назначения группы для узлов, но шаги одинаковы для подсетей и общих сетей.

В зависимости от того, нужно ли настроить группу для IPv4, IPv6 или обоих протоколов, см. процедуру для:

• Сети IPv4.

• Сети IPv6.

Для настройки объявлений группы для одновременного применения параметров к нескольким хостам выполните следующие действия:

Для сетей IPv4:

1. Отредактируйте /etc/dhcp/dhcpd.conf файл:

   • Добавьте групповое объявление:

    group {
     option domain-name-servers <ip-address>;
   
      host server1.example.ru {
        hardware ethernet 52:54:00:72:2f:6e;
        fixed-address <ip-address19>;
      }
   
      host server2.example.ru {
        hardware ethernet 52:54:00:1b:f3:cf;
        fixed-address <ip-address20>;
      }
    }
   

   Это определение группы объединяет две записи хоста. Служба dhcpd применяет значение, заданное в параметре option domain-name-servers, к обоим хостам в группе.

   • При необходимости добавьте дополнительные параметры к объявлению группы, которые специфичны для этих узлов.

2. Перезапустите службу dhcpd:

   systemctl start dhcpd
   

Для сетей IPv6:

1. Отредактируйте /etc/dhcp/dhcpd6.conf файл:

   • Добавьте групповое объявление:

    group {
     option dhcp6.domain-search "example.ru";
   
      host server1.example.ru {
        hardware ethernet 52:54:00:72:2f:6e;
        fixed-address 2001:db8:0:1::200;
      }
   
      host server2.example.ru {
        hardware ethernet 52:54:00:1b:f3:cf;
        fixed-address 2001:db8:0:1::ba3;
     }
    }
   

   Это определение группы объединяет две записи хоста. Служба dhcpd применяет значение, заданное в параметре option dhcp6.domain-search, к обоим хостам в группе.

   • При необходимости добавьте дополнительные параметры к объявлению группы, которые специфичны для этих узлов.

2. Перезапустите dhcpd6 службу:

   systemctl start dhcpd6
   

Восстановление поврежденной базы данных аренды#

Если DHCP-сервер регистрирует ошибку, связанную с lease database (базой данных аренды), например, Corrupt lease file - possible data loss! (поврежденный файл аренды – возможна потеря данных!), Можно восстановить базу данных аренды из копии, созданной службой dhcpd. Обратите внимание, что эта копия может не отражать последнее состояние базы данных.

Если удаляется база данных аренды вместо того, чтобы заменить ее резервной копией, теряется вся информация о назначенных в данный момент договорах аренды. Как следствие, DHCP-сервер может назначать договоры аренды клиентам, которые ранее были назначены другим хостам и срок действия их еще не истек. Это приводит к конфликтам IP-адресов.

В зависимости от того, нужно ли восстановить DHCPv4, DHCPv6 или обе базы данных, см. процедуру для:

• Восстановление базы данных аренды DHCPv4.

• Восстановление базы данных аренды DHCPv6.

Для восстановления базы данных аренды DHCPv4 выполните следующие действия:

1. Остановите службу dhcpd:

   systemctl stop dhcpd
   

2. Переименуйте поврежденную базу данных аренды:

   mv /var/lib/dhcpd/dhcpd.leases /var/lib/dhcpd/dhcpd.leases.corrupt
   

3. Восстановите копию базы данных аренды, созданную службой dhcp при обновлении базы данных аренды:

   cp -p /var/lib/dhcpd/dhcpd.leases~ /var/lib/dhcpd/dhcpd.leases
   

   Примечание

   Если существует более свежая резервная копия базы данных аренды, восстановите резервную копию.

4. Запустите службу dhcpd:

   systemctl start dhcpd
   

Для восстановления базы данных аренды DHCPv6 выполните следующие действия:

1. Остановите службу dhcpd6:

   systemctl stop dhcpd6
   

2. Переименуйте поврежденную базу данных аренды:

   mv /var/lib/dhcpd/dhcpd6.leases /var/lib/dhcpd/dhcpd6.leases.corrupt
   

3. Восстановите копию базы данных аренды, созданную службой dhcp при обновлении базы данных аренды:

   cp -p /var/lib/dhcpd/dhcpd6.leases~ /var/lib/dhcpd/dhcpd6.leases
   

   Примечание

   Если существует более свежая резервная копия базы данных аренды, восстановите резервную копию.

4. Запустите службу dhcpd6:

systemctl start dhcpd6

Настройка агента ретрансляции DHCP#

Агент ретрансляции DHCP (dhcrelay) позволяет ретранслировать запросы DHCP и BOOTP из подсети, в которой нет DHCP-сервера, на один или несколько DHCP-серверов в других подсетях. Когда DHCP-клиент запрашивает информацию, агент ретрансляции DHCP перенаправляет запрос в указанный список DHCP-серверов. Когда DHCP-сервер возвращает ответ, агент ретрансляции DHCP пересылает этот запрос клиенту.

В зависимости от того, нужно ли настроить ретрансляцию DHCP для IPv4, IPv6 или обоих протоколов, см. Процедуру для:

• Сети IPv4.

• Сети IPv6.

Для настройки агента ретрансляции выполните следующие действия:

Для сетей IPv4:

1. Установите пакет dhcp-relay:

   yum install dhcp-relay
   

2. Скопируйте файл /lib/systemd/system/dhcrelay.service в /etc/systemd/system/ каталог:

   cp /lib/systemd/system/dhcrelay.service /etc/systemd/system/
   

   Не редактируйте файл /usr/lib/systemd/system/dhcrelay.service. Будущие обновления пакета dhcp-relay могут переопределить изменения.

3. Отредактируйте файл /etc/systemd/system/dhcrelay.service и добавьте параметр интерфейса -i вместе со списком IP-адресов серверов DHCPv4, которые отвечают за подсеть:

   ExecStart=/usr/sbin/dhcrelay -d --no-pid **-i enp1s0<ip-address>
   

   С помощью этих дополнительных параметров dhcrelay прослушивает запросы DHCPv4 в интерфейсе enp1s0 и пересылает их на DHCP-сервер с IP <ip-address>.

4. Перезагрузите systemd manager конфигурацию:

   systemctl daemon-reload
   

5. При необходимости настройте, чтобы служба dhcrelay запускалась при загрузке системы:

   systemctl enable dhcrelay.service
   

6. Запустите службу dhcrelay:

   systemctl start dhcrelay.service
   

Для сетей IPv6:

1. Установите пакет dhcp-relay:

   yum install dhcp-relay
   

2. Скопируйте файл /lib/systemd/system/dhcrelay.service в каталог /etc/systemd/system/ и назовите файл dhcrelay6.service:

   cp /lib/systemd/system/dhcrelay.service /etc/systemd/system/dhcrelay6.service
   

   Не редактируйте файл /usr/lib/systemd/system/dhcrelay.service. Будущие обновления пакета dhcp-relay могут переопределить изменения.

3. Отредактируйте файл /etc/systemd/system/dhcrelay6.service и добавьте параметры -l receiving_interface и -u outgoing_interface:

   ExecStart=/usr/sbin/dhcrelay -d --no-pid **-l enp1s0-u enp7s0
   

   С помощью этих дополнительных параметров dhcrelay прослушивает запросы DHCPv6 на интерфейсе enp1s0 и пересылает их в сеть, подключенную к интерфейсу enp7s0.

4. Перезагрузите systemd manager конфигурацию:

   systemctl daemon-reload
   

5. При необходимости настройте, чтобы служба dhcrelay6 запускалась при загрузке системы:

   systemctl enable dhcrelay6.service
   

6. Запустите службу dhcrelay6:

   systemctl start dhcrelay6.service