настройка dhcp для разных vlan windows server

Настройка DHCP на одном сервере для 7 VLAN

Cisco Packet Tracer настройка роли DHCP на отдельном сервере в ЛВС с VLAN
Доброго утра, товарищи! Прошу оказать содействие в решение вопроса по настройке DHCP на отдельном.

Сложная настройка коммутатора DHCP-Relay для разных vlan
Добрый день, подскажите с настройкой коммутатора, схема такая. Есть комутатор Циско 2960 на нем 2.

VLAN на базе двух коммутаторов, настройка DHCP (Cisco Packet Tracer)
Добрый день. Нужна помощь по настройке, а точнее найти ошибку в настройке. Мною выполняется.

Настройка DHCP на сервере Win 2003.
Есть сеть из 25 машин( Win xp ) и 2 сервака ( Win 2000) и (Win 2003). На серваке с 2003 нужно.

Да, на Win сервере ничего кроме добавления Scope делать не нужно.

Добавлено через 3 минуты
+ здесь показано, как добавлять Области (Scope):

и первым делом сказано:

Под фразой «layer-3 switch» у меня «межсетевой экран-роутер» Dfl-860e, это как бы логично что сначала делаем вланы а потом уже к ним dhcp сервер) на цисках я помню это ip helper address а в терминологии сетей это dhcp relay

Добавлено через 19 минут
Еще вопрос, настраивая вланы на роутере, я не потеряю доступ к самому роутеру? и по какому адресу к нему подключаться для конфига потом?

Чтобы «не потерять доступ к самому роутеру» и всё работало, как надо:

Источник

Windows Server DHCP VLAN Configuration: Detailed Guide

Network segmentation is a great way to compartmentalize the various networks you need to run in your environment. This provides many benefits from both a management and security perspective. When segmenting your networks, one of the things that you have to consider and take care of is IP addressing. Dynamic Host Configuration Protocol (DHCP) is an age-old standard that has been used in the enterprise for handing out IP addresses to clients on the network. DHCP requires its own broadcast domain, which in turn requires VLANs. Many organizations are using Windows Server for DHCP on their networks. In this post, we will take a look at Windows Server DHCP VLAN configuration. These steps work for Windows Server 2012, 2016, 2019, and Windows Server 2022.wind

Why are VLANs needed for DHCP?

When a client is provisioned on a network segment and is set up to have IP addressing configured automatically using DHCP, the client makes broadcast queries on the network segment to notify the DHCP server configured that it needs an IP address. The DHCP server responds with the appropriate IP address for the network segment and the additional configuration for network connectivity on the segment.

VLANs (Virtual Local Area Networks) allow taking a physical network switch and logically segmenting the physical network environment into multiple network segments. This makes much more efficient use of network hardware since additional segments do not require additional physical network switches. By introducing VLANs, you can provision multiple network segments on the same switch.

When you spin up a new network segment IP address range, you want to pair this with a new VLAN or logical network segment. VLANs control broadcast ranges. Within each VLAN, clients can initiate the broadcast for a network IP address from a DHCP server. There are many different ways to have a Windows Server participate in a VLAN network segment. Before we look at the specifics related to DHCP VLAN configuration, let’s take a look at the multiple options for connecting the Windows host into a VLAN-backed network.

Connecting Windows Server to Multiple VLANs

There are many different ways to connect Windows Server to multiple VLANs. This includes the following:

Additional network interfaces Untagged for VLAN traffic

With VLANs, you hear two different terms tossed out there related to the VLAN you are working with – untagged, and tagged. When you talk about untagged frames, this means the Windows host is not tagging the Ethernet frames originating from the host with VLAN information. Instead, it is relying on the upstream switch it is plumbed into to handle that configuration.

So, essentially, the Windows Server is unaware of the VLAN and doesn’t care. It simply relies on its physical uplink to do any VLAN tagging for it to communicate appropriately. However, this means that if you want to have a Windows Server to be a part of multiple VLANs, it means you need a physical uplink for each separate VLAN, since it is relying on the switch to tag the traffic appropriately for a specific VLAN.

As shown below on a Windows Server 2019 server, you can specify the Bindings for the Windows DHCP Server so that it knows which interfaces to “listen” for DHCP on.

A single network interface with Tagged VLAN frames

While there may be reasons that you use multiple physical uplinks with untagged frames for communicating with different VLANs, a more efficient approach is to use Tagged VLAN frames on a single network connection. When you use tagged frames, the Windows Server tags the frames appropriately for each VLAN it is associated with. The ability to Tag frames generally needs vendor-specific driver sets to be loaded, such as the Intel Pro Set drivers using Intel-based cards.

Routed Layer 3 connectivity to VLAN-backed subnets

The third option is simply relying on routing to take care of connectivity to the VLAN-backed subnets they need to communicate with. This technically does not connect the Windows Server into the VLAN as that would mean it would have the ability to be in the broadcast domain which is a Layer 2 VLAN construct. Instead, you are relying on Layer 3 connectivity to IP addresses. For many type of communication, including Windows Server 2012 DHCP VLAN configuration, this is all that is needed.

Windows Server DHCP VLAN Configuration

You can use all three of the methods above for Windows Server 2012, 2016, 2019, and Windows Server 2022 DHCP VLAN configuration. You can add multiple network adapters to each VLAN and have each scope listen on that specific network interface for DHCP requests. You can also use the tagging method listed above that allows adding multiple VLANs to a single network interface which allows keeping a single network adapter and connecting that physical network uplink to multiple VLANs.

You might assume the third option, since it is not connecting the uplink to the physical broadcast domain, would not be able to answer the broadcast DHCP request from the client on a specific VLAN. However, even though the DHCP server is not on the same broadcast domain/VLAN, there are really only two pieces of information the DHCP servers need to know to allocate an IP address on a particular subnet. This includes:

You will note that the Windows Server DHCP server being a part of the VLAN is not a requirement for a successful DHCP request being made to the Windows Server. The third option is typically the option that I steer towards unless there are requirements for multiple physical uplinks for compliance or other security-based reasons. So, how does the Windows DHCP Server respond to a DHCP broadcast request if it is not on the same VLAN to take part in the broadcast traffic?

IP Helper Address, DHCP Relay, DHCP Proxy Address

This is made possible by the IP Helper Address which is sometimes referred to as DHCP Relay, or DHCP proxy address. Using an IP helper address, DHCP Relay, or DHCP proxy address allows the special DHCP broadcast messages to be forwarded from VLAN they originated from and forwarded to the DHCP server. This role is typically handled by a firewall or router device that is able to take the DHCP broadcast message and forward these to the DHCP server.

How does this work? When the DHCP client issues the DHCP broadcast request packet, is as of yet has no IP address configured. This being the case, it uses a broadcast with an all zero source address – 0.0.0.0. It also has no way to get to the DHCP Server with the lack of IP configuration. With this being the case, the client uses a general broadcast address of 255.255.255.255 as the destination with the DHCP request packet.

The device handling the DHCP proxy functionality receives the DHCP request packet from the client, replaces the destination address of 255.255.255.255 with the configured address of the server that was configured in the IP helper-address configuration. The client’s MAC address is included in the DHCP request so the receiving DHCP server knows the required MAC address of the client. This information is then forwarded to the DHCP server from the router, firewall, or another device in the role of the DHCP proxy.

The DHCP server issues an address now that it knows the subnet the client resides on along with the MAC address. It sends the DHCP response back to the DHCP Proxy device. The DHCP Proxy device then forwards the response to the correct MAC address of the requesting client and it is able to be configured with the IP address allowing network communication on the subnet.

The configuration of DHCP Relay is generally simple but can vary depending on the vendor of router, firewall, or other device you might be using to perform this function. Below is the configuration of DHCP Relay on a Palo Alto firewall. You simply have to select the Interface and the DHCP Server IP Address you want to use for the target of DHCP requests.

Windows Server DHCP VLAN configuration for Virtual Machine DHCP servers

The principles still apply to Windows Server DHCP servers running inside a Windows Server virtual machine. The one method that is more difficult is the tagging of a single interface with multiple VLANs as this is not a feature that you can carry out with VMware Tools drivers that I am aware of. You can add multiple virtual NICs to a single VM and connect the virtual machine to different VLAN-backed port groups for each connection.

This will essentially place the Windows Server virtual machine on the same network segments as the clients that need addresses. Or, you can use the preferred method of using an IP Helper Address to forward the DHCP requests from all the other VLAN-backed subnets to the DHCP server and have the addresses issued by the server using only the single network connection.

Creating a Windows Server DHCP scope for a different VLAN

As detailed by the explanation above, the actual work of the Windows Server DHCP VLAN configuration takes place with the IP Helper Address/DHCP proxy device. Creating a Windows Server DHCP scope for a different VLAN is the same as creating a scope for the native VLAN network where the DHCP Server itself is located. Non-intuitively, you won’t see any part of the scope creation wizard that has you define the VLAN configuration. However, this is not needed in any of the configurations mentioned. With IP Helper Address, the packets are forwarded by the DHCP proxy to the DHCP server. If you are using different interfaces or tagged interfaces, the DHCP server will receive the DHCP broadcasts as normal.

Set the name and description (optional) of the new DHCP scope.

Specify the new DHCP address range.

Set the exclusion range for the DHCP scope.

Specify the lease duration.

Configure the DHCP options for the new DHCP scope.

Define the default gateway of the new Windows Server DHCP VLAN configuration.

Configure domain name and DNS servers.

Setup any WINS server addresses.

Activate the new DHCP scope.

Complete the new DHCP scope wizard.

Below is an example of how my DHCP server looks after creating two different scopes for address leasing.

Wrapping Up

Hopefully, this Windows Server DHCP VLAN Configuration: Detailed Guide will help any who may be trying to wrap their heads around the configuration of DHCP services for different VLANs and network segments in their network. By understanding the different means you have available to hand out IP addresses from a Windows DHCP Server you can effectively segment your network and easily handle IP addressing for all clients in the network, regardless of the VLAN they reside on.

Источник

DHCP сервер на нескольких VLAN

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

Требуется обеспечить доступ для нескольких сотен клиентов к неким общим ресурсам в таком режиме, чтобы:

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

Технически описанное выше решение можно реализовать только аппаратными средствами на коммутаторах уровня L3 или программно-аппаратными средствами на коммутаторах уровня L2 (лишь бы они понимали 802.1q) и каком-либо компьютере с linux-подобной операционной системой. Так как у меня уже был сервер (являющийся, к тому же, целевым для клиентов), то логично было бы остановиться на аппаратно-программном варианте.

Итак, программируем коммутатор таким образом, чтобы на каждом клиентском VLAN был один физический порт коммутатора в “access mode”, и один общий порт в режиме 802.1q (к этому порту будет подключаться наш сервер). Подробно технология настройки не расписывается, т.к. она достаточно тривиальна и зависит от конкретной модели используемого коммутатора.

Далее приступаем к созданию конфигурации для сервера. Пусть физический интерфейс, который подключается к порту 802.1q коммутатора, имеет имя eth0. Для моей конкретной задачи понадобилось 200 клиентских VLAN с VLAN ID от 600 до 799 включительно, так что будем их создавать:

Общая настройка видов имен VLAN-интерфейсов. Я хочу, чтобы имена VLAN-интерфейсов имели вид “vlanXXX”, где XXX — VLAN ID:

Непосредственно создаем VLAN на базе интерфейса eth0:

Создаем бридж, в который будем объединять созданные vlan:

Объединяем созданные интерфейсы в бридж:

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

И запрещаем трафик между клиентскими VLAN средствами ebtables:

(в данном случае используется таблица ebtables ‘filter’, запрещающая передачу трафика между интерфейсами, входящими в бридж в виде логических портов). Если все-таки необходимо разрешить возможность передачи трафика между клиентами под нашим контролем (см. п. 3 техзадания), то вместо вышеприведенного правила устанавливаем следующие:

Здесь мы работаем с таблицей ‘broute’. В ней не стандартные действия для целей ACCEPT и DROP. Цель ACCEPT разрешает форвардинг трафика с заданными условиями (т.е. трафик передается на уровне L2), а цель DROP запрещает форвардинг трафика и обеспечивает его передачу на роутинг (и, соответственно, мы сможем им управлять посредством iptables). Однако т.к. все адреса принадлежат одной IP-подсети но могут находиться в разных клиентских VLAN, на интерфейсе br1 необходимо будет разрешить arp proxy:

Замечу, что у меня не не стояло задачи пропуска трафика между клиентами, поэтому описанное выше расширение чисто умозрительное и на практике не проверялось!

Осталось только настроить сервер DHCP и поселить его на интерфейс br1. Эта операция также тривиальна, поэтому в рамках данной статьи не описывается.

Ну что, все работает? А вот как бы не так:

Здесь все нормально: получили один broadcast запрос DHCPDISCOVER, ответили одним broadcast-ответом DHCPOFFER.

А теперь давайте посмотрим, что происходит на физическом интерфейсе:

Мало того, что мы засветили всем клиентам MAC/IP адреса одного из них, так еще и вдобавок получили не хилый broadcast storm на физический коммутатор. Кстати, от такого шторма у некоторых коммутаторов просто едет крыша: работающий у нас QTECH не только не смог пропустить broadcast на все заявленные 200 клиентских VLAN (т.е. конечный клиент с произвольной вероятностью либо получал свой адрес от DHCP сервера, либо не дожидался от него вообще никакого ответа), но и даже забыл таблицу известных ему MAC-адресов (во всяком случае в консоли он показывал только один MAC-адрес для всех портов). А вот коммутатор ASOTEL справлялся с такой нагрузкой и клиенты могли получить адреса от нашего DHCP-сервера.

Ну ладно, будем исправлять ситуацию. Надо заставить сервер посылать broadcast только в тот VLAN, от которого пришел первоначальный запрос, а не размножать его по всем доступным местам.
Модуля трекинга DHCP broadcast-ов я не нашел. Как выяснилось позднее, он бы в данном случае все равно не помог, т.к. broadcast-ответ DHCP-сервером формируется при помощи системного вызова
socket(PF_PACKET, SOCK_DGRAM, htons(ETH_P_IP))
который не проходит ни через одну из таблиц ebtables или iptables. Т.е. если входящие broadcast отловить еще можно, то вот ответы передаются драйверу минуя стек протоколов. И это логично: если уж мы сами формируем ethernet-заголовок, то какой смысл дополнительно обрабатывать его средствами ядра?

Для начала вспомним, что в современных linux-ядрах есть такие вкусности, как Virtual Ethernet Device (из них можно делать хорошие pipes для перегонки ethernet-трафика внутри нашего компьютера) и Network Namespace (средство для изоляции сетевого стека. В аппаратных маршрутизаторах это, обычно, называется VRF). В принципе для данной задачи можно обойтись исключительно Virtual Ethernet (veth), но для красоты решения (и упрощения связки DHCP Server — DHCP Relay Agent) будем использовать также и Network Namespace (netns).

После инициализации сети в linux по умолчанию имеется только один root netns, в котором находится единственная копия сетевого стека, таблицы маршрутизации, интерфейсы и т.п. В дальнейшем описании для определенности будем использовать следующую терминологию:
Network Namespace назовем “слоем” (layer);
root netns назовем слоем “backplate” (хотя в реальности этот netns имеет имя в виде пустой строки);

каждый клиентский VLAN добавляем в отдельный bridge, на интерфейс которого будем вешать DHCP Relay Agent. Через этот интерфейс клиенты смогут посылать broadcast-запросы агенту и принимать от него broadcast-ответы.
из каждого клиентского bridge сделаем ethernet pipe до нашего основного br1. Через связку “customer vlan”-”customer vlan bridge”-”virtual ethernet”-”br1” будет проходить полезный трафик между клиентским сервисом и общими внешними ресурсами.

Сам DHCP Relay Agent живет в одном экземпляре (он может слушать несколько клиентских интерфейсов) на специальном ethernet pipe, на другой стороне которого находится наш DHCP Server.
весь прикладной уровень (т.е. все, что не касается DHCP), расположим на уровне backplate;
все, что связано с DHCP Relay Agent, расположим на уровне с именем “relay”;
собственно сервер DHCP должен быть доступен как для DHCP Relay Agent (для обработки сообщений, распространяемых в виде broadcast и преобразуемых агентом в unicast и обратно), а также непосредственно для клиентов DHCP (для обработки специального случая: сообщения DHCPRELEASE, отправляемого unicast клиентом напрямую тому DHCP-серверу, который выдавал этот адрес).

С учетом данных требований сам DHCP-сервер расположим на уровне backplate на интерфейсе br1, но для предотвращения приема им broadcast-запросов от конечных клиентом на интерфейс будут наложены специальные фильтры.

Ну, поехали… Создаем слой “relay”

Создаем на слое backplate виртуальный pipe, предназначенный для общения DHCP Relay Agent и DHCP Server:

Переносим хвост dhcpd (интерфейс, на котором будет работать Relay Agent) в слой relay:

Настраиваем в слое relay интерфейс dhcpd:

Создаем наш основной бридж br1:

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

Ну и клиенты — личности своеобразные, вполне могут и кольца сотворить. Ежели кто этим и займется, то пусть страдает сам, не затрагивая при этом других. Т.е. запустим на нашем виртуальном коммутаторе STP:

Т.к. этот бридж является также шлюзом по умолчанию для клиентов, то повесим на него IP-адрес (вместе с сеткой) и поднимем непосредственно сам интерфейс:

Добавляем в бридж интерфейс, по которому DHCP сервер будет общаться с агентом:

Запрещаем трафик между клиентскими VLAN средствами ebtables:

Запрещаем обработку DHCP-сервером broadcast-запросов (они должны вылавливаться агентом и отсылаться серверу в виде unicast):

Для подстраховки разрешаем использование адреса, выделенного для DHCP Relay Agent только на интерфейсе с именем relay:

Ладно, последний мазок. Так как я категорически не доверяю клиентам, заставим ядро убеждаться в том, что приходящие от них IP-пакеты имеют source address вида 10.12.8.0/23 (а не, к примеру, 192.168.1.1). Для этого включаем на интерфейсе rp filter:

Общая настройка видов имен VLAN-интерфейсов. Я хочу, чтобы имена VLAN-интерфейсов имели вид “vlanXXX”, где XXX — VLAN ID:

Непосредственно создаем VLAN на базе интерфейса eth0:

Переносим созданный интерфейс vlan600 из слоя backplate в слой relay:

Поднимаем интерфейс vlan600, но уже в слое relay:

Создаем в слое relay бридж для данного клиентского VLAN (на который будем вешать DHCP Relay Agent).

Мы хотим, чтобы этот бридж работал в качестве хаба (т.е. выполнял бы трансляцию пакета сразу же после его получения, не используя период сбора информации о MAC-адресах). Для этого до момента добавления первого интерфейса в бридж устанавливаем его параметры:

Кроме того, STP на данном бридже нам явно не нужен:

Поднимаем интерфейс бриджа:

И добавляем в него клиентский VLAN:

Создаем на слое backplate (ну все равно он туда придет) ethernet pipe для связки клиентского бриджа br600 и нашего основного бриджа br1:

Переносим второй конец pipe в слой relay:

И добавляем этот конец трубы в бридж:

Ну и добавляем конец pipe, оставшийся в слое backplate, в бридж br1:

Повторяем в цикле операции создания клиентских VLAN в нужном количестве.

Теперь достаточно запустить сам DHCP сервер в слое backplate и DHCP Relay Agent в слое relay. В моем случае используется сборка из BusyBox, что в данном случае не критично. Использование ISC агента и сервера не должно вызвать больших затруднений.

Итак, запускаем агента. В качестве клиентских интерфейсов используются br600-br799, в качестве интерфейса для связи с DHCP-сервером используется интерфейс dhcpd, а сам DHCP сервер имеет адрес 10.12.8.1:

Ну и, наконец, запускаем DHCP сервер:

В файле /etc/udhcpd.conf единственная строчка, которая относится к данной схеме:

Все, теперь broadcast-запросы в пользовательском VLAN отлавливаются DHCP Relay Agent через соответствующий br-интерфейс, после чего запрос unicast-ом передается на серверу через интерфейс dhcpd. Сервер отсылает unicast-ответ через интерфейс relay, который агент получает из интерфейса dhcpd и транслирует broadcast-ом в исходный VLAN.

Клиенты стали получать адреса через DHCP, broadcast-storm исчез. И клиент может послать DHCPRELEASE непосредственно серверу на адрес 10.12.8.1

© Copiright 2015 by Vedga. Копирование текста на другие ресурсы без согласия автора запрещено.

Что посмотреть к этой статье:

Источник

Настройка dhcp для разных vlan windows server

Вопрос

Все ответы

» В качестве шлюза по умолчанию следует указать IP-адрес интефейса L3 коммутатора для соответствующего VLAN» Плюс данная тема до конца не раскрыта

я не совсем понимаю эту фразу, шлюз задается на DHCP сервере? если так, та как быть при существующих даже 2-х вланах и едином сетевом интерфейсе в сервере?

Я не волшебник, я только учусь MCP, CCNA. Если Вам помог чей-либо ответ, пожалуйста, не забывайте нажать на кнопку «Пометить как ответ» или проголосовать за полезное сообщение. Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции работодателя. Вся информация предоставляется как есть без каких-либо гарантий. Блог IT Инженера, Twitter, YouTube, GitHub, Instagram

Вы не внимательно прочитали мой вопрос. У меня не отрабатывает виндовый DHCP, не могу найти ни одной толковой статьи по этому поводу

по вашей ссылке ни слова по поводу DHCP на базе W2012

с настройкой DHCP Relay на D-Link вроде как нет проблем

есть D-Link DGS-3120-24TC (L3) и D-Link DGS-3000-52X

А в качестве роутера у Вас кто?

У меня не отрабатывает виндовый DHCP

Там нечему отрабатывать. На DHCP просто создаются области для каждой сети:

Так что, Вам нужно обратиться на форумы D-link.

» В качестве шлюза по умолчанию следует указать IP-адрес интефейса L3 коммутатора для соответствующего VLAN» Плюс данная тема до конца не раскрыта

я не совсем понимаю эту фразу, шлюз задается на DHCP сервере? если так, та как быть при существующих даже 2-х вланах и едином сетевом интерфейсе в сервере?

Я не волшебник, я только учусь MCP, CCNA. Если Вам помог чей-либо ответ, пожалуйста, не забывайте нажать на кнопку «Пометить как ответ» или проголосовать за полезное сообщение. Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции работодателя. Вся информация предоставляется как есть без каких-либо гарантий. Блог IT Инженера, Twitter, YouTube, GitHub, Instagram

Источник