Как работают сети: что такое свитч, роутер, DNS, DHCP, NAT, VPN и ещё с десяток необходимых вещей
Тема сетей, к сожалению, весьма скучна для большинства наших коллег. Всем основным задействованным технологиям, протоколам и лучшим практикам уже несколько десятков лет, они давно окружают нас и обеспечивают взаимодействие миллиардов устройств вокруг. Даже программисты чаще всего воспринимают сеть как данность и не задумываются о том, как же она работает.
Часто бывает у наших коллег: вроде бы слова IP и DNS используют каждый день, а понимания как это всё работает нет, и как это всё пощупать вживую тоже непонятно. Такое отношение не только некорректно, но и вредно для карьеры любого уважающего себя инженера из IT. Сколько бы JS-фреймворков ты не выучил, без знания основ сетей тебя никто всерьёз воспринимать не будет. Ни одна часть инфраструктуры не должна оставаться чёрной коробкой ни для разработчиков, ни для администраторов, ни уж тем более для тебя, будущего DevOps инженера.
Целью этой статьи не является дать исчерпывающее руководство по сетям. Внутри самой статьи и в её конце я приведу множество ссылок на ресурсы, которые помогут тебе углубить полученные знания. Не ленись и кликай по всем ссылкам и читай их все.
В этом же тексте мы сфокусируемся на структуре сети, основных её компонентах и рассмотрим как они используются на практике при помощи уже освоенных нами в предущей статье виртуальных машин и libvirt/KVM в частности.
Сетевая модель OSI
В первую очередь нам нужно познакомиться с сетевой моделью OSI. Эта модель стандартизирует взаимодействие сетевых протоколов.
OSI делит коммуникацию на 7 слоёв, на каждом слое есть свои протоколы. Ты часто будешь слышать вещи в духе «это происходит на Layer 3». Вот эти слои:
Физический уровень (physical layer)
Протоколы этого уровня отвечают за связь между железками на самом низком уровне. Непосредственная передача данных по проводам (и без проводов) описывается как раз на физическом уровне. Примеры протоколов: Wi-Fi, Bluetooth, DSL.
Канальный уровень (data link layer)
Канальный уровень отвечает за передачу данных между устройствами одной сети. Данные передаются в виде кадров (frames), в кадре указан физический адрес получателя и отправителя. Этот адрес называется MAC-адрес.
Кто же выступает в роли отправителя и получателя?
Во-первых, у каждой машины (включая твой ноут) есть NIC — Network Interface Controller. Это железка (или виртуальная железка), которая отвечает за передачу и приём кадров. У NIC есть MAC-адрес — уникальный адрес, который обычно прошит в железке, или же генерируется системой виртуализации.
Само собой, у машины может быть несколько NIC. Посмотрим интерфейсы при помощи команды ip :
lo — это loopback device, специальный виртуальный интерфейс, который система использует, чтобы общаться самой с собой. Благодаря lo даже без подключения к сети локальные приложения могут взаимодействовать друг с другом.
Ты уже заметил, что из твоего компьютера не вылазят миллиарды проводов, напрямую подключённые ко всем другим компьютерам мира. Для организации сети нужны дополнительные устройства.
Например, свитч (switch).
Свитч — это такое устройство, которое формирует сеть, и в которое подключаются наши машинки через порты. Задача свитча L2 (есть ещё более продвинутые, относящиеся к L3 и даже к L7) — перенаправлять кадры от MAC отправителя к MAC получателя. Множество машин, подключенных к одному свитчу формируют локальную сеть (LAN).
Конечно, пачка серверов подключенных к одному свитчу — это весьма тривиальный способ создать сеть. А что если мы хотим объединить в одну сеть сервера, находящиеся в разных физических локациях? Или, например, хотим логически разделить сервера подключенные к одному свитчу в одной локации в разные сети?
Для таких случаев создают VLAN (виртуальную локальную сеть), которую можно реализовать, например, при помощи свитча. Работает это достаточно просто: к кадрам добавляется дополнительный заголовок с VLAN-тегом, по которому и определяется к какой сети принадлежит кадр.
Другое устройство — мост (bridge). Мост L2 используют чтобы объединить две сети, сформированные при помощи свитчей, примерно таким образом:
И свитчи и мосты (а ещё хабы (hub), о которых почитай сам) помогают объединить несколько машин в одну сеть. А есть ещё маршрутизаторы (или роутеры, routers), которые соединяют сети между собой и работают уже на L3. Например, твой Wi-Fi роутер соединяет твою локальную сеть (в которой находятся твой ноутбук, телефон и планшет) с Интернетом.
Помимо LAN разделяют ещё несколько типов сетей. Например, WAN. Интернет можно считать за WAN, за тем исключением, что Интернет полностью стирает географические границы сети.
Как я уже упомянул, есть ещё свитчи L3, которые могут не просто перенаправлять кадры от одного устройства к другому, но и обладают более продвинутыми фишками, типа маршрутизации. Чем же отличается роутер от свитча L3, спросишь ты? Тут всё сложно (и скучно), но если тебе интересно, то прочитай статью Layer 3 Switches compared to Routers
Сетевой уровень (network layer)
На третьем, сетевом уровне используются не MAC, а IP адреса. Посмотрим IP адрес нашей машины при помощи той же самой команды ip :
Интерфейсу eth0 присвоен адрес 192.168.122.212/24.
IPv6 адресов гораздо больше. Но полный переход IPv6 ещё не произошёл 🙂
Вручную всё считать необязательно, можно воспользоваться калькулятором.
Мы уже знаем, что на L2 используются MAC-адреса, а на L3 — IP адреса. Должен существовать какой-то механизм, который ассоциирует MAC-адрес сервера с его IP адресом. Этот механим называется ARP (Address Resolution Protocol).
В данном случае, 192.168.178.1 — это IP адрес моего Wi-Fi роутера, к которому ноутбук подключен через интерфейс wlp3s0.
Один из видов кибер-атак связан с ARP и называется ARP spoofing. Цель такой атаки — подменить MAC-адрес, ассоциированный с определённым IP, на адрес машины хакера. Как страшно жить, да?
Но как именно у сетевого интерфейса появляется IP адрес? Один из вариантов — задать его вручную. Недостаток: ручная работа. Если руки кривые, то можно настроить дублирующиеся адреса и получить конфликт 🙂
Другой вариант: Dynamic Host Configuration Protocol (DHCP), протокол, использующийся для автоматического выставления различной конфигурации, в том числе IP-адресов.
Для работы DHCP нужен DHCP-сервер, раздающий IP-адреса и DHCP-клиент на твоей машине, который будет запрашивать адрес для этой машины. В домашних условиях чаще всего DHCP-сервер находится на роутере.
Чтобы понять как именно работает DHCP, нам нужно отвлечься на понятие «broadcasting». Это процесс, в котором наш сервер отправляет сообщение на все сервера в сети, так как он не знает где именно находится та информация, которая ему нужна. Ближе всего такое broadcast общение к радио вещанию.
Как это происходит в случае с DHCP:
А где хранятся настройки соединений?
Обрати внимание на BOOTPROTO=dhcp — эта опция означает, что будет использован DHCP-сервер, в том числе для получения IP адреса. Для сравнения, конфиг соединения для loopback устройства:
Командой ip r add можно добавлять новые пути, а командой ip r del — удалять.
Про DNS ты наверняка слышишь не в первый раз. Простая идея: обращаться к серверу не по IP адресу (тяжело запомнить для людей), а по нормальному имени.
Самый старый и популярный DNS-сервер (тот, что хранит информацию об адресах и отвечает на запросы) — это BIND. Альтернатив тоже много, но тебе в первую очередь рекомендуется развернуть локально именно BIND.
Обязателен к прочтению материал от Cisco DNS Best Practices, Network Protections, and Attack Identification — там узнаешь не только все основы DNS, но и кучу важных рекомендаций по созданию безопасного и устойчивого DNS-сервера.
Есть возможность обновлять записи в DNS-сервере динамически. Для этого почитай про nsupdate. Ниже найдёшь ссылку на отличное руководство по настройке, включая безопасное обновление записей. Одно из интересных применений — service discovery. Поищи в Интернете, о чём это, или дождись соответствующей статьи на mkdev 😉
До появления DNS всё, что у нас было — это файлик /etc/hosts. Он и сейчас часто используется.
Ещё очень интересен файлик /etc/nsswitch.conf. В нём определяется в каком порядке и где искать разную информацию, в том числе где искать хосты. По-умолчанию, сначала они ищутся в /etc/hosts, а уже потом отправляется запрос в DNS-сервер.
Используемый для разрешения DNS-имён сервер, кстати, указан в /etc/resolv.conf.
Дебажить DNS проблемы удобнее всего командой dig и nslookup. Например, чтобы запросить информацию о mkdev.me у nameserver 8.8.8.8 можно сделать так:
Виртуалки
До этого момента все примеры выполнялись на локальной машине. Это, конечно, полезно для восприятия, но не так интересно. Поэтому дальше мы укрепим только что прочитанное при помощи виртуальных машин и libvirt, а заодно познакомимся с ещё парой терминов.
В первую очередь, создадим виртуалку при помощи virt-install:
По-умолчанию libvirt создаёт одну сеть:
connections показывает количество машинок, подключённых к этой сети. Подробное описание всех возможных опций этого XML-файла можно прочитать в документации libvirt. Нас же сейчас интересуют два слова: bridge и dhcp.
Создание сети в libvirt по умолчанию приравнивается к созданию виртуального свитча, к которому цепляются все виртуалки, тем самым образую локальную сеть, LAN.
Реализован свитч virbr0 при помощи Linux Bridge — технологии, изначально предназначенной как раз для создания виртуальных локальных сетей. Выполнив команду brctl show на хост-машине можно увидеть список всех свитчей.
Linux Bridge «слегка» отличается от типичного железного свитча L2. За годы его существования к нему прилепили множество дополнительных фич, например, фильтрацию трафика и файрвол. Корректнее всего назвать его свитчем L3, но здесь ваш покорный слуга не уверен до конца.
Теперь обратим внимание на следующую секцию:
Здесь указан блок адресов, использующихся для виртуальных машин в этой сети. 192.168.122.1 — IP-адрес хост-машины в пределах этой виртуальной сети.
Выполнив ip r в виртуалке увидим:
По умолчанию трафик из виртуалки во внешний мир идёт через хост-машину. В качестве забавы можешь настроить, чтобы трафик к одной виртуалке шёл через другую.
Как мы уже знаем, за назначение IP адресов отвечает служба DHCP. Libvirt использует dnsmaq для DHCP и DNS и запускает по экземпляру dnsmasq для каждой сети.
Мы можем посмотреть табличку DHCP, которая покажет нам выданные адреса:
Обрати внимание, что 52:54:00:05:36:e6 это MAC-адрес интерфейса eth0 нашей виртуалки.
Читая ранее про CIDR тебя могло кое-что насторожить: даже если мы разделим сеть на много блоков, то общее количество IP адресов не увеличится. На самом деле, всегда используется комбинация из частных и публичных адресов. Обычно за одним публичным адресом прячется множество машин, у каждой из которых есть свой частный адрес.
Хост-машина, если мы продолжаем использовать для неё свой личный ноутбук у себя дома, прячется на Wi-Fi роутером и так же не обладает собственным публичным адресом.
На первый взгляд, то, что виртуалки имеют доступ к Интернету, кажется само собой разумеющимся. Но ведь у виртуалки есть только частный адрес, недоступный вне хост машины. Публичному серверу, к которому виртуалка обращается, нужно куда-то отправлять ответ и частный IP адрес виртуалки он просто-напросто не сможет найти (на то он и частный).
Эту проблему решает NAT (Network Address Translation) — механизм преобразования IP адресов в сетевых пакетах. Обычно в пакете указан IP, откуда пакет отправлен и IP, куда пакет идёт. NAT позволяет динамически менять эти адреса и сохранять таблицу подменённых адресов.
Существует SNAT (source NAT), который и используется для наших виртуалок для доступа в Интернет. Когда пакет отправляется, то его исходящий адрес заменяется на адрес хост машины. Когда ответ от сервера назначения идёт назад, то адрес меняется с адреса хост машины на адрес виртуалки. Меняет адрес роутер.
DNAT (destination NAT) занимается примерно тем же самым, но наоборот: это когда ты обращаешься к некоему публичному адресу, за которым скрываются частные, локальные адреса.
NAT — способ по умолчанию для общения виртуалок с внешним миром. Но libvirt штука гибкая. Можно, например, цеплять виртуалки напрямую к физическому интерфейсу хоста, вместо виртуального свитча. Вариантов создания сети, на самом деле, много.
Для NAT libvirt использует iptables. Если кратко, то это инструмент, отвечающий за фильтрацию сетевых пакетов. iptables настраиваются через специальные правила (rules), которые комбинируются в цепочки (chains). Вот путём добавления таких правил libvirt и добавляет нашим виртуалкам доступ в Интернет, используя NAT. Мы вернёмся к iptables когда будем говорить о безопасности в целом.
Ещё для того чтобы на хосте работало перенаправление пакетов в настройках ядра должна быть включена опция ipforward. Включается она просто: `echo 1 > /proc/sys/net/ipv4/ipforward`
tcpdump
Пожалуй, самый незаменимый инструмент для дебаггинга сетевых проблем, а, конкретнее, трафика, который проходит через нашу машину — это tcpdump. Уметь им пользоваться обязательно. Посмотрим, например, что происходит на нашем virbr0 при перезапуске виртуалки.
Открываем отдельное окошко и делаем virsh reboot # <номер_виртуалки>.
Смотрим результат в первом окошке и видимо откуда какие запросы пришли:
Ну и заодно глянем ARP табличку:
Иногда (на самом деле, очень часто) необходимо сделать так, как будто и клиент и сервер находятся в одной частной сети. Например, когда все сервисы компании находятся в закрытой сети, доступной только в офисе, и нужно дать сотрудникам удалённый доступ. Или когда у компании несколько офисов или дата центров, которые нужно соединить друг с другом так, чтобы по-прежнему не открывать всю сеть всему интернету.
По сути VPN — это вложение одного tcp/ip пакета в другой и шифрование содержимого. Получается виртуальная сеть работающая внутри реальной сети. Для виртуальных сетей создаются виртуальные сетевые устройства (tun/tap) с виртуальными же IP адресами, видимыми только внутри нашей виртуальной зашифрованной сети.
Я оставлю настройку VPN за пределами этой статьи. На совести читателя останется попробовать это сделать самостоятельно при помощи OpenVPN или strongSwan.
Мы ещё вернёмся к тебе безопасности, но ты уже можешь почитать про IPsec — этот протокол использует strongSwan.
Для самостоятельного изучения
Мы только что пробежались по самым основам сетей, но, конечно же, есть ещё с десяток технологий, которые стоит посмотреть. Погугли самостоятельно VXLAN, изучи TCP и UDP (и разберись когда какой использовать), глянь что такое ICMP. Ты постоянно будешь сталкиваться с новыми терминами, но, как и всегда, главное — усвоить основы.
Мы не поднялись до более высоких уровней модели OSI, не посмотрели различные протоколы, с которыми работают веб-приложения: HTTP(S), FTP, SSH, NTP и многие другие.
Не забывай заглядывать в RFC. Это первая остановка в поиске нужной тебе информации по сетям.
Мы, скорее всего, вернёмся к этим темам в последующих статьях. Для меня лично сложнее всего было раньше понять именно то, как всё работает на уровнях ниже уровня приложения: все эти сети, подсети, непонятные проблемы с доступом от одного сервера к другому и т.п.
Надеюсь, ты теперь чуть больше знаешь о самых основных компонентах, задействованных в сетевой коммуникации и в будущем сможешь быстрее разбираться во возникающих проблемах — так как заранее будешь знать, где и что может пойти не так.
Что дальше?
Я знаю, что дорогой читатель ждёт-недождётся, когда я начну рассказывать про Chef, Puppet, Ansible и прочие модные штуки. Но рано, пока ещё рано. Нас ждёт ещё как минимум одна статья подобного рода, в которой мы рассмотрим все возможные способы аутенфицировать и авторизовывать пользователей и сервера, тем самым сильно копнув в сторону темы безопасности в целом.
Дополнительное чтение
Как я уже говорил, тема сетей сложная, глубокая и задействует множество различных частей. Ты наверняка чувствуешь лёгкую кашу в голове. Ничего страшного! Ссылки ниже помогут тебе ещё глубже усвоить всё, что тебе нужно знать о сетях.
Мы рассказываем, как стать более лучшим разработчиком, как поддерживать и эффективно применять свои навыки. Информация о вакансиях и акциях эксклюзивно для более чем 8000 подписчиков. Присоединяйся!
Сетевые сервисы DNS и DHCP
Сетевые сервисы относятся к ядру вашей сети, той основе, на которой все строится. По убеждениям автора это достаточно простые, однако, от этого не менее важные сервисы.
DNS – сервис, разрешающий доменные имена в IP адреса. Например, при обращении к ресурсам Интернет в поле URL мы вбиваем читабельное имя google.com, а работа с ресурсом осуществляется с помощью IP. Перед тем, как обратиться к ресурсу компьютер-клиент обращается к DNS серверу, запрашивая IP адрес для определенного имени. Если в базе DNS сервера такое имя есть, он возвращает клиенту искомый IP адрес. Если имя не найдено, в большинстве случаев DNS сервер обратится к вышестоящему DNS серверу. И так до самой верхушки: 13 корневых DNS серверов, которые обеспечивают работу корневой зоны DNS в сети Интернет. Получение ответа происходит по цепочке в обратном направлении.
Службы DNS и DHCP могут быть установлены на различных серверах и сетевых устройствах. Начиная от домашних роутеров, и заканчивая отдельными серверами, специально выделенными под эти задачи. При планировании сети важно правильно выбрать месторасположение и количество серверов, обеспечивающих надежную работу этих сервисов.
Например, для отказоустойчивости DHCP можно настроить несколько серверов, а для DNS помимо избыточности устанавливают внутренние и внешние DNS-сервера.
Настройка DNS и DHCP серверов может быть выполнена как ОС Windows так и Linux. В зависимости от выбранной платформы могут быть различные преимущества и особенности настройки. Например, в Windows 2012 появилась возможность поднять службу DHCP в отказоустойчивом режиме и использовать безопасные подключения для DNS. Для того, чтобы установить сетевые службы DNS и DHCP на серверах Windows необходимо поднять соответствующие роли. Дальнейшая настройка зависит от параметров вашей сети.
Работа ActiveDirectory тесно связана с сервисом DNS. Установить службы DNS можно в процессе поднятия роли ADDS, таким образом, установка DNS сервера будет произведена на контроллере домена. DHCP, кстати также имеет интеграцию с доменом: доменная машина не получит IP от DHCP сервера, если он не активирован в AD.
Для установки DNS и DHCP сервера требуется, чтобы сам сервер имел статический IP. Также на момент установки серверов крайне рекомендуется уже иметь разработанный план подсетей, областей и исключений. Также не стоит забывать о правильной конфигурации сетевого оборудования. Например, получение ip адреса от DHCP сервера будет работать в рамках одного широковещательного домена. Если вы используйте оборудование Cisco и несколько vLan, для каждого из них нужно прописать ip-helper с указание ip адреса DHCP сервера. В случае использования другого сетевого оборудования нужно найти механизмы для настройки этого функционала. После установки роли, подключиться к службам для дальнейшего управления можно с помощью консоли, которая находится в меню инструментов для администрирования.
Дальнейшая настройка DHCP сервера требует конфигурирования хотя бы одной области, в рамках которой будет указан пул выдаваемых IP адресов, адреса, которые нужно исключить из выдачи, а также резервирования. Резервировать IP адрес нужно для того, чтобы этот адрес выдавался автоматически, но только одному единственному устройству. В качестве уникального идентификатора используется MAK адрес сетевого интерфейса устройства, которому требуется выдать IP. Кроме этих настроек также можно указать ряд сетевых параметров (options), которые будут получены вместе с IP адресом. Например, шлюз и DNS сервера сети, прокси-сервера для выхода в Интернет, параметры PXE для загрузки устройства по сети, а также многое другое.
Для дальнейшей настройки DNS сервера потребуется создание хотя бы одной прямой и, при необходимости, обратной зоны, указать необходимость динамических обновлений и настроить пересылку запросов. Для настройки можно использовать готовый мастер, вызвать который можно из меню консоли управления DNS.
При создании зоны нужно указать ее тип. Существует 3 типа зон:
После того как зона создана. Ее нужно наполнить требуемыми записями.
Наиболее используемые из них
Есть еще другие, такие как SOA, SRV и пр.
Нужно отметить, что другие DNS сервера обновляют информацию о вашей зоне с некоторой задержкой, соответственно, нужно помнить, что, несмотря на то, что изменения DNS зоны применяются незамедлительно, говорить об однозначном отсутствии ошибок в разрешении имен можно только через 48 часов после применения изменений.
Одной из частых задач, возникающих при установке собственного DNS сервера является перенос зоны от провайдера. Для этого необходимо:
Говоря о создании резервной копии важно понимать, что сам сервис разворачивается за несколько минут и основными данными, которые подлежат защите, является:
Методов защиты этой информации существует великое множество. Какой из способов выбрать – решать Вам.
Данный текст был призван пролить свет на необходимость и принципы работы сетевых сервисов DNS и DHCP в инфраструктуре Вашего предприятия.
Если у Вас остались вопросы, Вы всегда можете получить консультацию наших специалистов или обратиться за помощью по внедрению продуктов, [email protected]
Chi cerca — trova…
Что такое DNS- и DHCP-сервера? Нужны ли они?
· многие не знают лицензионной политики Microsoft (впрочем, это верно и для любого другого вендора),
· далеко не все в ИТ придерживаются единого подхода и стандартов,
· в силу вышесказанного все задачи решаются не «как надо», а «как получается»,
· «получается» у всех по-разному, отсюда бардак и отсутствие хоть какой-то документации по сервисам, предоставляемых в компании.
Уверен, что большинство сейчас же со мной не согласится. Ну и что из того негатива, что я привел? Ведь все работает, «бизнес» не жалуется. Да, на первый взгляд, так оно и есть. Но…
… а знает ли «бизнес», что эти сервисы могут работать лучше? Является ли предлагаемое Вами решение оптимальным? «Бизнесу» абсолютно всё равно на технические аспекты, ему важно понимать, насколько эффективно используются инвестиции в ИТ. Малый бизнес тут не исключение. Ведь ни для кого не секрет, я надеюсь, что Microsoft предлагает готовые решения (не продукты!) для малого бизнеса за вполне умеренные деньги (но есть и ряд ограничений на использование). Почему же тогда не повысить эффективность труда и в маленьких компаниях? Большие затраты на ИТ не сможет позволить себе маленькая компания, а простой в работе ИТ скажется на ней моментально.
Было много разговоров на тему внедрения Active Directory в маленьких компаниях (примерно до 15-25 компьютеров). Как оказалось, многие не знают и не понимают идеологии самой технологии. Где-то слышал, что используется в enterprise-сегменте, попробовал, ничего не ясно, не буду использовать. Я не скрываю того, да и всячески акцентирую внимание, что любая технология в неумелых руках способна принести больше вреда, нежели пользы. Ну не зря есть много официальных и авторских курсов. Поверьте, это не просто так. Не важно, сколько Вы знаете, или какой у Вас опыт, курсы помогают систематизировать информацию даже в том случае, если Вы уже всё-всё-всё знаете. Почему-то гуру в своих направлениях не стесняются посещать такие курсы. Для них новой информации там может быть менее 30%, но систематизация знаний в таком случае более важна.
Сегодня я хочу продолжить цикл статей «Сервера в малом бизнесе: просто и доступно». В этой статье мы поговорим о DNS- и DHCP-серверах. Почему? На этот вопрос вы получите ответ в конце статьи. J
Итак, для чего нужен DNS-сервер? Domain Name System (система доменных имен) – это распределенная система получения соответствия между именем компьютера и его числовым ip-адресом. Числовая адресация удобна для машинной обработки таблиц маршрутов, но совершенно не приемлема для использования ее человеком. Запомнить наборы цифр гораздо труднее, чем мнемонические осмысленные имена. Для облегчения взаимодействия сначала стали использовать таблицы соответствия числовых адресов именам машин. Эти таблицы сохранились до сих пор и могут использоваться старыми прикладными программами. Это файлы с именем hosts. Большинство интернет ресурсов известно пользователям по их доменным именам. Это справедливо как для адресов электронной почты, так и для адресов веб-сайтов. В любом адресе центральное место занимает доменное имя сервера, на котором ресурс расположен.
Соответственно можно определить основное назначение DNS-серверов:
· получение информации об IP-адресе сервера по его имени и наоборот,
· маршрутизация электронной почты,
· предоставление информации об обслуживающих серверах определенных протоколов внутри сети.
Для чего нужен DHCP-сервер? Dynamic Host Configuration Protocol (протокол динамической конфигурации хоста) – сетевой протокол, используемый для того, чтобы компьютеры в сети смогли автоматически получить правильный IP-адрес и другие параметры для работы в сети TCP/IP.
Я не хочу останавливаться на техническом описании реализации данных служб. Они, во-первых, разные у разных производителей, а, во-вторых, даже у одного производителя в зависимости от используемой версии могут быть разными реализации. Давайте обсудим целесообразность и те выгоды, что получает в данном случае системный администратор.
Правильное планирование и настройка данных серверов могут сберечь много времени для администратора. Ведь конечному пользователю (директору, бухгалтеру, менеджеру) абсолютно всё равно как у него настроен компьютер для сетевого взаимодействия – автоматически или в ручном режиме. Но если администратор ценит свое время и свой труд, то он один раз потратит время на изучение принципов работы с данными службами, а в будущем просто будет отслеживать их корректную работу. Согласитесь, предотвращать инциденты гораздо эффективнее, чем постоянно решать возникающие проблемы. Да, никто не оценит этот труд. Это та работа, которая остается «за кадром». Но рано или поздно Вы оцените, что не зря потратили время на внедрение этого функционала.
В продолжение тематики первой статьи об Active Directory хочу отметить, что DNS является необходимым компонентом работы служб Active Directory (как было отмечено, DNS используется для предоставления информации об обслуживающих серверах определенных протоколов).
Настройка DNS требует определенных знаний и полного понимания вносимых настроек. Экспериментам не место на DNS-серверах внутри компании. Иначе одно неправильное действие и сеть компании превращается просто в набор проводов и джеков. Ни один сервис не будет работать. Приведу простой пример. В Украине довольно популярен провайдер Ого! со своим ADSL подключением по телефонной паре. Я уже неоднократно слышал такие «вредные» советы от их службы поддержки. Они предлагают в настройках сетевого подключения на конечном устройстве указать их (то есть провайдера) адреса DNS-серверов. На доступе в интернет это не скажется никак. Но ваши внутренние ресурсы перестанут быть видимыми для компьютеров сети. Опять-таки в случае использования Active Directory это просто недопустимо по понятным причинам. Такой вариант имеет на существование только при подключении одного конечного устройства к интернет. Даже в домашних условиях он сейчас не особо применим. Поясняю почему… Зачастую дома ставится небольшой маршрутизатор, зачастую он же является и точкой доступа для WiFi устройств. Соответственно, если я хочу организовать обмен данными между «домашними» устройствами, то мне необходимо пользоваться встроенным в маршрутизатор DNS-сервером.
Многие старожилы ИТ любят всё и вся настраивать исключительно в ручном режиме. Это касается и простых сетевых настроек — указать IP-адрес, маску подсети, адрес шлюза и DNS-сервера. Но и этот процесс можно автоматизировать. Согласитесь, всё больше и больше устройств для подключения в интернет, что нас окружают, в своем функционале имеют DHCP-сервер. Отключать его и настраивать всё в ручном режиме конечно же можно, но зачем? Гораздо удобнее, чтобы конечные устройства получали все вышеуказанные настройки автоматически. Проверьте, насколько это удобно вручную на рабочем месте выставлять все рабочие параметры, а приходя домой с тем же ноутбуком всё настраивать заново, но уже для домашней сети. Не проще ли все настройки получать автоматом в зависимости от того, к какой сети подключается ноутбук?
Для решения такой вот задачи существует ряд программных продуктов. Настраиваются несколько профилей, в которых указываются вручную необходимые настройки, а затем происходит простое переключение между профилями по желанию пользователя. Но и у такого сценария есть один недостаток – хоть один раз, но вы должны все настройки ввести сами.
Рассматривая целесообразность внедрения DHCP-сервера оцените главную его пользу – Вы избавляетесь от конфликтных ситуаций, которые могут появиться при установке параметров вручную. Один раз спроектировали, один раз настроили и всё работает как надо. Сервер точно «помнит», кому, какие IP-адреса выдавал и на какой период.
Учитывая, что протоколы далеко не новые, всё равно следите за изменениями, которые происходят в управлении этими серверами. Например, почитать о новом функционале DHCP-сервера, который входит в состав только Windows Server 2008 R2, можно в статье Дмитрия Пономарева.
И напоследок, помните, что DNS – это распределенная система. Не экономьте на втором сервере, просто посчитайте, во сколько может обойтись простой при отказе DNS (откажет DNS – откажут все сервисы в сети). Ну а единожды правильно настроенный DHCP-сервер позволит Вам забыть о конфигурировании рабочих станций для работы в сети компании раз и навсегда.
А теперь перейдем к главному. Сегодня рассмотрели именно эти сервера, потому как они будут очень нужны при развертывании Active Directory с нуля. Без DNS-сервера сама AD не будет работать (более детально в статье Дениса Баканова). А вот без DHCP-сервера вполне может обойтись, но зачем придумывать себе лишнюю работу.
Как настроить Active Directory, DNS и DHCP сервера для малого бизнеса смотрите в следующем веб-касте.
