Install and configure dhcp server on centos 7/6/5 linux systems

Как настроить DNS в CentOS 8

Начиная с CentOS 6, основные настройки DNS стали прописываться в файлах /etc/sysconfig/network-scripts/, но в CentOS есть специальный файл куда попадают настройки из конфига интерфейса, называется он resolv.conf. Честно не знаю, почему так сделали. Resolv.conf — это имя компьютерного файла, используемого в различных операционных системах для настройки преобразователя системы доменных имен (DNS). Файл представляет собой простой текстовый файл, который обычно создается сетевым администратором или приложениями, которые управляют задачами конфигурации системы. Программа resolvconf — это одна из таких программ на FreeBSD или других Unix- машинах, которая управляет файлом resolv.conf.

В большинстве Unix-подобных операционных систем и других, в которых реализована библиотека распознавателя BIND Domain Name System (DNS), файл конфигурации resolv.conf содержит информацию, которая определяет рабочие параметры распознавателя DNS. DNS-распознаватель позволяет приложениям, работающим в операционной системе, преобразовывать понятные человеку доменные имена в числовые IP-адреса, необходимые для доступа к ресурсам в локальной сети или в Интернете. Процесс определения IP-адресов по доменным именам называется разрешением. В системных дистрибутивах Linux есть символическая ссылка на 

ссылка на руководство resolf.conf http://man7.org/linux/man-pages/man5/resolv.conf.5.html

Хочу отметить, что если вы соберетесь редактировать отдельно файл Resolv.conf  и вносить альтернативные DNS сервера отличные от тех, что прописаны на сетевых интерфейсах, то после перезагрузки сервера они снова будут затерты на те, что прописаны в конфигурационных файлах сетевых интерфейсов. Давайте я для примера добавлю в это файл сервера Google 8.8.8.8 и 8.8.4.4.

vi /etc/resolv.conf

Перезапустим сеть:

systemctl restart NetworkManager.service

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

Использования Solaris

Этот DHCP освобождает системного или сетевого администратора от некоторых трудоемких задач, связанных с настройкой сети TCP/IP и ежедневным управлением ею, он работает только с IPv4. Solaris DHCP предлагает следующие преимущества:

1. Управление IP-адресом. В сети без DHCP администратор вручную присваивает IP-адрес, пытаясь назначить уникальные адреса клиенту и индивидуально настраивать их.
2. Если арендатор перемещается в другую сеть, администратор должен внести изменения вручную для этого клиента.
3. Когда DHCP включен, DHCP-сервер управляет и назначает IP-адреса без вмешательства администратора.
4. Конфигурация централизованного сетевого клиента.
5. Сетевой администратор может создать индивидуальную конфигурацию для определенных пользователей или определенных типов клиентов и хранить информацию в одном месте, хранилище данных DHCP. Он может предоставить им всю необходимую ему информацию, включая IP-адрес, загрузочный сервер и информацию о конфигурации сети.
6. Поскольку запросы загрузки сети могут быть ретранслированы по подсетям, можно развернуть меньше серверов.
7. Загрузка RARP требует, чтобы каждая подсеть имела загрузочный сервер и сеть с dhcp сервеошиб ром.

Сетевые настройки на сервере CentOS

Первый раз с сетевыми настройками сервера CentOS 7 или 8 мы сталкиваемся, когда производим установку. На экране первоначальной настройки есть отдельный пункт, касающийся настройки сетевых интерфейсов:

Зайдя в него мы видим список подключенных сетевых карт. Каждую из них можно включить соответствующим ползунком (пункт 1 на картинке). При активировании интерфейса он автоматически получает настройки по dhcp. Результат работы dhcp можно посмотреть тут же. Если вас не устраивают эти настройки, их можно отредактировать, нажав configure (пункт 3 на картинке). Здесь же можно задать hostname (пункт 2 на картинке):

Открыв окно дополнительный настроек Ehernet, вы сможете изменить имя сетевого интерфейса, указать настройки IP (пункт 1 на картинке), выбрать ручные настройки (пункт 2 на картинке), назначить ip адрес (пункт 3 на картинке), установить dns сервер (пункт 4 на картинке) и сохранить сетевые настройки (пункт 5 на картинке):

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

Теперь рассмотрим другую ситуацию. Сервер, а соответственно и конфигурацию сети, производили не вы, а теперь вам надо ее посмотреть либо изменить. В вашем распоряжении консоль сервера, в ней и будем работать. Если у вас установка производилась с дистрибутива minimal, то при попытке посмотреть сетевые настройки с помощью команды ifconfig в консоли вы увидите следующее:

или в русской версии:

Для работы с ifconfig и прочими сетевыми утилитами необходимо установить пакет net-tools. Сделаем это:

Теперь можно увидеть настройки сети:

Если у вас нет желания устанавливать дополнительный пакет, то можно воспользоваться более простой командой ip с параметрами:

Мы увидели конфигурацию сети, теперь давайте ее отредактируем. Допустим, нам нужно сменить ip адрес. Для этого идем в директорию /etc/sysconfig/network-scripts и открываем на редактирование файл ifcfg-eth0 или ifcfg-ens18. Название файла будет зависеть от имени сетевого интерфейса. В Centos 8 по-умолчанию убрали поддержку настройки сети через конфигурационные скрипты, поэтому установите отдельно пакет network-scripts.

По настройкам из этого файла мы получаем ip адрес по dhcp. Чтобы вручную прописать статический ip, приводим файл к следующему содержанию:

Мы изменили параметры:

BOOTPROTO	с dhcp на none
DNS1	указали dns сервер
IPADDR0	настроили статический ip адрес
PREFIX0	указали маску подсети
GATEWAY0	настроили шлюз по-умолчанию

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

Проверяем, применилась ли новая конфигурация сети:

Все в порядке, новые настройки сетевого интерфейса установлены.

ОПИСАНИЕ

Файл dhcpd.conf содержит информацию о настройкахdhcpd, сервера DHCP разработанного в ISC

Файл dhcpd.conf имеет простой текстовый формат. Разбор файла производится
встроенным в dhcpd парсером. Файл может содержать дополнительные пробелы,
символы табуляции и пустые строки для придания более читабельного вида.
Ключевые слова не чувствительны к регистру. Комментарии могут располагаться
в любом месте, он только не в кавычках. Комментарии начинаются с символа #
и продолжаются до конца строки.

По существу файл состоит из секций-объявлений вида: имя_секции {…}.
В фигурных скобках могут быть заключены другие секции(подсекции) и параметры

Параметры используются для что бы определить поведение сервера:

• что и как делать (например на какой срок выдавать адрес)
• делать ли вообще (например выдавать ли адреса неизвестным клиентам)
• какие дополнительные параметры, кроме IP адреса, предоставлять клиенту
  (например шлюз по умолчанию или адреса серверов DNS).

Секции-объявления используются для:

• описания топологии сети
• описания клиентов сети
• описания адресов которые должны предоставлены клиентам
• присвоить группу параметров одновременно в нескольким секциям

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

Секции описывающие топологию сети включают следующие подсекции:

shared-network и  subnet.
Если клиентам в подсети адреса назначаются динамически, то
инструкция range должна быть использована в секцииsubnet. Для клиентов со статически назначенными адресами, или для конфигураций
в которых обслуживаются только известные клиенты, для каждого из них должен быть
описан параметр host
Если необходимо присвоить значения параметрам, в нескольких подсекциях,
которые не сгруппированы на основе принадлежности к одной подсети, то их можно
сгруппировать, поместив в секцию group.

Для каждой обслуживаемой подсети, и для каждой подсети к которой подключен dhcp сервер,
должны быть объявлены секции subnet, которые говорят серверу как распознать
какой адрес к какой подсети относится. Секция subnet требуется для каждой подсети
даже если в ней нет динамически выделяемых адресов.

Иногда случается что в одном физическом сегменте сосуществуют несколько IP подсетей.
Например в организации существует требование использовать 8-битные маски подсетей,
но сеть разрослась до размеров превышающих 254 хоста, в этом случае необходимо использовать
две подсети с 8-битными масками до тех пор пока новый ethernet сегмент не будет добавлен.
В этом случае секции subnet описывающие две эти подсети могут быть заключены в
секцию shared-network.

В некоторых случаях встречаются топологии когда клиенты находятся болле чем в одной
подсети, и в этом случае бывает предпочтительно назначить этим клиентам набор параметров
отличный от тех что назначаются другим клиентам в той же подсети. Клиенты которые
явно объявляются в подсекциях host, могут быть объединены в группу
с помощью объявления group, и в этой секции указываются параметры общие для
всей группы. Для клиентов чьи адреса назначаются динамически не существует способа
назначения параметров всей группе иначе как сгруппировав в соответствии в топологией сети.

Когда клиент загружается, начальные параметры определяются в соответствующем клиенту
объявлении host, затем проверяется секция group (если она существует)
которая содержит в себе host, далее проверяется секция subnet соответствующая
подсети в которой находится клиент, после этого проверяется указаны ли какие-нибудь параметры
в секции shared-network(если есть), содержащей нашу подсеть, ну и наконец
проверяются глобальные параметры, которые могут быть указаны перед всеми объявлениями.

Когда dhcpd ищет секцию host для соответствующего клиента, он следует
следующим правилам:
сперва ищется объявление host где указан параметр fixed-address
и секция subnet или shared network совпадает с подсетью в которой
находится клиент. Если нет соответствующих записей, dhcpd ищет объявление host
без параметра fixed-address. Если подходящих записей не найдено, то dhcpd считает
что нет записей для этого клиента, даже если они есть для этого клиента в другой подсети.

Протокол VRRP

VRRP — это аббревиатура Virtual Redundant Router Protocol. Группа физических маршрутизаторов объединяется в один виртуальный. Каждый участник группы может находиться в 3 состояниях:

• неопределенном (initialize)
• основном (master)
• резервном (backup)

У всех участников группы в настройках присутствует 1 или несколько виртуальных адресов. У основного эти адреса присвоены сетевой карте, а у других — просто ждут своего часа.

Прежде всего надо сказать, что VRRP работает поверх IP, а не напрямую поверх канального уровня. Если быть точным, он использует групповой (multicast) адрес 224.0.0.18. Поскольку multicast по умолчанию не маршрутизируется, взаимодействие возможно только в пределах одной физической сети.

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

Надо сразу сказать, что основной (служебный) адрес совсем не должен быть из одной сети с виртуальными. Если у вас недостаточно публичных адресов для тех сетевых карт, которые смотрят в интернет, вы вполне можете использовать частные адреса из RFC 1918 в качестве служебных. Ну, если настройки вашего провайдера этого не запрещают.

У каждой группы маршрутизаторов есть VRID — Virtual Router Identifier. Это просто число в диапазоне от 1 до 255. С каждой такой группой может быть ассоциирован 1 или несколько виртуальных адресов. На уровне протокола список адресов передается, но только для отладочных целей. Процесс VRRP их никак не использует, тем более что передаются они без маски подсети, так что за идентичностью настроек виртуальных адресов надо следить самому.

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

При загрузке или первичной настройке VRRP участники группы оказываются в неопределенном состоянии (initialize) и выбирают, кому быть основным, а кому резервным. В настройках VRRP можно указать приоритет (priority) — маршрутизатор с наибольшим приоритетом выигрывает выборы.

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

Маршрутизатор, который выбрали основным, присваивает своей сетевой карте виртуальные адреса и начинает посылать остальным пакеты VRRP advertisement. Таким образом он сообщает, что еще функционирует и работоспособен.

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

Что будет, если бывший основной маршрутизатор вернется к жизни? Все зависит от опции
preempt в настройках. Если она включена, то он повторно инициирует выборы и вернет себе былую славу. Если нет, так и останется резервным.

Включать или не включать
preempt — вам решать. С одной стороны, с этой настройкой легко предсказать, какой маршрутизатор в данный момент основной, а с другой — переключений состояния, а значит, и потерянных пакетов будет больше. Я как правило включаю, но свое мнение никому не навязываю.

Что делать, если CentOS не видит сетевую карту?

Вы установили сервер, загрузились и обнаружили, что в системе нет ни одной сетевой карты. Что в таком случае делать? Первым делом посмотрите вывод команды dmesg и поищите там поминание о своей карте. Возможно, она в системе есть, просто не активирована. Активировать ее можно с помощью nmtui, а котором я рассказывал выше.

Там есть пункт меню Activate connection, нужно в него зайти и активировать вашу сетевую карту. После этого ее можно будет настраивать.

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

Есть еще вероятность, что вы не увидите своей карточки при выводе команды ifconfig, если в эту карту не воткнут сетевой провод. Чтобы наверняка посмотреть все интерфейсы, необходимо использовать ключ -a:

Есть еще один способ поискать сетевую карту в системе. Установите пакет pciutils:

И посмотрите вывод команды:

Если сетевая карта видится системой, то должно быть что-то в этом роде:

Если в выводе пусто, значит сетевая карта не определена.

Как отключить ipv6

В настоящее время активного использования протокола ipv6 в России нет и в обычной работе он чаще всего не нужен. Хотя нас уже много лет пугают, что свободных ip адресов уже практически не осталось, но на деле пока еще всем хватает. Так что с точки зрения практических соображений ipv6 в настоящее время на сервере не нужен и его можно отключить.

Перед отключением ipv6 в  centos необходимо на всякий случай проверить, какие программы его используют в своей работе. Это нужно для того, чтобы избежать ошибок в их работе, предварительно отключив ipv6 в конфигурациях. Для того, чтобы увидеть, какие программы висят на ipv6 интерфейсе воспользуемся командой netstat:

Все строки с ::: это ipv6 протокол. В моем случае это sshd, postfix и chronyd. Отключим им ipv6 и оставим только ipv4.

Начнем с sshd. Открываем файл настроек /etc/ssh/sshd_config и находим строки:

Раскомментируем их и изменим. Должно получиться вот так:

Теперь открываем файл настроек постфикс /etc/postfix/main.cf. Ищем там строку:

Меняем на:

Отключаем ipv6 в chronyd. Для этого создаем файл /etc/sysconfig/chronyd и добавляем строку:

Теперь отключаем ipv6 в CentOS. Открываем файл /etc/sysctl.conf и добавляем туда строки:

Редактируем файл /etc/sysconfig/network, добавляя туда:

Добавляем запрет на работу ipv6 в конфигурацию grub. Открываем конфиг /etc/default/grub и добавляем к параметру GRUB_CMDLINE_LINUX еще одно значение ipv6.disable=1. Должно получиться примерно так:

После этого обновляем конфиг загрузчика.

Перезагружаемся и проверяем результат:

Нигде нет упоминания про inet6 и адреса формата ipv6. Значит все в порядке, мы отключили ipv6 в CentOS. Теперь проверим список открытых портов:

Все порты ipv4. Все в порядке, наша задача выполнена.

Глобальный пул адресов

В большой сети компьютеры в сети не могут напрямую подключаться к USG через интерфейс Ethernet, но должны проходить через другие устройства. В этом случае, чтобы гарантировать, что компьютеры динамически получают айпи из USG, обычно необходимо наладить DHCP на основе глобального пула адресов. DHCP динамически выделяет айпи для пользователей в одном и том же сетевом сегменте. Сетевой сегмент 10.1.1.0/24 пула IP можно разделить на два, а именно 10.1.1.0/25 и 10.1.1.128/25. Айпи двух интерфейсов GigabitEthernet на DHCP равны соответственно 10.1.1.1.25 и 10.1.1.129/25.

Срок аренды в сегменте сети 10.1.1.0/25 составляет 10 дней и 12 часов, доменное имя — dhcpserver.com, IP-адрес DNS-сервера — 10.1.1.2, без IP сервера NetBIOS существует, а IP-адрес устройства маршрутизации на выходе — 10.1.1.126. Срок аренды IP в сегменте сети 10.1.1.128/25 составляет 5 дней, доменное имя — dhcpserver.com, IP сервера — 10.1.1.2, адрес NetBIOS — 10.1. 1.4, а IP с устройства маршрутизации на выходе — 10.1.1.254.

Перед тем как включить службу DHCP, задают айпи, которые не выделяются автоматически сервером NetBIOS и исходящего шлюза и настраивают общие атрибуты пула адресов. Далее, настраивают связанные атрибуты пула, исходящий шлюз, айпи NetBIOS и срок аренды. Например, для трех пулов IP: Пул IP 0 используется для наладки общих атрибутов для всех потребителей.

Пул IP 1 и 2 применяют для настройки соответствующих атрибутов разных клиентов соответственно. В этом примере пользователи могут настраивать только два пула IP-адресов, а именно пул IP-адресов 1 и пул IP-адресов 2. Таким образом, оба пула IP-адресов не могут наследовать конфигурации из родительского режима. Поэтому атрибуты каждого пула IP-адресов должны быть настроены соответственно.

Взаимодействие DHCP-сервера и клиента

Сервер и клиент обмениваются сообщениями по принципу «запрос-ответ». Взаимодействие состоит из 4 этапов и сокращенно называется «DORA». По одной букве на каждый этап:

1. Поиск – Discover.

2. Предложение – Offer.

3. Запрос – Request.

4. Подтверждение – Acknowledgement (ACK).

Поиск (Discover): Клиент → Сервер

На этом этапе клиенту главное найти и узнать, где находится сервер. 

Мы включили компьютер, который находится в сети. Еще в этой же сети работает DHCP. В данном случае наш компьютер – это клиент, а DHCP – сервер. Теперь нашему устройству необходимо получить IP-адрес и другую необходимую информацию о сети, например шлюз, адреса DNS и маску подсети. Поэтому клиент начинает поиски сервера и посылает сообщение «DHCPDISCOVER» на компьютеры внутри этого сегмента сети. 

Такое сообщение называется широковещательным (broadcast) – это значит, что поток данных от клиента получат все устройства внутри его сети. Ответить на такое сообщение смогут только DHCP-серверы.

Запрос клиента получат все участники сети, но ответит только сервер

Предложение (Offer): Сервер → Клиент

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

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

Если клиенту ответили несколько серверов, он выберет какой-то один и получит от него IP-адрес с настройками.

Запрос (Request): Клиент → Сервер

Клиент получил IP-адрес и отправляет серверу ответное сообщение: «DHCPREQUEST». В нем он еще раз прописывает полученный адрес и тем самым подтверждает, что будет использовать его.

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

Только один сервер продолжает взаимодействие с клиентом. Это тот, который предложил выбранный клиентом IP-адрес.

Подтверждение (ACK): Сервер → Клиент

Сервер отправляет сообщение «DHCPACK» и тем самым закрепляет IP-адрес за клиентом. В сообщении содержится сам адрес, срок его использования и дополнительные настройки сети. Клиент проверяет эти настройки, применяет полученную конфигурацию и получает доступ к сети. 

В общем виде весь процесс взаимодействия выглядит так:

– (Клиент) Кто тут сервер? Мне надо получить IP-адрес: «DHCPDISCOVER».

– (Сервер) Я сервер, предлагаю тебе использовать вот этот IP: «DHCPOFFER».

– (Клиент) Хорошо, я буду использовать этот IP, что ты мне отправил: «DHCPREQUEST».

– (Сервер) Вот и договорились. Приятной работы в сети: «DHCPACK».

Другие варианты сообщений

• «DHCPINFORM» – так клиент запрашивает локальные настройки сети. В ответ на это сообщение сервер посылает запрашиваемую конфигурацию.

• «DHCPNAK» – так сервер отказывает клиенту пользоваться IP-адресом.

• «DHCPRELEASE» – так клиент сообщает, что отключается от сети и освобождает свой IP-адрес. После этого сервер снова добавляет этот адрес в список доступных.

Настройка сети через консоль с помощью networking

Кроме NetworkManager, сетями управляет служба Networking. Она интегрирована с NetworkManager и позволяет настроить все необходимые вам параметры с помощью редактирования конфигурационных файлов. Сначала нам нужно посмотреть список сетевых интерфейсов:

У меня имя сетевого интерфейса enp2s0f0. Именно на его примере дальше будет выполняться подключение к сети centos 7. Все настройки для сети Networking хранятся в каталоге /etc/sysconfig/network-scripts/. Для нашего сетевого интерфейса конфигурационный файл будет называться /etc/sysconfig/network-scripts/ifcfg-enp2s0f0.

Давайте сначала рассмотрим основные параметры, которые вам придется рассмотреть:

• TYPE — тип соединения, проводное (Ethernet), беспроводное(Wired) и т д;
• BOOTPROTO — способ получения IP адреса, static, dhcp или none;
• NAME — имя соединения;
• DEVICE — имя сетевого интерфейса;
• ONBOOT — необходимо ли запускать при старте системы;
• IPADDR — IP адрес, который будет использован для этого компьютера;
• GATEWAY — шлюз для доступа к интернету;
• NETMASK — маска сети;
• DNS1 — сервер для разрешения доменных имен DNS.

Фактически вы уже знаете большинство этих параметров. Теперь рассмотрим какой набор нужно задать для каждого способа получения IP адреса.

Настройка получения IP по DHCP

Настройка сети dhcp centos предусматривает использование значения BOOTPROTO dhcp, остальные параметры задавать необязательно:

Теперь сохраните изменения и перезапустите сеть. Все должно заработать.

Настройка сети со статическим IP

Для установки статического IP адреса нужно задать значение BOOTPROTO — static, а также указать IP адрес, шлюз, маску сети и DNS. Вот пример конфигурации сети CentOS для нашего интерфейса:

Укажите свои значения и сохраните настройки. Для перезагрузки сети используйте команду:

Затем вам останется проверить работу сети. Если все было сделано правильно сеть будет работать.

Step 4: Setup Client System

At this stage we have a running dhcp server which is ready for accepting requests and assign them a proper ip. but to verify I have another CentOS machine running on same LAN. Now login to that client machine and edit Ethernet configuration file.

# vim /etc/sysconfig/network-scripts/ifcfg-eth1

DEVICE=eth1
BOOTPROTO=dhcp
TYPE=Ethernet
ONBOOT=yes

Make sure BOOTPROTO is set to dhcp.

Let’s restart network services on client system. You will get that dhcp server assigned an ip address from defined subnet. If you have connected to client pc from remote login, Your session can be disconnect.

For CentOS/RHEL 7

# systemctl restart network

For CentOS/RHEL 6/5

# service network restart

Hints: 	
1. By default dhcp server is listening to the first NIC card which is eth0 "in most CentOS/Redhat Linux"
2. To change the dhcp server to listen to another NIC interface you need to edit /etc/sysconfig/dhcpd

Работа сетевых сервисов DHCP и DNS

DNS – система доменных имен. Она нужна для того, чтобы одному IP-адресу соответствовало одно доменное имя. Доменное имя может присваиваться не только сайту, но и клиенту в ЛВС. Например, Buhgalter PC. DNS сопоставляет IP-адреса с доменами.

С проблемой взаимодействия DHCP и DNS сталкиваются пользователи Linux. В этой ОС отсутствует Active Directory, благодаря которой можно создать связь между доменом и IP. Но существуют альтернативные способы настройки этих двух сетевых сервисов в Linux. Использование пакета dnsmasq – один из них.

После установки пакета dnsmasq через терминал необходимо отредактировать файл конфигурации. В файле содержатся комментарии с объяснениями каждой настройки. После завершения редактирования конфигурации можно приступать к настройке фаервола. Удобнее всего это делать через Ubuntu Uncomplicated Firewall. Нужно будет открыть для DNS 53 порт с помощью следующих команд:

• sudo ufw allow bootps
• sudo ufw allow 53/udp
• sudo ufw allow 53/tcp

Заключительный этап – корректировка настроек роутера. В веб-интерфейсе устройства нужно отключить DHCP для ЛВС и изменить настройки DNS таким образом, чтобы все они указывали на настроенный DHCP-сервер. После этого необходимо перезапустить сеть на сервере.

Заключение

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

Популярные услуги

Виртуальная инфраструктура IaaS
IaaS – решение, которое позволяет отказаться от использования физического оборудования и значительно сократить расходы компании.

Гибридные облака
Гибридное облако (hybridcloud) – отдельная IT-инфраструктура, представляющая собой объединение виртуального приватного облака (VPC) и выделенных серверов. Использование гибридных решений позволяет компании решить нехватку собственных ресурсов за счет мощностей облачного провайдера.

Заключение

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

1. Сервер был введен в домен Windows для настройки авторизации доменных пользователей на прокси сервере.
2. Настроен прокси сервер squid для работы с доменными учетными записями.
3. Собран из исходников многофункциональный web интерфейс для управления squid — sams2 самой последней на текущий момент версии.

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

Уровень данной статьи получился чуть выше, чем может рассчитывать новичок в линуксе, но тем не менее я постарался расписать все максимально подробно. Все этапы проверены на чистой системе, чтобы убедиться в достоверности данных и отсутствии ошибок. То есть сначала была исследована тема, настроена конфигурация на тестовой машине. После того, как я убедился, что все работает так, как мне нужно, я на чистой системе еще раз с нуля провел всю конфигурацию по своей шпаргалке и зафиксировал эту чистую настройку в статье.

Если у вас есть желание научиться администрировать системы на базе Linux, но вы с ними никогда не работали и не знакомы, то рекомендую начать с онлайн-курса «Linux для начинающих» в OTUS. Курс для новичков, для тех, кто с Linux не знаком. Цена за курс минимальная (символическая). Информация о курсе и цене.