Dhcp сервер с подсетями

Dhcp сервер с подсетями

Настройка cisco dhcp в локальной сети

Настройка cisco dhcp в локальной сети

Всем привет ранее мы закончили настраивать сеть для филиалов, и разобрались со статической маршрутизацией, но все это время настраивали компьютерам ip адреса в ручную. Для решения это задачи есть служба DHCP. Можно конечно использовать Windows DHCP, при наличии лицензии на Windows Server, но Cisco тоже умеет это делать на ура. Настроим давайте DHCP службу на Cisco, рассмотрим несколько вариантов.

Принцип работы DHCP

Как работает dhcp сервер, ответ на этот вопрос очень простой. Когда компьютер появляется в локальной сети, первым делом он отсылает в сеть широковещательный запрос, по всем кто в сети. Данный пакет называется DHCPDISCOVER, в котором он спрашивает ребята есть у вас тут DHCP, если да то дай как мне ip адрес. Если HDCP сервер в локальной сети есть, то он отвечает ему пакетом DHCPOFFER, в котором говорит вот я есть, вот тебе ip адрес, будешь брать? Компьютер получив пакет DHCPOFFER, отсылаем ему ответ в виде пакета DHCPREQUEST в котором говорит, отлично я беру это ip адрес запиши его за мной, на что DHCP получив этот пакет, отвечает пакетом DHCPACK в котором говорит что записал, что это ip адрес теперь твой. Вот весь принцип.

В своей практике я встречал еще вот такие пакеты от dhcp сервера:

  • DHCPDECLINE — это пакет в котором клиент определил, что ip адрес, от DHCP сервера в момент предложения, уже используется кем то, и тогда будет сгенерирован новый запрос на другой ip адрес
  • DHCPRELEASE — данный пакет появляется когда клиент освобождает IP адрес
  • DHCPRENEW — Это пакет содержит в себе запрос на обновление и продление аренды ip адреса
  • DHCPINFORM — пакет, направленный клиентом к серверу DHCP, чтобы получить от него детальную информацию, пример, где находится запасной DHCP сервер в сети

Настройка dhcp cisco

Настройка для маленького офиса

У нас есть филиал, 3 компьютера, один коммутатор второго уровня Cisco 2960 и роутер Cisco 1841. Все компьютеры находятся в нативном vlan (vlan по умолчанию). Вот схема сети.

Приступаем к настройке Cisco 1841. Поднимем у него порт fa0/0 и назначим ему ip 192.168.1.1/24

Видим, что порт загорелся зеленым.

Далее создаем pool ip адресов на cisco dhcp server, для этого вводим команду: DHCP_192.168.1.0 это имя

Посмотрим теперь доступные команды

Router(dhcp-config)#?
default-router Default routers
dns-server Set name server
exit Exit from DHCP pool configuration mode
network Network number and mask
no Negate a command or set its defaults
option Raw DHCP options

Задаем в начале сеть которую будем раздавать, естественно она должна быть в том же диапазоне что и ip адрес устройства Cisco. Создаю сеть 192.168.1.0

Теперь давайте исключим из созданного пула первые 50 ip адресов, которые отдадим для серверов и про запас.

Проверка получения ip адреса

Берем первый компьютер, вводи на нем команду ipconfig чтобы посмотреть текущие настройки. Как видим, ip адрес не назначен. Так как это у меня симулятор Cisco packet tracer 6.2, то у него по умолчанию стоит статический ip в настройках, поставлю получение автоматически с DHCP.

Делаем снова ipconfig и видим, что получили ip адрес 192.168.1.51

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

В малом офисе мы настроили dhcp сервер cisco.

Настройка DHCP для среднего офиса

С маленьким офисом мы разобрались, теперь рассмотрим схему среднего офиса. У нас тут уже есть сигментирование в виде vlan (2,3,4). У нас в схеме есть роутер Cisco 2911, на котором будет маршрутизация локального трафика между vlan, коммутатор второго уровня Cisco 2960 на уровне доступа конечных устройств, сервер DHCP в vlan 4, с которого мы и будем получать ip адреса.

Настроим Cisco 2960

Первым делом на коммутаторе нужно создать vlan 2,3,4 и зададим им имена.

Теперь настроим порты коммутатора и добавим их в нужный vlan.

int range fa0/1-2
switchport mode access
switchport access vlan 2
exit

VLAN3 у меня порты fa0/3 и fa0/4

int range fa0/3-4
witchport mode access
switchport access vlan 3
exit

VLAN4 у меня порт fa0/5

int fa 0/5
switchport mode access
switchport access vlan 4
exit

Теперь настроим порт gi0/1 который подключается к роутеру Cisco 2911, и режим работы у него будет trunk. разрешим через trunk все 4 vlan.

Настроим Cisco 2911

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

первым делом мы поднимаем порт, так как на всех роутерах Cisco они в выключенном состоянии.

Проверим теперь с компьютера где ip адрес 192.168.2.1 пропинговать шлюз и соседей по vlan 3,4. Видим, что все отлично работает, связь проверена. Осталось теперь настроить DHCP сервер.

DHCP настройка

Напомню, что службой DHCP, может быть компьютер с роль на Windows Server (тут это компьютер или виртуальная машина, где есть много сетевых интерфейсов, каждый из которых подключен к нужному vlan, в который DHCP и отдает свои ip адреса), само устройство cisco, либо сторонний продукт на базе linux, вариантов много, в своей тестовой среде у меня это будет сервер в cisco packet tracer, у него есть статический ip адрес 192.168.4.1. Я создаю новый пул для VLAN2, раздавать я буду с 192.168.2.50 до 192.168.2.250, задаю шлюз по умолчанию и dns сервер.

жмем Add и добавляем наш пул. Так же создаем пул для 3 VLAN.

Теперь вспомним, что у нас DHCP сервер в другом vlan, а это значит что широковещательные запросы DHCPDISCOVER из других vlan он не видит, решить эту проблему нам поможет dhcp relay.

dhcp relay настройка

cisco dhcp relay в двух словах это ретранслятор, который отлавливает пакеты DHCPDISCOVER и перенаправляет их DHCP серверу, за счет этого можно уменьшить количество DHCP серверов. Приступим и настроим наш dhcp relay.

Теперь у нас в каждом vlan появился ретранслятор на наш dhcp сервер. Так же в целях безопасности вы можете настроить, чтобы у вас доверенным был только определенный dhcp сервер с определенного порта, а все остальные будут игнорироваться. Возьмем за тест компьютер со статическим ip 192.168.2.1, посмотрим текущие настройки сети командой ipconfig, ставим автоматическое получение, и видим что получили 192.168.2.50. DHCP в vlan2 работает.

Полезные команды cisco dhcp

Смотрим статистику по пакетам и привязкам

Смотрим кому какой ip адрес присвоен

Вот так вот работает и настраивается DHCP и DHCP Relay в сети. Надеюсь было позновательно.

Зачем это нужно?

С понижением цен на аппаратное обеспечение размеры локальных сетей выросли. Теперь обычным явлением являются локальные сети размером от малого офиса (5-10 хостов) до больших корпоративных сетей, охватывающих целое здание (более 50 хостов).

При количестве хостов менее 10-ти управлять сетью, в общем, очень просто: все узлы принадлежат одному Ethernet-сегменту, а безопасность, если она необходима, реализована на уровне хоста: пароль и т.п. При количестве узлов более 50-ти вы уже должны получать финансирование, достаточное для установки управляемого коммутатора с поддержкой виртуальных сетей (VLAN’ов). Тогда бухгалтерия будет работать в одном «вилане», отдел сбыта — в другом и так далее. Каждый хост будет иметь доступ к хостам из своего вилана и серверам компании, но не к хостам из другого вилана. Кроме безопасности на уровне хоста появляется еще и сетевой уровень безопасности.

Читайте также:  Arp корабли world of warships

В сетях среднего размера мы часто вынуждены объединять все узлы в один сегмент. Современные дешевые коммутаторы легко справляются с обработкой трафика 50-ти узлов, но они не поддерживают функции виртуальных сетей. Коммутаторы же с такой функцией на порядок дороже. Хорошо известные брэнды продают их начиная от $1200 за 24-портовый коммутатор. Возможно, он и стоит этих денег, однако он совершенно не вписывается во многие сметы. Например, в мою.

DHCP и подсети

Одна из локальных сетей, которую я администрировал, была сетью школы, где я работал. Она представляла собой длинную цепочку неуправляемых Ethernet-коммутаторов. Такая архитектура была обусловлена планировкой здания. Мне приходилось управлять трафиком нескольких типов. Для упрощения будем говорить о «преподавательском» (группа А) и «студенческом» (группа Б) трафиках. Они не должны смешиваться. Я не хочу, что бы люди из разных групп имели доступ к принтерам и файлам другой группы (пароли были гораздо проще, чем мне бы хотелось).

Простейшим путем разделение на группы является выделение каждой группе своей сети. Например, группа А получит адреса из сети 192.168.10.0 (т.е. 192.168.10.12), тогда как группа Б — из сети 192.168.20.0 (т.е. 192.168.20.34). Сервера, доступ к которым должен быть открыт для обеих групп, должны иметь адрес в каждой из сетей.
Здесь картинка с архитектурой сети. Можно посмотреть здесь: http://gazette.l inux.ru.net/lg83/ward/misc/ward/map.jpg

Хорошим решением проблемы является сервер DHCP. Это сервис, которым вы пользуетесь при dial-up соединении с Internet: вы соединяетесь с провайдером, который назначает вам временный ( а возможно и постоянный. — Прим.пер. ) реальный IP адрес. Большинство дистрибутивов Linux, включают в себя сервер DHCP, который можно использовать и в локальной сети.

В простейшем случае, вы задаете DHCP-серверу диапазон адресов: например от 192.168.1.100 до 192.168.1.199. Любой хост, который загружается и запрашивает адрес, получит его из указанного диапазона. После отключения хоста адрес освобождается и может быть использован повторно, уже для другого хоста.

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

Пользуясь этим, мы можем создать список MAC-адресов хостов группы А, и настроить DHCP на раздачу им постоянных IP-адресов из подсети 192.168.10.0. А хостам с MAC-адресами группы Б, будут отдаваться адреса из сети 192.168.20.0, хосты не принадлежащие ни одной из групп (лаптопы визитеров, например) получат адрес в подсети 192.168.1.0 .

В этом смысле у DHCP есть преимущество над VLAN’ами: «виланы» определяются для физических портов, тогда как DHCP использует адрес карты. При использовании виланов, если вы физически меняете сетевое подключение — например при переезде из одной комнаты в другую — вы можете изменить и свой вилан. При использовании DHCP, привязка к подсети останется прежней.

Это очень неполное суждение. Вы можете привязать к порту коммутатора MAC-адрес, тогда несанкционированного попадания в другой вилан не будет. Строго говоря, разбиение на подсети (и использование разных адресов сетей) не имеет никакого отношения к безопасности, тогда как одной из функций виланов может быть обеспечение безопасности на сетевом уровне. — Прим.пер.

Настройка DHCP

В большинстве дистрибутивов сервер DHCP называется dhcpd и запускается стандартными скриптами (теми же что и сервисы httpd, postfix, …). Он может быть и в виде пакета RPM, например dhcp-3.0-3mdk.i386.rpm. Если он уже установлен в вашей системе, то просмотрите страницы руководства dhcpd и dhcpd.conf.

Сначала, чтобы настроить сервис DHCP для основной сети, я использовал утилиту webmin. Обратите внимание, что сервис должен работать в сети 192.168.0.0 с маской 255.255.0.0 . Это связано с тем, что он должен быть доступен из всех подсетей.
Скриншот настройки подсетей через Webmin. Глядите здесь: http://gazette. linux.ru.net/lg83/ward/misc/ward/main.jpg

Далее, я внес в конфигурацию каждый хост, указывая его имя, аппаратный MAC-адрес и IP-адрес, который я хотел ему выдать. IP-адреса принадлежали подсети 192.168.10.0 ( Для группы А, естественно — Прим.пер. ).
Скриншот редактирования настроек хостов. Можно взять здесь: http://gazett e.linux.ru.net/lg83/ward/misc/ward/client.jpg

Если вас интересует, где можно узнать MAC-адрес сетевой карты, то посмотрите на нее внимательно. На большинстве из них есть наклейка, где он указан. Если же на ваших картах наклейки нет, то пока пропустите этот шаг. Заканчивайте настройку DHCP-сервиса, и запускайте хосты один за другим. Поскольку каждый хост получает IP-адрес (в сети 192.168.1.0 пока что), вы увидите его в файле /var/lib/dhcp/dhcpd.leases. Например:

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

Закончите настройку фиксированных адресов в конфигурации DHCP-сервера.

Запустите или перезапустите сервер DHCP. Узлы должны будут получить назначенные им адреса ( при запросе от них. Например при загрузке — Прим.пер.) На Linux в этом можно убедится при помощи команды ifconfig. На Windows-машине используйте winipcfg для Win95/98/ME, а ipconfig (в окне команд) для WinNT/2k.

Кстати, эти же команды выведут вам и MAC-адрес сетевой карты компьютера. Для команды ipconfig нужно еще задать параметр /all: ipconfig /all — Прим.пер.

Маска сети по умолчанию, однако, устанавливается равной 255.255.0.0. Это нехорошо, т.к. хосты подсетей 192.168.10.0 и 192.168.20.0 будут видеть друг друга (попробуйте пинг). Идем в конфигурацию каждого узла и нажимаем «edit client options». Устанавливаем маску подсети 255.255.255.0 и маршрутизатор по умолчанию 192.168.X.1 для подсети 192.168.X.0 . Например, в сети 192.168.10.0.
И еще один скриншот: http://gazet te.linux.ru.net/lg83/ward/misc/ward/client1.jpg

Не забудьте также установить маску 255.255.255.0 в общей настройке клиентов сети 192.168.0.0.

Можно и вручную править файл /etc/dhcpd.conf. Это может быть даже более понятно, чем интерфейс webmin. Вот что вы могли бы указать:

Организация доступа к серверу

В предыдущем примере, для каждой подсети вида 192.168.X.0 мы указали маршрутизатор 192.168.X.1 . Но при этом наш сервер имеет IP-адрес 192.168.1.1 — и это значит, что:

  • узлы в сети 192.168.10.0 будут пытаться получить IP-адрес
  • они будут получать адрес от сервера 192.168.1.1
  • адрес будет из сети 192.168.10.0 с маской 255.255.255.0
  • и в результате узлы не смогут работать с сервером 192.168.1.1, поскольку он принадлежит другой сети.

Поэтому наш сервер должен иметь дополнительные адреса для каждой из подсетей: 192.168.10.1, 192.168.20.1, и т.д. Это можно сделать очень просто, создавая виртуальные сетевые карты ( точнее — указывая дополнительные адреса сетевой карты — Прим.пер. ) eth0:1, eth0:2, и т.д. При помощи webmin (последний скриншот): http://gazet te.linux.ru.net/lg83/ward/misc/ward/virtual.jpg

Все можно настроить и руками. Если у вас дистрибутив Mandrake или Red Hat, нужные файлы расположены в каталоге /etc/sysconfig/network-scripts. У вас уже должен быть файл ifcfg-eth0. Скопируйте его с именем ifcfg-eth0:1, ifcfg-eth0:2, … и измените в них соответственно адреса и сетевые маски ( а так же переменные DEVICE, BROADCAST и NETWORK — Прим.пер. ). Например, для eth0:1 :

Читайте также:  Another java installation is in progress

Это, в основном, все, что вам нужно. Возможно, вам нужно будет разрешить маршрутизацию на сервере, например для доступа к Internet. Но будьте аккуратны, при этом нужно будет запретить маршрутизацию между локальными подсетями; 192.168.X.0 не должна видеть 192.168.Y.0 . Чтобы избежать этого, используйте брандмауэр, такой как iptables. Его же можно использовать для блокировки доступа в Internet для тех или иных подсетей или хостов.

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

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

  1. Каждый клиент не видел трафик остальных клиентов.
  2. Неисправности одного клиента (broadcast-storm, конфликты IP-адресов, не санкционированные DHCP-сервера клиента и т.п.) не должны влиять на работу как других клиентов, так и всей системы в целом.
  3. Каждый клиент не должен напрямую получать доступ к ресурсам других клиентов (хотя, как специальный случай, можно предусмотреть и разрешение данного трафика, но с его централизованным контролем и/или управлением ).
  4. Клиенты должны иметь возможность получения доступа к общим внешним ресурсам (которыми могут быть как отдельные сервера, так и сеть Интернет в целом).
  5. Общие ресурсы должны также иметь возможность доступа к ресурсам клиентов (конечно при условии, что известен общему ресурсу известен IP-адрес ресурса клиента).
  6. Адресное пространство для клиентов выделяется централизованно и его администрирование не должно быть чрезмерно сложным.

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


Условия 1 и 2 достигаются выделением каждому клиенту собственного VLAN. Условия 3-5 можно выполнить путем объединения клиентских VLAN с запретом прямой передачи трафика между ними. В некоторых источниках эта технология называется “private VLAN”, в некоторых “port isolation”, а смысл ее такой: из каждого клиентского VLAN можно беспрепятственно попасть в некий общий VLAN (и, соответственно, обратно), но вот между клиентскими VLAN передача трафика запрещена. Ну а для выполнения условия 6 выделим для всех клиентов общее адресное пространство вида 10.12.8.0/23, а конкретные IP-адреса будем выдавать по запросу при помощи DHCP.

Таким образом, при появлении у клиента нового устройства адрес для него будет выдан автоматически (и у нас не будет проблем из-за того, что один клиент может использовать для своих нужд единицы 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.

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

Что произошло? Да все, как мы сконфигурировали:

  • DHCPDISCOVER был получен с VLAN 603;
  • запрос был передан через интерфейс br1 нашему серверу DHCP;
  • сервер в ответ на него передал на интерфейс br1 ответ DHCPOFFER;
  • интерфейс br1 размножил этот ответ (т.к. он, по стандарту DHCP, является broadcast как по уровню L3, так и по уровню L2) по всем клиентским VLAN.

Мало того, что мы засветили всем клиентам 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-заголовок, то какой смысл дополнительно обрабатывать его средствами ядра?

Читайте также:  Garmin navigator для android на русском

Ладно, попробуем повесить на каждый клиентский VLAN по DHCP Relay Agent и уже запросы от него передавать на обработку DHCP серверу. Однако оказалось, что Relay Agent не отлавливает запросы от интерфейсов, входящих в бридж (ну это тоже, наверное, логично). Стоило убрать интерфейс из бриджа, как Relay Agent начинал вылавливать запросы, передавать их серверу и отсылать ответы обратно в тот VLAN, в который нужно. При повторном добавлении VLAN в бридж работоспособность агента опять нарушалась и DHCP становился недоступным для клиентов.
“Ну ладно!” — сказали суровые сибирские мужики. Будем делать все по-взрослому.

Для начала вспомним, что в современных 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:

Физический интерфейс eth0 мы не будем переносить с backplate на слой relay (ну, допустим, нам надо будет повесить на него еще какие-то application VLANs, не имеющие отношения к данной схеме). Поэтому мы будем сначала создавать VLAN-интерфейсы на слое backplate, а потом переносить их в слой relay:

Общая настройка видов имен 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. Копирование текста на другие ресурсы без согласия автора запрещено.

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

Ссылка на основную публикацию
Cpu amd fx 8300
Описание AMD начала продажи AMD FX-8300 в октябре 2012. Это десктопный процессор на архитектуре Vishera, в первую очередь рассчитанный на...
Battery remaining time в биосе что это
Вчера я писал о ноутбуке Samsung серии 300E5 (http://ammo1.livejournal.com/262248.html). В этой серии применён очень простой и остроумный способ сохранения жизни...
Battle eye не запускается
К любому онлайн-проекту нужен античит, иначе все баталии превратятся в вакханалию бесконечных патронов и бессмертных бойцов. Но иногда этот самый...
Cpu hash что это
AIDA64 имеет множество тестов, которые возможно применять для оценивания состояния разных составляющих компьютера или техники в целом. Это искусственные тесты,...
Adblock detector