Настройка dhcp relay linux
Обновлено: 06.07.2024
В дополнение к этой задаче хотелось бы поэкспериментировать, как отработает
функционал DHCP Relay поднятый на шлюзе базирующемся на Mikrotik с целью выдаче сетевого IP адреса другой сети отличной от той в которой находится сам DHCP сервис. А DHCP сервис который мне нужно развернуть на Ubuntu Trusty Server amd64 задействует пакет: isc-dhcp-server, но можно все тоже самое проделать и на dnsmasq. Впрочем это не меняет сути. Мне нужна базовая заготовка и она ниже.
$ sudo nano /etc/network/interfaces
iface eth0 inet static
$ sudo nano /etc/hostname
$ sudo nano /etc/hosts
$ sudo rm -Rf /var/lib/apt/lists
$ sudo apt-get update && sudo apt-get upgrade -y
$ sudo apt-get install isc-dhcp-server -y
$ sudo cp /etc/dhcp/dhcpd.conf /etc/dhcp/dhcpd.conf.backup
$ sudo nano /etc/dhcp/dhcpd.conf
subnet 192.168.2.0 netmask 255.255.255.0
range 192.168.2.100 192.168.2.200;
option broadcast-address 192.168.2.255;
option routers 192.168.2.1;
option domain-name "polygon.local";
subnet 192.168.3.0 netmask 255.255.255.0
range 192.168.3.100 192.168.2.200;
option broadcast-address 192.168.3.255;
option routers 192.168.3.1;
option domain-name "polygon.local";
$ sudo nano /etc/default/isc-dhcp-server
$ sudo service isc-dhcp-server restart
Если используется между этой системой и шлюзом (на базе Mikrotik с поднятым функционалом DHCP Relay), то другая система за Mikrotik получит адрес из области: 192.168.3.0/24, а точнее предопределенного диапазона в /etc/dhcp/dhcpd.conf
Отлично, основная и дополнительная задача протестирована. Теперь у меня есть то что мне было нужно на новом месте работы, ведь надеяться на кого-то это уже смешно. Мы все профессионалы и все должны уметь сами. На этом всё, с уважением автор блога Олло Александр aka ekzorchik.
Используйте прокси ((заблокировано роскомнадзором, используйте vpn или proxy)) при использовании Telegram клиента:
Поблагодари автора и новые статьи
будут появляться чаще :)
Карта МКБ: 4432-7300-2472-8059
Большое спасибо тем кто благодарит автора за практические заметки небольшими пожертвованиями. С уважением, Олло Александр aka ekzorchik.
Приветствую всех хабраюзеров. Мой первый опыт написания статей на Хабре, так что любая конструктивная критика приветствуется. Написать решил только лишь потому, что недавно столкнулся с задачей, решения которой «в лоб» не нашел.
Суть задачи в том, что в большой организации нужен был отказоустойчивый DHCP-сервер, с dhcp-relay и возможностью быстро синхронизировать конфигурацию. Основной момент, что в большинстве найденных мной руководствах рассматривается либо вариант failover, либо dhcp-relay и нигде оба варианта не рассматривались вместе да ещё и с удобным методом синхронизации конфигурации. Вдруг кому моя статья немного поможет?
Суть задачи в следующем: есть большое предприятие, сеть на >1000 компов, единственный vlan, 2 контроллера домена, в сети dhcp отсутствует(!). Предыдущие админы умели только так, но это отдельный рассказ и не для Хабра.
Понятно, что первой же задачей стала модернизация сети, а именно сегментация на vlan и внедрение dhcp. При анализе задачи были выработаны следующие требования:
- Отказоустойчивость — независимость от какого-либо железа
- Учитывая планы по сегментации сети — необходимо, чтоб сервер знал, в какой vlan какую адресацию отдавать
- «Репликация» — учитывая, что планируется широко использовать dhcp «привязки» по MAC, нужно чтоб эти «привязки» работали всегда (например, сетевые принтеры)
- Автоматическое ведение обратных DNS зон
- Две виртуальные машины на двух разных гипервизорах
- На машинах стоит centos7 и isc-dhcpd
- На dhcp настроены failover, динамическое обновление зон и распознавание option 82
- Option 82 меткой того VLAN, из которого пришел запрос, серверу отдают центральные коммутаторы L3+, на которых все VLAN и разруливаются
- Так как большинство админов плохо ориентируются в linux и vim, нужна автоматизация процесса добавления статических привязок и механизм репликации конфига
-
Для начала в Windows DNS создаем все обратные зоны для всех VLAN'ов, разрешаем зонам небезопасные обновления.
Для репликации серверов достаточно написать скрипт, который синхронизирует файлы в каталоге "/etc/dhcp/dhcpd.d/" и перезапускает dhcp-демон после этого. Сам скрипт приводить не буду из-за очень «костыльного» кода, который писался на коленке и на очень скорую руку. Возможно синхронизировать конфиги с помощью утилиты типа csync2 или rsync.
Для добавления статических привязок также был написан отдельный скрипт, который мне стыдно приводить тут по тем же причинам. Каждый может порезвиться с этим сам либо добавлять статические привязки «ручками».
Возможно это можно обойти двойным include: сначала в основном файле на вспомогательный, а во вспомогательном уже на конкретные файлы VLAN, а затем синхронизировать и вспомогательный, но я заморачиваться не стал.
Повторюсь ещё раз — большинство информации, описанной мной, в интернете навалом, но нигде я не нашел как совместить failover, dhcp-relay и сделать это удобным для синхронизации. Жду ваших замечаний и предложений
Что такое DHCP? Любой, кто имеет базовые знания о компьютерных сетях, знает, что для того, чтобы два хоста могли общаться в одной сети с использованием модели TCP/IP, оба хоста должны иметь уникальный IP-адрес. Существует два способа получения IP-адреса любым хостом в вашей сети.
Каждый сетевой хост, настроенный для получения IP-адреса динамически через DHCP, при загрузке отправит запрос DHCP по сети (по определению это широковещательная передача), чтобы узнать, есть ли где-то в сети DHCP-сервер и, следовательно, запросить конфигурацию сети. Затем DHCP-клиент обязан поддерживать связь с DHCP-сервером и регулярно обновлять свой IP-адрес в соответствии с истечением срока аренды IP-адреса. В случае, если DHCP-клиент не может обновить свой IP-адрес (отключение, хост выключен и т. д. ) его IP-адрес истекает, и DHCP-сервер может свободно выдать этот IP-адрес другому DHCP-клиенту.
DHCP-сервер ведет запись всех арендованных IP-адресов и сохраняет их в файле под названием dhcpd.leases в каталоге /var/lib/dhcp (расположение этого файла может отличаться в зависимости от используемого дистрибутива Linux ). Наличие такого файла позволяет DHCP-серверу отслеживать все арендованные IP-адреса даже после перезагрузки или сбоя питания.
Вот некоторые преимущества использования DHCP-сервера в сети:
Установка DHCP-сервера
Стандартный DHCP-сервер доступен для Linux дистрибутивов от ISC (Internet System Consortium).
Используйте следующую команду для установки DHCP-сервера, в зависимости от вашего дистрибутива Linux.
Debian и Ubuntu
Redhat и Fedora
Простая конфигурация DHCP
По-умолчанию конфигурация в файле dhcpd.conf не содержит никаких объявленных сетей, а так же в файле /etc/default/isc-dhcp-server нет указанных интерфейсов, по которым будет происходит слушание и раздача параметров. Поэтому при запуске службы вы получите ошибку.
Starting ISC DHCP server: dhcpdcheck syslog for diagnostics. . failed!
Examining log files such as /var/log/syslog reveals more details:
No subnet declaration for eth0 (some IP address).
Your server may be connected to multiple network subnets. To start DHCP server, at least one subnet must be defined within the DHCP configuration file /etc/dhcp/dhcpd.conf.
NOTE: if your server has access to more than one subnet, DHCP requires all subnets to be defined even though there isn't immediate intention to enable DHCP service on that subnet.
Поэтому для запуска нам потребуется записать в конфигурационный файл простейшее описание сети(ей):
А так же в файле /etc/default/isc-dhcp-server укажем наш интерфейс (или несколько):
Этот файл конфигурации указывает DHCP-серверу прослушивать запросы DHCP-клиента в подсети 10.1.1.0 с маской сети 255.255.255.0 на интерфейсе eth0. Кроме того, он назначит IP адреса в диапазоне 10.1.1.3-10.1.1.254. Он также определяет пустое описание для подсети 192.168.0.0.
Измените приведенный выше код с вашей подсетью и вставьте его в файл /etc/dhcp/dhcpd.conf. После перезагрузите DHCP-сервер с помощью команды:
Время аренды по-умолчанию и максимальное время аренды в DHCP
На этом этапе мы можем добавить несколько дополнительных настроек к нашей конфигурации DHCP, а именно срок действия аренды по-умолчанию и максимальное время аренды.
Определение DNS-сервера
Другим параметром конфигурации, который может быть задан DHCP-сервером своему клиенту, является определение DNS-сервера. Если вы хотите, чтобы ваши клиенты использовали DNS-сервер с IP-адресом 8.8.8.8 и 10.1.1.1, вы можете сделать это, включив опцию domain-name-servers в конфигурационный файл DHCP.
Назначим шлюз по-умолчанию
DHCP-сервер также позволяет использовать шлюз по-умолчанию для клиента. Например установим шлюз по-умолчанию 10.1.1.1 для клиентов сети 10.1.1.0, добавим строку option routers 10.1.1.1 в dhcpd.conf в соотвествующие секции:
Описание конфигурации для отдельных хостов на DHCP-сервере
Возможно, потребуется установить статический IP-адрес для конкретного хоста в сети, такого как принтер, веб-сервер и т. д. В этом случае возможно изменить конфигурацию DHCP-сервера для аренды выбранного IP-адреса конкретному хосту, определенному его MAC-адресом.
Приведенный выше файл конфигурации DHCP будет постоянно присваивать IP-адрес 10.1.1.100 хосту printer с MAC-адресом 00:16:d3:b7:8f:86 и IP-адрес 10.1.1.200 хосту web-server с MAC-адресом 00:17:a4:c2:44:22.
Как быстро настроить DHCP-клиент на Ubuntu
Чтобы настроить ваш клиент на использование DHCP через сетевой интерфейс eth0 на Ubuntu или Debian подобных, пропишите следующие строки в файле /etc/network/interfaces:
auto eth0
iface eth0 inet dhcp
Конфигурация DHCP-relay (передача полномочий другому DHCP-серверу)
Если ваш DHCP-сервер не имеет доступа к какой-то конкретной подсети, это не значит, что он не может предоставлять там свои услуги. Для выполнения этой работы агент DHCP-relay должен быть настроен в удаленной подсети, которая пересылает все запросы на указанный DHCP-сервер и удаленную подсеть. Сначала установите DHCP-relay:
Затем создайте конфигурационный файл /etc/default/isc-dhcp-relay с такими двумя строками:
Приведенный выше конфигурационный файл даст указание агенту DHCP-relay agent прослушивать на интерфейсе eth0 запросы DHCP-клиента и пересылать их на DHCP-сервер по IP-адресу 192.168.5.5.
Как работает DHCP?
- После загрузки подключенный к сети клиент (на котором настроено использование DHCP) отправляет DHCP-серверу пакет DHCPDISCOVER.
- Получив пакет запроса DHCPDISCOVER, DHCP-сервер отвечает пакетом DHCPOFFER.
- Клиент принимает пакет DHCPOFFER и отправляет серверу пакет DHCPREQUEST, подтверждая готовность принять сетевую конфигурацию, предоставленную в пакете.
- Получив от клиента пакет DHCPREQUEST, сервер отправляет пакет DHCPACK, который разрешает клиенту использование выделенного IP-адреса.
В данном руководстве мы рассмотрим настройку DHCP-сервера в Ubuntu/Debian Linux, но большенство настроек будет работать и в других дистрибутивах. Для получения административных привилегий все команды будут выполняться через sudo.
Шаг 1: Установка DHCP-сервера
1. Для установки пакета DCHP-сервера, ранее известного как dhcp3-server, нужно выполнить следующую команду:
2. После завершения установки отредактируйте файл /etc/default/isc-dhcp-server для определения интерфейсов, которые будет использовать DHCPD для обработки DHCP-запросов, при помощи опции INTERFACES.
Например, если вам нужно, чтобы демон DHCPD прослушивал eth0, задайте следующее значение:
Для этого сетевого интерфейса нужно настроить статический IP-адрес.
Шаг 2: Настройка DHCP-сервера
- параметры – указывают, как выполнять задание (например, на какое время выделять адрес), выполнять ли его вообще (например, выделять ли адреса неизвестным клиентам) или какие параметры сетевой конфигурации отправлять DHCP-клиенту.
- декларации – определяют топологию сети, описывают клиентов и предоставляемые им адреса, или применяют группу параметров к группе деклараций.
4. Для определения настроек DHCP-сервера откроем и отредактируем файл конфигурации:
5. Теперь нужно указать подсеть, в нашем примере мы будем использовать DHCP в локальной сети 192.168.10.0/24.
Здесь мы использовали следующие параметры:
Шаг 3: Настройка статических IP-адресов для машин клиентов
6. Для выделения конкретным клиентам фиксированного (статического) IP-адреса нужно добавить в файл конфигурации секции следующего вида, где явно указаны MAC-адрес и статически выделяемый IP-адрес:
7. Запустим службу DHCP и установим ее автоматический запуск при загрузке:
8. Далее нужно создать правило для службы DHCP в брандмауэре (Демон DHCPD прослушивает UDP-порт 67):
Шаг 4: Настройка машин клиентов
9. Теперь можно настроить клиентские компьютеры в сети для автоматического получения IP-адресов от DHCP-сервера.
Отредактируйте файл конфигурации интерфейса Ethernet на клиентской машине (обратите внимание на имя/номер интерфейса):
Укажите следующие опции:
Сохраните и закройте файл, а затем перезапустите сетевые службы или перезагрузите систему:
Если все настроено правильно, клиентская машина должна автоматически получать IP-адреса от DHCP-сервера.
Настройка DHCP-сервера завершена. Более подробную информацию о dhcpd и dhcpd.conf с описанием всех возможных опций можно получить в соответствующих man-страницах:
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
Шпаргалки и заметки о сетевых технологиях, серверах, СХД, IT в принципе. И о разном другом) Чтоб самому не забывать, и другим помочь.
четверг, 20 июня 2013 г.
DHCP Relay: Теория и практика настройки DHCP-Relay
В рабочей практике столкнулся с необходимостью настройки такой вещи, как DHCP-Relay. Имея небольшой практический опыт, а так же теоретическую базу, которую получил во время подготовки к CCNA и его последующем преподавании, решил, что все просто. Собственно, настроил, как помнил и. ничего не заработало. Поэтому придется разобрать данную технологию чуть подробнее, и рассмотреть различные схемы, в которых используется DHCP-Relay.Теоретическая база
Протокол DHCP (Dynamic Host Configuration Protocol) предназначен для автоматической раздачи хостам сетевых настроек. Протокол позволяет выдать пользователям необходимый IP-адрес, маску подсети, адрес основного шлюза, адрес DNS-сервера и иные настройки, необходимые пользователям. Подробно работа протокола DHCP описана в RFC 2131. Тем не менее, постараюсь дать краткое описание работы DHCP. Существует три механизма назначения адресов и настроек пользовательским устройствам: - Ручное присвоение (Manual Allocation): администратор вручную предназначает адреса пользовательским устройствам на сервере, а DHCP нужен лишь для доставки этих настроек непосредственно пользователям. - Автоматическое назначение (Automatic Allocation): DHCP автоматически выбирает адреса из набора (пула) адресов и выдает их пользователям, но при этом присваивает их перманентно, навсегда закрепляя адрес за пользователем. - Динамическое назначение (Dynamic Allocation): DHCP автоматически присваивает адреса устройствам из некоторого пула адресов, но адрес выдается на некоторое время (время аренды/leasing time). Если хост отключился от сети, его адрес может быть выдан кому-нибудь другому при условии, что время аренды на сервере так же истекло.
DHCP-Relay
Рассмотрим следующую типичную схему устройства сети
Практическая часть
С теорией все понятно. Теперь применим полученные знания к задачам, возникающим на практике. Попробуем начать с простых задач, и дойдем до (на мой взгляд) более-менее сложных.
УСЛОВИЕ: Имеем коммутатор L3 (Cisco 3750-X). Запустим на нем DHCP-Server и будем раздавать настройки всем устройствам, подключенным к нашему коммутатору.
Откровенно говоря, DHCP-сервер лучше всего создавать на маршрутизаторе. Но в данном случае все равно попробуем сделать это на коммутаторе L3, раз он умеет выполнять такую роль. Синтаксис может отличаться в зависимости от версии IOS.
Предлагаемая схема проста и представлена на рисунке ниже.
Создадим SVI для возможности подключения к коммутатору с помощью Telnet/SSH
Использовать VLAN 1 не самое правильное решение, но для тестовой схемы будем использовать его. Далее приступим к созданию DHCP-пула. Во-первых, исключим адреса, которые мы выдали серверам, шлюзам, сетевым устройствам. Например исключим диапазон с 10.10.10.250 по 10.10.10.254:
Создадим пул адресов с именем LocalNet и укажем, какие параметры необходимо выдавать хостам:
УСЛОВИЕ: Возьмем схему из предыдущего варианта и модифицируем её, добавив еще несколько SVI, VLAN, и создав для каждого из VLAN свой DHCP-пул.
К имеющемуся VLAN добавим еще два:
VLAN 2 - Department_A
Network:172.16.1.0/28, IP GW: 172.16.1.14, SVI IP: 172.16.1.13
VLAN 3 - Department_B
Network:172.16.1.16/28, IP GW: 172.16.1.30, SVI IP: 172.16.1.29
Конфигурация коммутатора будет схожа с предыдущем заданием. Пулы настраиваются точно так же:
Настроим на интерфейсах роли портов доступа (Access interface), и присвоим интерфейсам соответствие одному из VLAN. Порт g2/0/1 оставим без изменений, по умолчанию он будет находится в VLAN1:
*Mar 2 01:03:54.173: DHCPD: Reload workspace interface Vlan2 tableid 0.
*Mar 2 01:03:54.173: DHCPD: tableid for 172.16.1.13 on Vlan2 is 0
*Mar 2 01:03:54.173: DHCPD: client's VPN is .
*Mar 2 01:03:54.173: DHCPD: using received relay info.
*Mar 2 01:03:54.173: DHCPD: DHCPDISCOVER received from client 0100.0d60.7886.dc on interface Vlan2.
*Mar 2 01:03:54.173: DHCPD: using received relay info.
*Mar 2 01:04:01.236: DHCPD: Sending DHCPOFFER to client 0100.0d60.7886.dc (172.16.1.1).
*Mar 2 01:04:01.236: DHCPD: no option 125
*Mar 2 01:04:01.236: DHCPD: Check for IPe on Vlan2
*Mar 2 01:04:01.236: DHCPD: creating ARP entry (172.16.1.1, 000d.6078.86dc).
*Mar 2 01:04:01.236: DHCPD: unicasting BOOTREPLY to client 000d.6078.86dc (172.16.1.1).
*Mar 2 01:04:01.236: DHCPD: Reload workspace interface Vlan2 tableid 0.
*Mar 2 01:04:01.236: DHCPD: tableid for 172.16.1.13 on Vlan2 is 0
*Mar 2 01:04:01.236: DHCPD: client's VPN is .
*Mar 2 01:04:01.236: DHCPD: DHCPREQUEST received from client 0100.0d60.7886.dc.
*Mar 2 01:04:01.236: DHCPD: Sending DHCPACK to client 0100.0d60.7886.dc (172.16.1.1).
*Mar 2 01:04:01.236: DHCPD: no option 125
*Mar 2 01:04:01.236: DHCPD: Check for IPe on Vlan2
*Mar 2 01:04:01.236: DHCPD: creating ARP entry (172.16.1.1, 000d.6078.86dc).
*Mar 2 01:04:01.236: DHCPD: unicasting BOOTREPLY to client 000d.6078.86dc (172.16.1.1).
Конфигурация коммутатора-DHCP-сервера представлена ниже. Фактически, мы оставляем на нем созданные ранее DHCP-пулы, а так же создаем маршрутизируемй интерфейс, который будет находиться в VLAN 4.
Параметры VLAN 4:
VLAN 4 -Servers
Network:10.10.5.0/24, IP DHCPServer: 10.10.5.200, SVI IP: 10.10.5.253
*Mar 2 02:02:59.417: %SYS-5-CONFIG_I: Configured from console by console
Current configuration : 2311 bytes
!
! Last configuration change at 02:02:59 UTC Tue Mar 2 1993
!
version 12.2<omited>
!
hostname DHCPServer
!
ip dhcp excluded-address 10.10.10.253 10.10.10.254
ip dhcp excluded-address 172.16.1.13 172.16.1.14
ip dhcp excluded-address 172.16.1.29 172.16.1.30
!
ip dhcp pool LocalNet
network 10.10.10.0 255.255.255.0
default-router 10.10.10.254
dns-server 8.8.8.8
domain-name LovelyWork
!
ip dhcp pool Dep_A
network 172.16.1.0 255.255.255.240
default-router 172.16.1.14
dns-server 8.8.8.8
domain-name LovelyDepartment_A
!
ip dhcp pool Dep_B
network 172.16.1.16 255.255.255.240
default-router 172.16.1.30
dns-server 8.8.8.8
domain-name LovelyDepartment_B
!<omited>
!
interface GigabitEthernet2/0/24
no switchport
ip address 10.10.5.200 255.255.255.0
!
<omited>
end
Для настройки relay к каждому SVI был добавлен helper-address, ссылающийся на DHCP-сервер.
Подключим клиентское устройство к порт Gi1/0/3 (VLAN 3) на коммутаторе RelayAgent и рассмотрим лог команды debug:
*Mar 2 03:05:17.120: DHCPD: setting giaddr to 172.16.1.29.
*Mar 2 03:05:17.120: DHCPD: BOOTREQUEST from 0100.0d60.7886.dc forwarded to 10.10.5.200.
Ответ от DHCP-сервера приходит соответственно на SVI, принадлежащий VLAN 4, в котором и расположен DHCP-сервер. Этот ответ обрабатывается и перенаправляется клиенту. При этом relay-агент создает ARP-запись для выдаваемого сервером адреса:
*Mar 2 03:05:19.142: DHCPD: Reload workspace interface Vlan3 tableid 0.
*Mar 2 03:05:19.142: DHCPD: tableid for 172.16.1.29 on Vlan3 is 0
*Mar 2 03:05:19.142: DHCPD: client's VPN is .
*Mar 2 03:05:19.142: DHCPD: Finding a relay for client 0100.0d60.7886.dc on interface Vlan3.
*Mar 2 03:05:19.142: DHCPD: Looking up binding using address 172.16.1.29
*Mar 2 03:05:19.142: DHCPD: setting giaddr to 172.16.1.29.
*Mar 2 03:05:19.142: DHCPD: BOOTREQUEST from 0100.0d60.7886.dc forwarded to 10.10.5.200.
*Mar 2 03:05:19.142: DHCPD: Reload workspace interface Vlan4 tableid 0.
*Mar 2 03:05:19.142: DHCPD: tableid for 10.10.5.253 on Vlan4 is 0
*Mar 2 03:05:19.142: DHCPD: client's VPN is .
*Mar 2 03:05:19.142: DHCPD: forwarding BOOTREPLY to client 000d.6078.86dc.
*Mar 2 03:05:19.142: DHCPD: no option 125
*Mar 2 03:05:19.142: DHCPD: Check for IPe on Vlan3
*Mar 2 03:05:19.142: DHCPD: creating ARP entry (172.16.1.18, 000d.6078.86dc).
*Mar 2 03:05:19.142: DHCPD: unicasting BOOTREPLY to client 000d.6078.86dc (172.16.1.18).
Стоит посмотреть, есть ли какие-либо интересные изменения в логе debug на самом DHCP-сервере:
Из лога видно, что все общение сервера идет через агента. Еще одна заметная особенность: DHCP сервер не создает ARP записей в своей таблице, т.к. он не находится в одном и том же сегменте с клиентом.
Можно составить еще какие-либо схемы, используя дополнительные промежуточные устройства. Но логика настройки и работы DHCP остается неизменно.
Читайте также: