DHCP

следующий наш модуль это модуль про настройку dhcp и здесь мы уже в принципе немножко здесь теперь работали то есть мы говорили про то что есть такие штуки которые позволят нам назначать адреса автоматически мы посмотрели на то как это устроено в ipv4 на сенди если память не изменит один мы посмотрели немножко на курсе по роутингу как можно дичьи и настраивать и здесь мы повторно разберем этот материал просто для того чтобы посмотреть применительно именно к курсу свитч что здесь может быть интересно нам напоминаю что dhcp это протокол который в ipv4 родился как расширение протокола бут пи то есть в свое время когда-то в сетях для конфигурации узлов использовался протокол бут пи который назначал адреса который мог всякие разные штуки делать типа указывать откуда без

дисковым рабочим станции следует грузить образ операционной системы ну и в принципе бут пи был неплохой протокол у него был один фундаментальный недостаток он был классовый ну соответственно когда появились был без классовый адреса нужно было где-то указывать маску и вот придумали мощные расширяемый протокол джи себе который берет вот пишные сообщения и делает к ним дополнение тл вешные опции вот поэтому когда мы говорим про джи теперь для ipv4 мы имеем ввиду в первую очередь что это на самом деле протокол бут пи с дополнительными опциями и вот именно в этих опциях и кроется вся магия протокола джи себе то что дети можно использовать для управления адресами я думаю вы уже догадываетесь так или иначе задачей этого протокола будет вы до раздача каждому узлу необходимой информации для того чтобы он мог работать в айпи сети в том числе эта информация про то какой айпи адрес получить если это необходимо если у него уже есть адрес например полученные по статике вы можете подище

теперь раздать только опции необходимо для его работы это сообщение джи себе информ будет но чаще всего все таки джи себе используется именно для раздачи адресов и там у нас будут четыре сообщения discover offer request acknowledge если говорить про и пиви 4 в ipv6 у джи теперь в общем все те же самые задачи единственное что он уже будет немножко по-другому устроен в том смысле что там не будет уже будешь снова заголовка там будет уже фактически свой отдельный протокол который очень похож на и пиви 4 здесь теперь по смыслу по скажем реализуемым задачам но тем не менее это будет уже как бы другой протокол поэтому 10 и 4 9 6 это протоколы формально разные у них разный формат пакета разные разные все где чипи 4 используют в качестве транспорт буты 10 и 6 это отдельный самостоятельный протокол который использует напрямую вложение в айпи так в любом случае джи себе вы можете раздавать адреса что в

ipv4 что в 6 эти адреса будут выдаваться на ограниченное время в любом случае то есть каждый раз когда сервер говорит у меня есть пачка адресов которые могу раздавать клиентам клиент приходит говорит дай мне адрес и вы выдаете клиенту адрес на определенное время и вы указываете это время в каждом сообщении джи себе вы указываете время т насколько выдается адрес максимум который можно будет указать это вот такое вот количество секунд которые здесь на слайде внизу указано так чем не рисовал к не рисуют печалька 4 миллиарда 2 295 миллионов там с копейками секунд то есть там время указывается на секундах если вы указываете максимально возможное значение 232 степени минус 1 то это будет означать что вы используете максимальный возможно вообще срок аренды который только вкладывается в 32 битные значения если вы возьмете калькулятор посчитаете сколько вот это вот будет в секундах ну если в годах считать то получится что это примерно около 136 лет то есть вы можете выдать адрес на 136 лет и есть такая

договоренность что если действительно кто-то получает айпишник на 136 лет это заменяется словом бесконечность ну действительно да что если кто-то адрес получил то ближайшие 136 лет он может пользоваться все равно что бесконечности все так тем не менее чаще всего мы все-таки выдаем на чуть более короткие сроки адреса то есть не на 136 лет от например на час или на 10 минут или на одну минуту или на там несколько месяцев но в любом случае да это какой-то более разумный срок и соответственно когда сервер выдает адрес клиенту он получает подтверждение что клиент готов использовать этот адрес и он у себя помечает в базе адрес как выданный то есть после того как она немного выдал клиенту он его больше уже никому не выдает но он при этом помнит на сколько времени он выдал адрес на он знает что если клиент не продлит время аренды он не имеет права больше адрес использовать соответственно адрес мы у себя через некоторое время пометим как свободный и можем с ним делать все что захотим время указывается в

секундах и когда вы указываете что вы какой-то адрес выдали то вы запускаете свой собственный таймер дальше вы клиенту отправляете пакет что я тебе на определенные количестве секунд дал адрес клиентов упускает свой собственный таймер время на клиенте на сервере не обязаны синхронизироваться поэтому может быть такое что у клиента там допустим 10 минут на которой он получил адрес закончится позже чем 10 минут который сервер у себя будет считать что он выдает адрес поэтому обычно когда сервер говорит что я выдаю адрес на время какое-то т на самом деле он у себя блокирует этот адрес на то что вот занят на время несколько больше чем ты ну как раз на случай если вдруг будет расхождение во времени между сервером клиентом так можно ли как-нибудь раздавать из разных подсетей разные адреса конечно можно далее когда сервер выдает какой-то айпишник вы указываете на какой срок вы выдаёте клиент понимает на какой срок он получил

этот адрес он им пользуется после того как адрес закончился соответственно клиент должен от него отказаться должен перестать использовать этот адрес либо если он хочет он может его продлить вы в принципе если почему-то знаете что вы имеете возможность распоряжаться определенным айпишником вы можете сказать я хочу продлить аренду то есть не запускать полный алгоритм discover offer request acknowledge а просто прийти к серверу сказать ты мне когда-то выдавал вот такой вот айпишник он все еще у тебя действует то есть ты все еще должен считать что это мой айпишник я хочу чтобы ты мне его продлил в некоторых ситуациях вы можете это поведение увидеть в случае когда у вас компьютер допустим выключается но выключается не совсем а он как-то например засыпает а потом вы его просыпаете и вот он помнит что ему выдавали определенный айпишник он видит что айпишник у него был там не знаю стыдно за 168 117 он видит что у него срок действия еще не прошел поэтому на всякий случай приходит на сервер и говорит я бы хотел продлить аренду потому что я вот некоторое время

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

правилу по какому именно правилу адреса выделяются для конкретного клиента клиент не знает и заказать конкретный адрес случайным ну из случайного диапазона он не может то есть вы можете сказать у меня когда-то был вот такой айпишник я считаю что он все еще действует поэтому пожалуйста продли его но вы не можете прийти сказать мне нравится красивая пишник 190 2 168 1177 вот он такой вот не сделает дальше на экзамене будут дурацкие вопросы типа того как вы именно можете на сервер выбирать адреса для конечных клиентов есть три варианта разметки вашего адресного вашего адресного пула соответственно адреса вы можете выдавать клиентам динамически это значит что у вас есть просто пул свободных адресов приходит новый клиент вы говорите окей я тебе дают свободное пишник из пула и если ты не продляешь эту аренду я его забираю возвращаю обратно в пул в следующий раз этот адрес может быть выдан кому-то еще второй вариант это вручную размещением мануэл вы сопоставляете каждому конкретному клиенту

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

адрес и дальше по все последующие обращение этого клиента будут выдаваться ему именно тот же самый айпишник если говорить про и пиви 4 то у нас дичь себе использует протокол будпи будут configuration протокол и соответственно у двух узлов которые будут обвиниваться тем самым будет пищными сообщениями будут характерные номера портов ведется ли какая-то база привязок или просто похожи от mac адреса база привязок вот да по поводу будут клиент когда будет посылать сообщение будет посылать сообщение из под 67 порта сервер будет посылать сообщение из под 68 порта ну соответственно когда у нас клиент орет на всю сеть дайте адрес он орет с порта 67 на порт 68 сервер отвечает 68 на 67 порт если мы говорим про и пиви 4 взаимодействие то клиент когда хочет получить айпишник он

отправляет сообщение и он это сообщение отправляет чтобы так или иначе получить айпи адрес у него этого и 5 адреса пока еще нету и для того чтобы ему отправить айпи пакет ему нужно заголовок айпи как чем-то заполнить и у него айпи шника пока еще нет и кому он отправляет сообщение он тоже не знает ну с айпишник назначение все просто мы можем указывать братка с 255 255 255 а вот опять шнеком источника все плохо потому что у нас пока еще адреса нет и для случая когда нам нужно отправить пакет и у нас нет еще живого адреса есть специальный случай этой пишник 0 0 0 0 это я не знаю свой адрес но мне надо отправить отправляете такой запрос с адреса 0000 на бродкаст в адрес 255 255 255 255 и ответные пакеты они соответственно пойдут на какие-то адреса тоже то есть сервер должен будет что-то ответить сервер

может ответить на бродкаст сервер может ответить на адрес 0000 но это как бы не очень хорошо потому что как бы никто такой адрес всерьез воспринять не сможет или сервер может сказать я тебе собираюсь выдать вот определенная пишет я тебе отправляю сообщение на этот айпишник и клиент должен сказать вот он поймет вообще что он отправлял пакеты из-под одного адреса ответы ему будут приходить на другой адрес в дичьи пишном сообщении есть специальный флажок бродкаст если вы можете сразу ответ юникастом обработать на тот айпишник который вам собирается сервер выдать то есть он отправит айпи пакет и говорит я тебе собираюсь выдать адрес 122 168 117 и отправить это сразу на айпишник 122 168 117 если клиент такую штуку сможет обработать он говорит я согласен принимать ответы юникастом и отправляют флаг бродкаст 0 если брат каста вставляется в единицу то в этом случае ответы будут приходить на 255 255 255 255 то есть сервер из-под своего и пешника будет

брат кастом рассылать сообщение вообще всем будет говорить я вот собираюсь отправлять пакеты и эти пакеты будут идти брат кастом то есть все в сети их увидят все в сети будут подрываться и почти все в сети скажут я же не заказывал айпишник поэтому там то что вижу и дети пишет на вложение на мнение не интересует для работы вот в пол в рамках решения задачи по получению айпишника у нас используются четыре сообщения надо их знать какой чинаж я надеюсь что вы их знаете еще со сидя один это discover offer request и окно врач вот это вот дара это аббревиатура которая как раз позволяет запомнить какие сообщения в каком порядке идут день дичьи пи discover сообщение когда у вас клиент просыпается у него нет адреса и вот он орет на всю сеть мужики дайте адрес может быть такое что несколько серверов сети услышат сообщение discover и несколько сообщений серверов скажет я тебе готов выдать айпишник из числа тех которые у меня свободные в базе настоящий момент есть и это сообщение идет offer offer может идти

брат кастом или может идти и не кастом если он пойдет и не кастом то его получит только тот клиент который вот собирается услышать этот ответ если он пойдет брат кастом то соответственно все узлы в сети услышат эти офферы ну да немножко напрягутся но в любом случае соответственно клиент который запрашивал айпишник он получит несколько офферов возможно один может быть два может быть три может быть 10 ему надо какой-то один из них выбрать и в то в сторону одного единственного сервера который действительно выдал этот адрес должен уйти пакет но остальным сервером нужно будет сказать ребята я хочу выбрать вот его я не хочу выбирать вас то есть вы у себя эти адреса можете пометить как свободные поэтому сообщение request идет тоже брат кастом вы отправляете пакет с адреса 0 0 0 0 на адрес 255 255 255 255 и вы говорите я хочу выбрать айпишник который мне предложил один из серверов тот кто предложил это и пиш не говорит окей я понял я тебе выдают адрес те кто не предложил это и пиш нет который предложил какие-то другие пиш не

ки видят по код транзакции что ответ идет на то что они предложили но их не выбрали и они у себя помечают адрес как свободный они выдали какие-то адреса не выдали зарезервировали какие-то адреса потенциально за этим клиентом и по их жизненно эти адреса конечно зарезервированы держать не хочется поэтому они попытались предложить адрес клиент отказался они немедленно поверьте пометили как свободный и последнее сообщение так но лишь тот кто получил реквест говорит окей ты можешь начинать пользоваться этим айпишником чей оффер будет выбран да кто будет 1 отвечать ну или если вы хотите вы можете например вести учет тех офферов которые к вам пришли в течение некоторого времени то есть допустим сказать что вы в течение там секунды набираете эти офферы и дальше вы пока кому-то признаку который вы хотите использовать выбираете какой офер вам ближе но стандарт от не регламентирует если вам нравится например только четные адреса пожалуйста используйте четные то есть вы там говорите окей мы

не принимаем первый оффер мы ждем там два три пять десять офферов или там ждем одну секунду и выбираем тот оффер который нам более интересен но чаще всего в реальности никакие вот такие подобные замуты не используются и вот кто первый ответил то в этапе это на самом деле будет некоторой проблемой потому что в сети может появиться какой-то левый сервер который будет находиться ближе к запрашивающему это довольно частая проблема и соответственно если у вас будет такая беда что в сети появится какой-то неправильный другой сервер который будет выдавать неправильные другие адреса до скорее всего он будет выдавать ответы первыми да скорее всего клиенты будут ориентироваться на то чтобы взять айпишники у него если один сервер авторитативный а второй нет вы видимо намекаете на то что в microsoft windows есть реализация дечи себе сервера и там есть такая штука как авторитативный дечи себе сервер но это никакого отношения где и че себе к самому не имеет эта штука указывает лишь то что у вас сервер помечен в

актив директоре как авторитативно или нет если у вас есть домен контроллер но не на есть у вас просить сервер который участник актив директоре на котором запущен 2 чтп сервер и это дичь себе сервер не прописан в актив директоре то тогда это windows of sky реализация дичь себе переходит в сонное состояние то есть она сама себя блокирует типа администратор сказал в актив директоре что этот сервер работать не может но как вы понимаете это очень сильно все завязано на актив директоре это очень сильно все завязано на именно микрософтовскую инфраструктуру и это никоим образом не запрещает другим сервером присылать вам какие-то левые анонсы то есть в самом протоколе 2 чтп ничего про авторитативность про доверенность нету сами сообщения вот эти вот диска диска вероффер реквеста окно лишь они очень тупые и они крайне небезопасны и поэтому при работе с коммутируемой сети дичь себе нужно защищать и защищать не средствами самого дичь себе отдельно на самом деле именно про это будет наш рассказ сейчас не про то что там

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

два вот они берут в идут в магазин там он продает роутер длингер 300 у него четыре дырки на них написано lan дальше эту коробочку приносят до спаковывать достают смотрят на эти самые lan порты говорят но это же у нас локальная сеть нам нужно сделать так чтобы у нас вместо одного lan порта получилось там два или три да ну то есть мы берем патч корт соединяем розетку в стене с этим самым дир 300 соединяем два компьютера который нам надо подключить к розетке в стене в дир 300 и вроде даже начинает все работать но сами понимаете да что к начинает все работать только она еще и dhcp сервером начинает а и пишники раздавать 122 168 00 или какие там ну то есть да по умолчанию такие домашние железки как правило раздают адреса абсолютно типичная беда сам сталкивался с этим несколько раз видел неоднократно как такое происходит не только у себя но еще и в других компаниях и соответственно бороться с этим на неподготовленных свечах крайне сложно то есть это не решается средствами самого протокола dhcp это решается

только на свечах уровня доступа ну давайте вот разбираться чему тут можем предложить схему dora я уже говорил discover offer request окно вич про время аренды тоже говорил то есть и у вас внутри сообщений указывается время в течение которого вы получаете это на на которой вы получаете подрась время в секундах если вы клиенты вы получили айпишник то вот в течение времени ты вы можете использовать этот айпишник дальше нет если вы хотите вы можете периодически эту аренду продлять соответственно первая попытка у вас должна и обычно идти спустя время которая называется t1 это как правило половину срока на это время указывается явно Morm виде в пакете то есть сервер в явном виде вам посылает сообщение что ты пожалуйста следующую время следующую попытку продления адреса дело никогда попала а вот через определенное время которое я тебе в явном виде указываю обычно это как раз половина срока то есть вы говорите я

тебе выдаю адрес на один час и первая попытка продления аренды должна быть через полчаса это все все прописывается в самом сообщении DHCP-шном и время T, и время T1. Если вы начинаете продлять аренду, и у вас это не получается, вы периодически пытаетесь ретрансмитить эти сообщения по правилу, которое не указано в явном виде, но там указывается, что не надо слишком часто посылать эти самые запросы. Но в любом случае вы пытаетесь продлить аренду, пытаетесь, пытаетесь, а оно не продляется, например, потому что DHCP-сервер, который выдал вам адрес, он ушел в перезагрузку или выключился, или что-то с ним еще случилось, сгорели, инопланетяне похитили. И эту самую попытку продления аренды вы пытаетесь сделать юни-кастом, вы не браткастите ее. То есть продление аренды – это сразу сообщение request и сразу попытка получить acknowledge на это. Вы не discover, не offer ничего, и оно идет юни-кастом. Но рано или поздно вы понимаете, что вы пытаетесь достучаться до какого-то сервера,

и он не отвечает, и непонятно, что с этим дальше делать. Адрес терять очень не хочется. Но вы предполагаете, что в сети, возможно, есть какой-то другой сервер, который согласен вам ответить. Может быть, даже тот же самый, но просто на IP-шник поменял, а вы про это не узнали. И поэтому спустя некоторое время после начала продления аренды вы пытаетесь браткастом определить, есть ли в сети такой сервер, который согласен вам выдать адрес. Вы посылаете request, но браткастом. И опять же, у вас есть рекомендованное время, когда это нужно делать. Это время будет называться T2, и оно тоже есть в пакете. То есть вы получаете пакет, и в нем указано три времени. Насколько времени выдается вам адрес, когда начинать попытку продления юни-кастом, и когда начинать попытку продления браткастом. Если в сети есть какой-то сервер, который способен продлить вам эту аренду, он вам ответит, что да, пожалуйста, я не против того, чтобы ты этот адрес считал у себя заметным. То есть это либо если у вас кластер какой-то есть, и один сервер из кластера сдох, но второй может ответить. Либо это тот же самый на самом деле сервер, который просто сменил адрес.

Гипотетически можно сбросить использование адреса с сообщением DHCP-релиз, если вы клиент. И в принципе, стандарт не указывает, но есть способ со стороны сервера отправить такое сообщение клиенту, чтобы клиент отказался от адреса. Это будет сообщение DHCP-force-renew, которое заставляет клиента немедленно продлить аренду. И сообщение DHCP-not-acknowledge. То есть это два сообщения. Одно говорит, немедленно продли аренду. Клиент на него не обязан реагировать, но вот он может попытаться отреагировать. И DHCP-нак – это вот на попытку продления адреса. Вы говорите, нельзя этим адресом пользоваться, немедленно от него отказывайся. Это не очень, конечно, надежная вещь, но тем не менее гипотетически такую штуку можно будет провернуть. Если вы можете отправлять сообщение от имени сервера, то клиент может потерять IP-шник.

Даже если этот IP-шник ему выдал кто-то легитимный, вот вы как нелегитимный сервер можете заставить клиента потерять адрес. Бутпишные пакеты у нас будут иметь следующий формат. Запоминать его не надо, я просто так для справки рассказываю, какие здесь поля есть, потому что иногда название этих полей можно будет встретить в литературе или в каких-то статьях. Сначала идет самое первое поле, однобайтовое, что это за сообщение. То есть бутпишные сообщения, их бывает два, либо бутреквест, либо бутреплай. Бутреквест – это от клиента к серверу, а бутреплай – это от сервера к клиенту. Ну, в принципе, это излишнее сообщение, потому что по номерам портов DHCP-шных и так понятно, кто кому чего посылает. Дальше. HType – это тип аппаратного адреса. Если мы говорим про Ethernet, то аппаратный протокол – это вот канальный уровень у нас, использует MAC-адреса, и поэтому в HType указывается единичка.

Ну, то есть чаще всего вы как раз эту самую единичку здесь и будете видеть. И HLEN – это длина аппаратного адреса в байтах. Если у нас MAC-адрес, то он традиционно считается 6-байтовый. Дальше. Зачем нам нужно указывать, какой там аппаратный адрес будет? Дело в том, что BootP, на самом деле, он предназначен для формирования сетевых адресов по MAC-ам или по канальным адресам в общем случае. И, соответственно, если мы говорим про BootP, про оригинальный протокол, на основе которого потом DHCP зародился, то вы посылали сообщение «я бы хотел получить свой IP-шник», и вы указывали свой адрес, свой MAC-адрес. И вот вы указывали, какого размера этот адрес и какая у него длина. То есть мало того, что вы все это дело вкладывали в Ethernet, но вы еще и говорили, что вот да, окей, у нас Ethernet есть. Но когда DHCP сервер получит этот пакет, MAC-адрес в заголовке, он уже будет потерян. Поэтому мы вынуждены будем указывать то,

какие у нас MAC-адреса прямо в самом сообщении BootP, чтобы если вдруг сервер получит пакет с нашим запросом, чтобы он не вынужден был искать в корзине, какой MAC-адрес был в кадре, в котором мы получили IP-пакет, в котором мы получили UDP-шную детаграмму, в котором мы получили BootP-шный пакет с запросом адреса. Поэтому здесь все это прямо в явном виде будет указано. Клиентский аппаратный адрес. Вот он будет CH-адрес. Это C-клиент, H-аппаратный адрес, hardware-адрес и addr. Ну, понятно, что это адрес. Здесь клиент будет указывать свой MAC-адрес для того, чтобы если вдруг BootP имел привязку MAC-ов к IP-шникам, чтобы вот он сказал, этому MAC-у мы выдаем определенный IP-шник. Поскольку BootP предназначался для работы в самых разных канальных средах,

то размер этого самого канального адреса может быть разным. И под это поле отводилось 16 байт. Ну, соответственно, поскольку мы работаем с Ethernet, то у нас 6-байтовые адреса будут использоваться. Поэтому из 16 байт по факту 6 байт будут заниматься, а остальные будут заниматься нулями. И, соответственно, вот для того, чтобы указать, сколько здесь ненужных нулей, а сколько здесь мясного адреса, указывается вот этот вот самый H-лен. Дальше. Когда у нас есть клиент какой-то, который в BootP хотел получить IP-шник, он отправлял сообщение, что я хочу адрес. Или если он уже имел IP-шник, он мог отправлять сообщение, типа я хочу адрес вот такой вот конкретный для каких-то вот задач. Вот адрес клиента, который клиент сообщал серверу, что он у него уже есть, я хочу его, ну, типа продлить, сообщается в поле CI-адр. Клиентские, буковка C. I – это интернет, потому что BootP работает для раздачи IP-адресов.

И IP – это у нас интернет протокол. Ну, соответственно, вот адрес сетевого взаимодействия. И это как раз интернет. Клиент указывает на свой IP-шник в CI-адр. Сервер, когда будет посылать сообщение, будет выдавать клиенту your IP-адрес, потому что сервер отправляет ответ на запрос клиента, и он говорит, я тебе хочу предложить IP-шник. Вот why I-adder – это как раз your IP-адрес. Сам сервер при этом тоже имеет какой-то IP-шник. Понятное дело, что IP-шник сервера, безусловно, указывается в IP-пакете, но на всякий случай он здесь тоже дублируется. Сервер IP-адрес – это указание на то, какой IP-шник у сервера, чтобы если вдруг вы получили несколько сообщений, чтобы вы, опять же, не рылись в буферах, кто там прислал IP-пакет, в котором лежит UDP-шник-эдетграмма, в который пришел вот этот самый BootP-шник-эдвет. Сервер при этом рядышком указывает, как его зовут. То есть есть такое поле, как S-Name, оно длиной 64 байта,

и это нультерминированная строка. То есть если вы указываете, что сервер у вас называется там server1.company.local, то вы это пишете прямо здесь вот, и, соответственно, дальше указываете все, нулями добиваете. Так, если вы используете BootP, то, возможно, вы это делаете для удаленной загрузки. То есть у вас есть какая-то бездисковая рабочая станция или, например, IP-телефон или что-то еще, и вам нужно указать, где брать, это самое, как называется, где брать файл для загрузки. Предполагается, что сервер, который прислал вам ответ, вот с него надо взять именно некий файлик, и указывается, какой именно файлик вы должны будете взять. То есть это некоторое имя файла, оно будет, опять же, нультерминированное и длиной до 128 символов. BootPish-ные сообщения могли проходить через несколько агентов ретранзляции. То есть у вас могло быть такое, что у вас есть некий сервер,

который выдает адреса, но если у нас BootPish-ные сообщения отправляются браткастом, то они не проходят через маршрутизаторы штатно. Но может быть такое, что у вас есть какой-то маршрутизатор, который говорит, у меня вот здесь вот есть какие-то клиенты, я хочу выдавать им адреса, и эти адреса должен выдавать им внешний какой-то сервер. То есть нам надо сделать так, чтобы сообщения BootPish-ные, которые отправляются на роутер браткастом, дальше отправлялись в сторону сервера. Ну там уже, естественно, Unicast. И вот в этом случае роутер, который будет выполнять перекладывание запросов клиентов в сторону сервера и ответов сервера в сторону клиентов, будет называться словом relay, сервер-последник. Или relay – это наиболее употребительное слово, а в терминологии BootPish он назывался gateway. gateway. И, соответственно, GI-адр – это gateway IP-адрес. Это IP-шник того роутера, который перекладывал пакеты в сторону сервера. И причем их могло быть много. То есть это вот gateway IP-адрес –

самый последний IP-шник, который перекладывал какие-то пакеты туда. То есть могло быть такое, что у нас есть несколько роутеров, и они вместо того, чтобы сразу конечный IP-шник сервера указывать, они говорили, вот этот перекладывает сюда, этот перекладывает сюда, перекладывает сюда. И вот в итоге это все доходит до конечного сервера, который пытается выдать ответ, и он по обратной цепочке будет возвращать результат. Чаще всего, конечно же, мы используем только один relay, но если гипотетически представить себе, что вот мы с BootPy работаем, можно было указывать несколько relay, и тогда в количестве hops у вас будет указано, сколько раз это подвергалось процедуре трансляции. Клиент, когда отправляет запрос, там указывает нолик, и каждый relay, который пересылает запрос куда-то дальше, он прибавляет туда единичку. Но по смыслу своему это типа PolyTTL. Опять же, в большинстве ситуаций мы здесь увидим либо нолик, если у нас сервер получает запрос напрямую от клиента, либо единичку, если у нас запрос пришел на relay, а дальше он переслался в сторону внешнего узла.

Так, вы можете указывать некие флаги, и вы можете указывать поле с опциями. И вот если мы говорим про DHCP, вот вся магия DHCP заключается в этом поле опции. Соответственно, здесь сообщение DHCP всегда начинается с вот такой вот штуки, которая называется Magic Cookie DHCP. Вы указываете вот эту вот колбаску, и дальше после того, как вы указали эту колбаску, вы указываете, какие DHCP-шные опции вы докладываете к этому бутпишному пакету. Здесь будет каждая опция иметь код, иметь некую длину и иметь какое-то содержимое. Вот самая первая опция с кодом единичка, то, ради чего DHCP, собственно, придумывался, это так называемый subnet mask. То есть, когда у вас есть протокол Bupi, там нигде не указывается маска того IP-шника, который сервер предлагает. Да, IP-шник предложить можно, и для этого есть поле your IP address. Но вот указать маску в бутпишном сообщении нельзя.

А в DHCP, соответственно, вот можно сделать расширение и сказать, мы предлагаем IP-шник с вот такой вот маской. Так, более того, на самом деле, когда в DHCP вы раздаете какие-то дополнительные плюшки, которых не было в оригинальном протоколе Bupi, вы имеете возможность указать намного больше, чем просто IP-шник, просто маску. Например, вы можете сказать, что у нас есть сеть. Это вот сеть, там, не знаю, какой-то коммутатор, к которому подключены пользователи. И у нас в этой сети есть DHCP-сервер. DHCP. И у нас есть шлюз по умолчанию, который выходит в интернет. И вот вы можете в этом случае сказать, дорогие слушатели, пожалуйста, используйте IP-шники там .1, .2, .3 и так далее. И в качестве шлюза по умолчанию используйте вот такой вот роутер. И вы можете указать опцию, которая называется роутер. У нее код трешечка. И там можно указать IP-адреса тех маршрутизаторов, которые должны быть поставлены в качестве шлюза по умолчанию.

Соответственно, там кратное четырем байтом поле. То есть вы просто указываете либо один IP-шник, либо два IP-шника, либо три IP-шника. И вы перечисляете IP-шники тех узлов, которые должны стать шлюзами. Если вы используете DHCP в Ethernet, то вы можете указать несколько IP-шников шлюзов, которые находятся в одном широкопечательном домене с клиентами. И у них, соответственно, IP-шники будут из одной и той же сети. Но есть нюанс. Ethernet — это протокол без обратной связи. Поэтому если вы отправляете какие-то пакеты на один роутер, и вот вы выбрали среди нескольких этих самых роутеров один тот, который самый хороший, вы начали его использовать. Если вдруг он помрет, то Ethernet про это вам ничего не скажет. У вас нет никакого способа определить, что пакеты, которые вы отправляете, они отправляются на недоступный шлюз. Поэтому вы должны вот эту вот штуку использовать не очень удобно. Именно потому, что вы, начиная использовать какой-то один роутер из пачки, все время отправляете пакеты дальше только ему,

до тех пор, пока у вас не протухнет запись в кэше ARPA. И если вот только у вас протухнет запись в кэше ARPA, вы попробуете перенайти роутер с определенным IP-шником, вам это не удастся сделать. Только в этом случае клиент может сказать, ага, у нас же есть один роутер, который мы пытались использовать. И раньше использовали, но все было хорошо. Но есть и второй. И вот если один сейчас сдох, то давайте переключаться тогда на второй, на запасной. Процедура переключения будет зависеть от очень многих параметров, от поведения стека IP, от таймаута кэша ARPA, от еще там ряда причин. Поэтому эту штуку не часто использовать для защиты отказоустойчивости шлюзу по умолчанию. Но тем не менее можно будет встретить, в принципе, и такое применение. Дальше. Вы можете указать опцию Name Server. Это DNS сервера. Здесь тоже можно указать несколько IP-шников. И в отличие от роутера, опции со шлюзом, это часто имеет смысл. То есть вы можете указать один IP-шник DNS сервера,

можете указать два, можете указать десять. И если вы укажете несколько адресов DNS серверов, то они действительно будут работать одновременно. Потому что, во-первых, вы можете сказать, что если мы отправили запрос на один Name Server, и он не ответил нам в течение некоторого времени, то мы переключаемся на второй. У нас в DNS есть обратная связь. Вот у шлюза обратной связи никакой нет. Мы отправляем ему пакет, и все. То, что пакет обратно не приходит, ну мало ли почему они не приходят. Может, они дальше где-то потерялись. А вот в DNS мы отправляем запрос, и мы ожидаем на этот запрос в течение определенного таймаута ответ. Если ответ не получен, значит, это нам сервер не отвечает, значит, можно переключиться на другой, на второй, третий, четвертый сервер из пачки. Поэтому вы можете несколько серверов указывать в опциях DHCP, и это даже имеет смысл. Ну, обычно принято два указывать, что если вдруг один сдохнет, второй подключится. Можно будет указывать, как зовут клиента. То есть вернусь на предыдущий слайд. У нас было здесь необязательное имя сервера

в виде нультерминированной строки. То есть можно было сказать, как называется наш сервер. Но здесь нельзя никак указать, как называется наш клиент, какое у него имя хоста. Например, мы хотим знать, что клиент, который к нам подключается, что называется Petya PC. Ну, здесь вот у нас есть 12-я опция. Клиент, когда будет спрашивать, какой бы мне айпишник хотелось получить, вот он будет говорить, меня зовут Вася, Петя, Коля. И вы на основании этого хостнейма можете, во-первых, когда вы выдадите адрес, сделать какую-то пометочку, потому что вот этот вот айпишник мы выдали не просто узлу с мак-адресом вот таким, а узлу именно там Petya PC. Опять же, это нультерминированная строка заранее неизвестного размера. То есть хотя бы один байт там нулевой должен быть. 23-я опция. Вы можете указать TTL, который вы хотите использовать. И здесь, опять же, не часто это приходится делать, но вы можете столкнуться с ситуацией,

когда у вас в сети много роутеров. И вы можете столкнуться с ситуацией, когда некоторые узлы будут использовать TTL по умолчанию слишком маленькие. Ну вот некоторая операционная система может, например, по умолчанию использовать TTL 64. И вы знаете, что у вас в сеть устроено очень странным образом, что там огромное количество маршрутизаторов в цепочке, и вот только по вашей внутренней сети пройти занимает, там, не знаю, 40 прыжков между роутерами. Тогда, когда пакеты будут выходить из вашей автономной системы, будут идти в сторону внешнего мира, они будут выходить с TTL достаточно маленьким, там, порядка 20. И далеко не до всех маршрутизаторов в интернете вы можете дойти за 20 прыжков между роутерами. Если вдруг вы выясняете, что слишком маленький TTL у вас получается на выходе из вашей автономки, вы можете заставить вашу операционную систему клиентские использовать TTL побольше или поменьше, ну, в зависимости от того, какая ваша цель. И для этого используется как раз 23 опция. Вы можете настроить стэк IP на ваших клиентах с помощью опции DHCP.

Равным образом, там рядышком есть опция, например, интерфейс MTU. То есть вы можете сказать, что тот интерфейс, на котором вы получили адрес, у него есть размер вложения в канальный уровень, ну, например, там Ethernet интерфейс, как бы по умолчанию в Ethernet мы можем отправлять пакеты до 1500 байт размером. Но мы знаем, что у нас есть вот этот вот роутер, и дальше он в интернет выходит через PPP, там PPPOE. И, соответственно, в PPPOE мы теряем там несколько байт на заголовке PPPOE. И вот в этой ситуации нужно будет клиентам сказать, ребята, постарайтесь, пожалуйста, отправлять пакеты поменьше размером, чтобы не 1500 байт отправлять, которые нам придется потом дербанить на части, а отправляйте сразу там 1480 пакеты, чтобы они заведомо пролезали вот в этот вот PPPOE-шный канал. Мы в DHCP конечным абонентам говорим, что, ребята, используйте, пожалуйста, максимальный размер пакета вот такой вот.

Дальше. Вы можете в DHCP раздать опцию 33, которая называется static IP route, и имейте, пожалуйста, в виду, что эта опция предполагает, что вы выдаете какие-то пары сущностей, которые будут иметь длину 8 байт, ну, каждая сущность по 4 байта. Можно подумать сначала, что это как раз замечательный размер для того, чтобы выдать сетку, соответственно, IP-шник плюс маска. Но на самом деле нет. Вы выдаете пары по 4 байта, каждая получается 8 байт сущность, и в паре первая половинка – это адрес сети, а вторая половинка, вторые 4 байта – это адрес шлюза, и здесь маски нигде нету. Соответственно, изначально эта опция появилась в DHCP для классовых сетей. Вы выдавали адреса, и вы выдавали адрес сети классовый,

и, соответственно, маска сети автоматически определялась из IP-шника. То есть вам 8 байт было вполне достаточно для того, чтобы вы могли сказать, вот у нас сетка 10.0.0.0. используете для нее маршрут в сторону какого-то другого роутера. То есть это дополнительно к тому, что была опция роутер, которая шлют по умолчанию, дополнительно вы выбрасывали какие-то еще кастомные маршруты, но только для классовых сетей. Сегодня эта штука работает чуть-чуть иначе. То есть понятно, что сегодня классовых сетей уже нет, но если сегодня вы попытаетесь заказать 33-ю опцию, то она будет указывать на один IP-шник по 32-й маске. Поэтому будьте, пожалуйста, внимательны. Оно называется static IP-Route, но по факту оно даст. На отдельный IP-шник маршруты будет ставить. Это не про то, что у нас какие-то случайные маршруты в IP. Это вот маршрут именно дал одного единственного адреса. Если вы хотите использовать настоящие маршруты, полноценные, то для этого будет использоваться опция classless route и 121-й код, соответственно.

У нее длина будет переменной длины, но как минимум 5 байт. То есть 4 байта на IP-шник и 1 байт на длину маски добавляется. Из того, что здесь еще, например, интересное есть, это вы можете указать тайм-аут кэша ARPA. И как раз это очень частое будет явление, если вы используете Ethernet и несколько маршрутизаторов. То есть вы указываете несколько IP-шников роутеров и говорите, давайте мы будем отправлять клиентам указание, что у нас 2, 3, 5, 10 роутеров используются. И, соответственно, переключение между роутерами будет выполняться тогда, когда мы попытались воспользоваться первым роутером, а у него нет ответа на наш ARPA-запрос. То есть фактически для определения доступности роутеров вы будете использовать обычный протокол ARP. Но чтобы почаще тыкать палочкой в роутеры и определять, что они издохли, вам нужно будет поставить кэш ARPA, чтобы он протухал максимально быстро.

И вот вы указываете там, например, 1 секунду. И тогда вы каждую секунду будете долбить каждый роутер, каждый узел в вашей сети ARPA для того, чтобы определить, живой он или нет. Ну и в этой ситуации, если вдруг один из роутеров сдох, то вы потыкали его ARPA и переключились на следующий роутер. Ну, естественно, это вызывает лютое количество бродкастов. Поэтому надо быть очень осторожным, потому что вы же не только роутер начинаете так пингать, вы же начинаете вообще все узлы, с которыми вы когда-либо взаимодействовали за последнее время, тыкать палочкой по ARPA. Вот. 150-я опция – это TFTP сервер IP-адрес. Это указание IP-шника, с которого надо загрузить какой-то файл, который вы указали в поле File Name. То есть вы можете сказать, дорогой узел, ты бездисковая рабочая станция, или ты IP-телефон, или ты кто-то еще, кто получает конфигурацию по DHCP, поэтому, пожалуйста, возьми, сходи на TFTP сервер с таким вот IP-шником

и получи там свою конфигу. Или если у вас нет желания использовать опцию 150-ю с IP-шником, потому что вы заранее IP-шник не знаете, и вот есть опция 66 – это TFTP сервер Name. Она предполагает, что у вас работает DNS. Ну, то есть, понятное дело, да, что в этом случае добавляется еще промежуточное звено в виде DNS-сервера. Клиент получает TFTP сервер Name, допустим, там, не знаю, server1.company.local. Вот он с него должен загрузить какой-то файл, который указывается в bootpish-ном заголовке, после чего он идет в DNS-сервер, спрашивает там сервер company.local, в какой IP-шник реализовывается, и после этого уже туда подключается и скачивает нужный файл. Любимая опция 82 – Client Information. Да, эта опция, она есть, мы про нее даже отдельно будем говорить, используется чаще всего в провайдерах для того, чтобы указать какую-то информацию о том, откуда пришел запрос клиента.

То есть там чаще всего указывается номер порта, из-под которого пришел запрос. И эту информацию подделать клиент не может. Все остальные параметры, которые клиент отправляет в запросе, он может сконструировать по любому своему хотению, то есть он может их подделать. А вот эту 82-ую опцию, ее добавляет не клиент, ее добавляет транзитная железка, тот самый Relay. То есть у вас есть клиент, он придумывает запрос, посылает его на, допустим, свитч. Свитч его дальше прокоммутирует в сторону, допустим, роутера, который переложит это в сторону сервера. Вот это у нас роутер, а это у нас сервер. Но вот этот вот товарищ, он скажет, я когда буду через себя пропускать DHCP-шные запросы, я в них добавлю 82-ую опцию, из-под какого порта оно пришло. Ну, например, Fast Ethernet 0.1. И когда мы говорим, что у нас есть вот этот вот свитч, который добавил указание, что из-под порта Fast 0.1 пришел запрос, этот запрос доходит до роутера Relay и Relay Forward Distance в сторону сервера,

сервер получает эту самую 82-ую опцию, и он может сказать, я ничему не верю в этом запросе. То есть я не верю ни единому в нем слову, я не верю your client IP address полю, я не верю запрошенный IP-шник от клиента 50-ой опции, я не верю тому, что там MAC-адрес какой стоит, потому что это все можно легко подделать. Но вот эту вот информацию добавила моя собственная доверенная железка. Я верю тому, что это пришло из-под порта Fast Ethernet 0.1 на свитче 17. Поэтому я могу в базу посмотреть, кто за этим портом сидит, убедиться, что там сидит Петя, и выдать Пете всегда тот самый IP-шник, который у Пети зарегистрирован. Поэтому Петя может хоть обменяться MAC-ами, хоть обменяться IP-шниками, хоть обменяться чем угодно, хоть что сконструировать в запросе, ответ все равно будет, дорогой Петя, на тебе твой адрес. Вот. Ну да, это провайдерская тема. В предприятиях она не очень частая, потому что, ну а что, в предприятиях очень редко кто-то подменяет IP-шники.

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

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

Не знаю, из Камчатки. Вот мы в Москве, он на Камчатке, он приехал в командировку в наш офис. Нет смысла зарезервировать за ним адрес на 3 месяца. Если у вас гостевая сеть, лучше восстанавливать срок аренды такой, который будет самый маленький из каких-то разумных. Ну, например, там 5 минут или 10 минут. Тогда адреса будут у вас высвобождаться очень быстро. Приехала делегация из Камчатки, 200 человек. Вы им выдали 200 адресов. Они вышли из здания, адреса освободились. Приехала другая делегация из Иркутска, тоже 200 человек. И снова эти же IP-шники выдались уже другим делегатам, из другой делегации. Если мы хотим поменять адрес клиента в базе DHCP, то время аренды огромное. Можно заставить клиента отказаться от адреса? То есть, пока клиент использует этот IP-шник, вот он его использует, мы говорим, окей, клиент использует этот адрес, пусть использует дальше. Если мы на клиенте можем сказать, что мы хотим поменять IP-шник на клиенте,

то мы можем послать сообщение DHCP-релиз, клиент откажется от адреса, и дальше сервер у себя в базе пометит, что адрес свободный. И мы можем... Например, если мы хотим сделать такое, что у нас есть клиент, и у этого клиента сейчас IP-шник какой-то неправильный, и мы прописали новое правило, что у этого клиента в следующий раз айпишник должен выдаваться правильный. Вот мы приходим на клиента, говорим DHCP Relays и DHCP Renew. И, соответственно, он обновляет свою аренду и получает уже новый айпишник. Имею в виду именно со стороны сервака, когда есть привязка к маку. Ну, голову никто не отменял. Если вдруг вы понимаете, что у вас частая задача менять айпишники, которые привязаны к макам, ну, тогда да, тогда надо небольшой срок аренды ставить. Рекомендация именно в корпоративной сети, совершенно абстрактной, произвольной, абстрактной корпоративной сети в вакууме выставлять побольше времени аренды

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

Как минимум, вы захотите включить какие-то адреса в этот пул, и делается это командой network. То есть вы указываете, что определенная сеть будет в пуле DHCP адресов находиться. В нашем случае мы выдаем сетку 10.0000-24. Это все адреса, которые будут в этой сети, они будут выдаваться клиентам. Если вдруг вы захотите, чтобы некоторые адреса по факту клиентам из этой сети не выдавались, чтобы, ну например, там, не знаю, сказать, что у нас некоторые адреса зарезервированы под какие-то служебные нужды, и их не следует назначать клиентам. Для этого есть команда IP DHCP excluded address. Она на уровне глобальной конфигурации указывает, что в принципе, теоретически, ни при каких условиях DHCP определенные IP-шники выдавать не будет. Вы в этой команде указываете диапазон адресов, начиная с какого и по какой вы не хотите выдавать. То есть они настраиваются не в пуле, а в глобальном конфиге, что ни при каких обстоятельствах, ни в каком пуле эти адреса выдаваться клиентам не будут.

Дальше. Вы наверняка захотите назначить какие-то дополнительные опции. То есть мало того, что вы скажете, что у нас есть адреса, вы, скорее всего, скажете, что с этими адресами должны идти какие-то плюшки. И вот эти плюшки могут быть шлюз по умолчанию, DNS сервер, доменный суффикс, то есть помощь DNS клиенту на конечных узлах, который поможет им резолвить имена в вашей сети. Делается это в настройке пула, то есть вы указываете Default Router, DNS сервер. Можно один, можно несколько указать через пробел. Доменное имя тоже там, Network Education.ru, как пример. CISCO про некоторые опции знает, и некоторые опции вы в вопросике увидите, что она может вам их специальным образом поименовать. Допустим, вот та же самая там опция номер 3, раутер, опция номер 6, DNS сервер. Они вот здесь вот есть, и вы можете их использовать. Ну и также вы можете указать, что вас интересуют раздача каких-то опций, которые штатно CISCO не знает.

Вот, например, TFTP сервер IPшник. Это опция 150. Вы можете ее тоже создать. Вы указываете, что будете раздавать кастомную опцию с кодом 150. У этой опции мясо тип IP. И, соответственно, дальше идет содержимое IPшник. Ну вот, 1002 в нашем случае это IPшник DHTP сервера. Так. Да, то есть вы можете на CISCO выдавать любые опции, которые захотите. Указываете option, дальше код опции, тип содержимого и само содержимое. Далее. Если вы хотите зафиксировать какой-то один IPшник за конкретным клиентом, есть два варианта, как это можно сделать. Это так называемые старые и новые способы. Называются они так, ну, естественно, неофициально, потому что есть вот этот вот самый способ, который в кавычках старый. Давайте кавычки поставлю. Это способ, который описан в любой документации, во всех книжках.

И на экзамене вы тоже должны будете пользоваться, вероятно, именно им. Способ этот выглядит следующим образом. Вы создаете пул отдельный. Пул из одного адреса для конкретного клиента. То есть у вас есть клиент, который называется Client1. Вот вы говорите, создаем пул под него. И в этом пуле вместо команды Network мы указываем хост. И дальше указываете IPшник и маску. Для того, чтобы сказать, кто конкретно будет получать этот IPшник и маску, вы указываете какой-то идентификатор. Самый простой идентификатор — указать hardware address. Это MAC-адрес. То есть вы указываете, что обладатель вот такого MAC-а будет получать вот такой вот IPшник. При этом, естественно, это не очень удобно, потому что на каждого клиента держать отдельный пул. А если вам надо 200 тысяч резервирований сделать из одного пула, ну то есть делать отдельный пул, что такой IPшник занят, такой IPшник занят, такой IPшник занят, такой IPшник занят, и все остальные IPшники тоже заняты, ну это как-то бредово, да, слегка. Но тем не менее в старых цисках вот только так и сделать и можно. Если у вас iOS новый, вы можете сделать резервирование прямо в самом пуле.

То есть вы создаете пул с командой Network и говорите, все IPшники, начинающиеся на 10.0.0.0 по 24 маске, они в этом пуле живут. И в этом пуле адрес 10.0.0.2 зафиксирован за абонентом с аппаратным адресом вот таким вот. То есть это намного более логичная, намного более понятная структура. И главное, писать надо меньше. То есть вы не создаете отдельный пул, вы всего лишь говорите, что у вас есть существующий пул, в котором отдельный IPшник зафиксирован за конкретным клиентом. И теперь, когда клиент с этим маком будет приходить, ему будет выдаваться всегда адрес 10.0.0.2. Поддерживается это не на всех iOS. Должен быть достаточно свежий iOS, но тем не менее, да, вот он на актуальных iOS, оно есть. Рекомендую пользоваться в реальном мире именно этим способом. Так, теперь по поводу того, как адреса выдаются. То есть у нас есть клиент. Этот клиент начинает орать на всю сеть. Мужики, дайте адрес.

Рисовал клиента. Он подключен к свечу. Этот свеч подключен к роутеру на интерфейсе. Там, допустим, какой-нибудь вот этот вот интерфейс. Там гигабит 0.0.0. И у нас на этом роутере есть, соответственно, пул. Этот пул называется пул... Пул... Подчеркивание name. Ну, не буду писать пул name. Просто пул и все. И у нас на интерфейсе гигабит 0.0 висит айпишник. Ну, например, 10.0.0.1. Слышь 24. Вот когда Discover приходит на наш роутер, Discover приходит на интерфейс, на котором висит айпишник 10.0.0.1. И роутер, понимая, что на нем, в принципе, работает DHCP сервер, автоматом включает DHCP слушание на тех интерфейсах, айпишники которых попадают в пул. То есть по факту того, что 10.0.0.1 попадает в пул пул name, мы говорим, мы на этом интерфейсе DHCP слушаем. И когда приходят запросы на адрес, на этот интерфейс, мы именно из пула, который называется пул name, будем выдавать адрес.

Если вы хотите, вы можете сказать, давайте у нас еще другой интерфейс будет, который в другую сетку смотрит. Там будет не 10.0.0.0, а 10.0.1.0, 10.0.2.0, 10.0.3.0. У нас будет куча пулов. И, соответственно, в каждом пуле у нас будет адрес, который висит на соответствующем интерфейсе. То есть мы нигде на интерфейсе не пишем, что этот интерфейс работает в пуле, который называется пул подчеркивание name. Адреса из пула пул подчеркивание name начинают раздаваться на интерфейсе сами, если айпишник на этом интерфейсе попадает вот в эту вот сетку. Вот. Поэтому вы можете на циске иметь много разных пулов. И адреса будут выдаваться именно из нужного пула просто по факту того, что запрос, пришедший на интерфейсе с айпишником 10.0.0.1 по 24 маске, означает, что клиент должен получить айпишник из этой же сети. Если у нас на интерфейсе висит 10.0.0.1.24 и у нас есть пул, в который включена сетка 10.0.0.0 по 24 маске, значит клиент должен получить адрес именно из этого пула. Я думаю, что только айпи, потому что маска клиента будет выдаваться вот именно вот это вот.

Но надо это проверить. На самом деле никогда не пробовал выдавать нетворк с маской, отличающейся от того, что на интерфейсе прописано. Но можем сейчас просто проверить. Далее. Далее, далее, далее. Когда мы создаем пул, мы можем посмотреть, насколько этот пул хорошо используется. То есть сколько адресов в нем занято, сколько свободно. Для этого есть команда showip.dhtppool, которая покажет, соответственно, сколько у нас сейчас адресов выдано. Leased addresses. Здесь оно показывает 0, но это вранье на самом деле. В реальных железках здесь показывается настоящее число. Total addresses. Сколько всего адресов в пуле. Ну, соответственно, тут показывается в соотношении процентное, сколько по факту у нас получилось. То есть там, допустим, один адрес из 254. Это значит, что мало. Если мы видим там, что 200 адресов из 254, то это, соответственно, будет много.

Показывается, сколько в процентах вы видели утилизацию максимум и минимум за последнее время. Ну, в нашем случае Utilization Mark показывает, что максимальная утилизация – это 100%, которая может быть, но мы ее не видели. По факту видели только 0. И показывается, какой адрес мы в ближайшем времени будем выдавать. Вот ближайший адрес, который мы будем выдавать – 10.005. И у нас есть указание, что, в принципе, адреса в этом пуле с 10.001 по 10.00254. Но адрес выдан всего только один. Что сразу возникает вопрос. Здесь вот как-то подозрительно 0 стоит. Ну, то есть на самом деле он один. И 10.001 – это IP-шник самого роутера. 10.002 и 10.003 и 10.004 – это какие-то другие адреса, которые, допустим, мы попытались выдать или выдали. И следующий адрес, который будет – это 10.005. При этом выдали мы по факту только один адрес. И видно, что IP DHCP binding, какие именно адреса были выданы клиентам.

10.002 был выдан клиенту с Client ID вот таким вот. То есть вы можете по разным критериям выдавать адреса для клиентов. Можете по Hardware Address – это обычный MAC-адрес. Можете по Client ID. Вот это вот Client ID – это на самом деле просто текстовая строка с определенным содержимым. 0.00 – это ASCII символ пустой строки нуля, нулевого символа. Дальше 63 – это буковка С. 69 – это буковка I. 73 – это буковка S. 63 – мы уже знаем, это буковка С. 6F – это буковка О. Дальше 2D. Если мне склероз не изменяет, 2D – это… Сейчас, мне склероз изменяет. Это какой-то символ пунктуации? То ли точка?

По-моему, точка, да. Дальше 35 – это 5. 30 – 0. 30 – 0. 30 – 0. 2E – это снова какой-то знак пунктуации. Вот это точно точка. Здесь циск. Допустим, два двоеточия. 5 – 0 – 0. Дальше. 35 – 30 – 30 – 30. 2E – точка. 30 – 30 – 30 – 32. 30 – 30 – 30 – 32. 2E. 30 – 30 – 30 – 30. 30 – 0 – 0 – 0. 2D – это вот опять тот самый знак пунктуации, который я не помню. Который гипотетически двоеточия. И после этого 47 – 69 – 32F30. Я не помню, что это там дальше означает. То есть я не настолько хорошо помню таблицу ASCII. Я помню, что все цифры начинаются на тройку. А вот эти вот 63 – 69 – 73 – я просто помню, что это циска. Но видно вендора, видно MAC-адрес. И дальше видно какую-то еще колбасу, которая здесь есть.

Это ClientID, скорее всего, это название интерфейса. То есть мы видим, что это железка с типом циска. Что это железка с MAC-адресом вот таким-то. И названием интерфейса вот каким-то еще. Но для сервера это просто текстовая строчка. И вот он говорит, вот я такую текстовую строчку фиксирую в качестве ClientID. Если вдруг кто-то придет с таким же ClientID, я выдам ему вот такой же адрес, пока он будет действовать. Адрес выдан на время. Показывается, когда протухнет аренда этого адреса. И тип размещения автоматически как раз указывает, что вот если кто-то нам придет, мы выдадим ему этот адрес, покуда у нас действует аренда. Show IP DHCP Conflict показывает, что у вас роутер мог попытаться выдать кому-то адрес, но он попытался этот адрес проверить на занятости. Внезапно выяснилось, что адрес уже занят. И вот вы можете делать это разными способами.

В нашем случае там 10.003 мы попытались попингать, и он пингался. А 10.004 мы попытались ARP пощупать. И не просто ARP, да, gratuitus ARP. Значит, мы сидели-сидели спокойно, никого не трогали, думали, что 10.004 свободен. А к нам пришел внезапный бесплатный ARP. И мы поняли, что кто-то отправляет ответы ARP из-под адреса 10.004, который у нас в базе числится как незанятый. Поэтому этот адрес мы помечаем как конфликтный. И эти адреса вычеркиваем из списка и больше их никому не выдаем. Вы должны будете периодически проверять эти самые конфликты, потому что в нормальной ситуации у вас там ничего не должно быть. Но если вдруг, например, кто-то прописал ручками IP-шник, и ЦИСК попыталась этот адрес считать свободным, но внезапно убедилась, что он на самом деле занят, то, соответственно, нам этот адрес больше никогда не будет выдавать. И если это просто кто-то одновременно попытался такой IP-шник использовать, и ЦИСК это дело пропалило,

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

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

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

и у вас должен быть какой-то специальный адаптированный под ваши нужды DHCP сервер, который будет в соответствии с каким-то алгоритмом влиять на поведение DHCP сервера. И в такой ситуации вы, скорее всего, сделаете один или два центральных DHCP сервера, которые будут связаны с базой биллинга, и вы скажете, что у вас все роутеры, которые в сети находятся, они должны будут отправлять запросы, ну, то есть запросы клиентов релейть в сторону тех самых двух выделенных серверов. Опять же, это больше провайдерская штука. В сети предприятия встречается не очень часто. Но, тем не менее, да, если вдруг у вас много-много-много широкомещательных сред, АК, Виланов, и вы хотите использовать один или два сервера, которые будут на всю сеть работать, то в этой ситуации вы как раз можете использовать DHCP релей. Смысл его будет заключаться в следующем. У вас есть клиент, он орет на всю сеть. Мужики, дайте адрес. У него самого IP-шника еще нет, и он отправляет запросы на адрес 255-255-255-255-255-255-255.

Мы сейчас для определенности предположим, что он заказывает флаг broadcast1 в предположении, соответственно, что все ответы должны тоже идти до него broadcast, что он не понимает, что если вдруг сервер предлагает ему IP-шник 10.0.0.17, что пакеты Unicast на адрес 10.0.0.17, про которые он еще ничего не знает, он должен обрабатывать тоже. То есть сами DHCP-ответы, которые будут, вот он говорит, я не понимаю ничего, кроме broadcast, которые будут приходить в ответ. Он заказывает флаг broadcast, он отправляет свой DHCP-дискавер-бродкастом, и, соответственно, этот broadcast распространяется на все узлы в пределах широковещательного домена. Роутер ловит такой пакет, говорит, у меня есть указание, что все DHCP-шные запросы следует перекладывать в сторону вот этого вот сервера, но они не просто перекладываются, то есть мы не просто повторяем тот же самый пакет, тот же самый кадр, который к нам пришел,

мы должны будем это дело немножко модифицировать, потому что здесь могут быть транзитные роутеры в цепочке, и мы не хотим тупо перекладывать broadcast-овые кадры, мы хотим сделать какую-то продвинутую логику, поэтому вместо broadcast-а такой посредник делает Unicast-овый кадр, Unicast-овый пакет, простите. Содержимое DHCP-запроса остается, но вместо broadcast-а он делает Unicast. И, соответственно, IP-шники, которые были с адреса 0.0.0.0 на адрес 255.255.255.255 пакет, шел изначально, вот они, соответственно, выбрасываются, и вместо них IP-шник, который висит на том интерфейсе, на котором релей получил такой запрос, то есть, например, 10.0.0.1, он пишется в качестве адреса источника. И, соответственно, настоящий адрес сервера, ну, не знаю, там 10.2.2.2. В Kibit пишется в качестве адреса получателя. У нас был broadcast-овый запрос,

мы из него сделали Unicast-овый запрос на сервер. И сервер получает запросы именно из-под того IP-шника, который висит на том интерфейсе, где был получен запрос. Это очень важно, потому что на этом сервере тоже может быть много пулов. У него может быть пул для одной сети, для другой сети, для третьей сети. Более того, этот сервер, скорее всего, имеет много разных пулов. И, соответственно, у нас этих роутеров, которые присылают такие запросы, будут вагоны маленькой тележкой. У них у каждого есть свой, ну, назовем это, свой VLAN, в котором сидят юзеры. И, соответственно, в каждом этом VLAN есть отдельная IP-сеть. И вот здесь у нас сетка 10.0.0.1, здесь 10.1.1.1, здесь 10.2.2.1. Ну, то есть это все разные отдельные сети. И нам нужно понять, когда запрос от посредника приходит, из какой сети оно пришло. И вот как раз вот по этому IP-шнику источника видно, из какой сети оно пришло. И мы точно так же берем IP-шник источника, смотрим, в каком пуле находится этот адрес, и выдаем IP-шник из этого пула.

Вот, так что логика здесь будет достаточно простая, но, на мой взгляд, очень элегантная. Но когда такой дискавер обработан, сервер в ответ посылает сообщение тому, кто спрашивал. То есть он говорит, сообщение пришло из-под адреса 10.0.1, вот я на него 10.0.1 и буду посылать юникастовые ответы. Ты тут просил IP-шник, на тебя IP-шник. Роутер, посредник, принимает такой юникастовый оффер и, соответственно, браткастит его во внутреннюю сеть. Клиент получил оффер в ответ на свой дискавер. Ну, соответственно, он выбирает его, говорит, я согласен взять такой оффер, отправляет реквест. Опять же, отправляет браткастом. Точно так же он перекладывается в юникаст в сторону сервера. Точно так же сервер говорит, окей, не проблема, пользуйся, пожалуйста, этим IP-шником. Юникастом отправляет на роутер. Роутер перекладывает это в сторону браткаста, в сторону конечного клиента. Вот эта вот штука, она, соответственно, позволяет вам

не держать полноценный пул адресов на циске, но она позволяет держать полноценный пул адресов на каком-то внешнем сервере, а циска или циски, которые у вас в сети есть, они, соответственно, просто фарвардят запросы на роутер. Опять же, чаще всего эта штука встречается в провайдерских сетях. В сети предприятия не часто ее можно будет встретить, но вот примерно представлять, как эта штука работает, вы должны даже для экзамена по свитчингу. Как это включается? Прописывается команда на интерфейсе. Вместо указания какого-то пула, который у вас там мог висеть отдельно, вы указываете просто на интерфейсе команду ip helper address, дальше ip-шник шлюза. Это как раз тот самый ip-шник, на который вы будете посылать запросы. И ip-шник источника вы берете с самого этого интерфейса. То есть, если у нас здесь указано на интерфейсе что-то, интерфейс vlan1,

то, соответственно, ip-шник, который висит на интерфейсе vlan1, будет браться в качестве ip-шника источника в восходящих пакетах вместо 0000, и ip-шник получателя будет 1001 вместо браткастов 255, 255, 255, 255. Сразу вы можете сказать, что helper address по виду команда какая-то странная, потому что она вроде бы как не содержит слова dhcp, не содержит слова relay, и вы будете абсолютно правы, потому что эта команда не работает с протоколом dhcp. Она делает очень простую вещь. Она берет любые широковещательные пакеты известных форматов. То есть, если она видит широковещательный ip-пакет, она его перекладывает в сторону указанного ip-шника. Ну, там не любой совершенно широковещательный пакет должен быть, а именно udp-шный. И, соответственно, там вложения в udp могут быть tftp, dns, tcax, ntp. Что там еще бывает udp-шное широковещательное? То есть, вы будете любые широковещательные пакеты переделывать в unicast-овое

и отправлять в сторону вот этого самого ip-шника. Если вы хотите, чтобы у вас не любые запросы, не любые широковещательные пакеты forward залезть в сторону этого ip-шника, то вы должны будете в глобальном конфиге сказать команду no ip forward protocol udp, и дальше указываете, что вам не нравится. То есть, по умолчанию там все включено. Вот вы можете сказать, что вам все не нравится. переключаете ip forward protocol udp, tftp, dns, ntp, что там еще у нас есть, tcax. Вот. И вы в списке как раз указываете, что вам не нравится. Но оставляете только dhtp. В принципе, в большинстве ситуаций это не требуется, но иногда вы можете столкнуться с ситуацией, когда, например, в сети будет большое количество cисок ненастроенных, и они будут желать получить ip-шник, и все вот эти вот запросы на получение ip-шника, они, естественно, будут forward-иться в сторону внешнего сервера,

но также там будет и запрос на tftp конфигурацию, там же будет запрос на время, там же будет запрос на многие разные другие штуки. Это все использует udp, широковещательную рассылку, и все это будет по умолчанию forward-иться командой ip-хлабор-адрес. Если вы хотите, вы можете на свече, на транзитном свече, добавлять опцию 82, ip-dhtp-rlay, information option insert. В сети предприятия это не нужно, но если вы работаете в сети провайдере, и вы увидите на интерфейсе вот эту вот штуку, не пугайтесь, это как раз та самая опция client information, что если вдруг вы на этом интерфейсе получаете dhtp-шный запрос, и вы его просто коммутируете дальше, вот эта вот команда, она как раз бросит в транзитные кадры из Orneta дополнительные указания про то, на каком порту это получено. То есть это вроде бы как бы к dhtp-relay имеет отношение, но на самом деле нет, на самом деле оно не relayt ничего, оно просто добавляет опцию. То есть это немножко дурацкая логика циски,

что в helper-адрес мы настраиваем dhtp-relay, а вот это вот ip-dhtp-relay information option insert, на самом деле никакого relay там не происходит. Там происходит просто добавление опции 82. Ну и, соответственно, в транзитные кадры просто мы смотрим, что каждый кадр, который мы пропускаем через себя, вот мы добавляем эту самую опцию или не добавляем, если там нет dhtp. В некоторых случаях вы до сервера должны будете сказать, что мы принимаем эту самую 82-ю опцию, то есть может быть такое, что к нам приходят какие-то кадры dhtp-шные, и мы должны будем доверять тому, что приходит в этих кадрах, в этих... в этой 82-й опции. Почему по умолчанию доверия этой самой 82-й опции нету? Потому что если вдруг у вас есть роутер, который... ну или сервер dhtp, который подключен напрямую к клиенту, ну либо через транзитный свитч, который не выполняет добавление 82-й опции,

то в этой ситуации получится, что это клиент вбросил 82-ю опцию, и верить ей нельзя. Вот по умолчанию Cisco не доверяет 82-й опции. Если вы хотите сказать, что в сети есть свитч, который добавляет 82-ю опцию, и, соответственно, дальше клиент что бы ни отправил, 82-я опция уже доверенная, вот надо будет сказать ipdhtp, relay information, trust all, но это делается на сервере, на dhtp-сервере, который получает 82-ю опцию от свитча. Поэтому по умолчанию он не доверяет ей, но если вы хотите, вот вы можете увидеть эту команду в ситуации, когда вы ей доверяете, потому что это вы ее сами и проставили. Что будет, если у вас будет в сети больше одного dhtp-сервера? Ну это как раз вопрос про то, что будет, если там кто-то начнет раздавать какие-то левые адреса. Вы можете столкнуться с двумя ситуациями, когда будет происходить такое, что в сети больше одного сервера. Первая ситуация – это вы хотите отказоустойчивость, что если один сервер упадет, второй подхватит его задачи на себя.

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

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

каким-то образом реплицировать базу выданных IP-шников друг с другом. То есть, если вы сможете это сделать, то получится, что может быть ситуация вида, у нас проснулся клиент, он сказал, я хочу адрес, и дальше ему пришло два оффера одновременно. Один говорит, я хочу тебе предложить 10.001, а другой говорит, я тебе хочу предложить 10.002. Ну, соответственно, в этой ситуации клиент говорит, я забираю адрес 10.001, левый сервер помечает у себя этот адрес как занятый, правый, соответственно, освобождает адрес 10.002, и после того, как клиент с левым сервером завершает процедуру аренды, ну, не завершает сам процесс аренды, а завершает только схему Dora, первый сервер на второй посылает сообщение 10.001 занят, пометь у себя, пожалуйста, что на определенный срок он занят. И каждый раз, когда будет у вас аренда продлеваться, первый сервер на второй будет посылать специальное контрольное сообщение, что, пожалуйста, считай по-прежнему, что этот адрес занят.

То есть такие вот штуки, они позволяют реплицировать базу занятых IP-шников между двумя узлами, и если у вас будет использоваться такое поведение, то в этом случае получится, да, что один и тот же IP-шник не может числиться занятым у одного сервера и свободным у другого. Если у вас такой штуки нету, то есть вы понимаете, что оборудование, с которым вы работаете, такую возможность не предоставляет, то можно будет сделать адреса из непересекающихся диапазонов. Например, сказать, что у нас левый роутер, левый сервер выдает адреса там из левой половины диапазона 10.0.0.0 по 24 маске. Соответственно, вторую половину мы делаем эксклюдит адрес, например, в ЦИСКе. А правый, второй роутер, мы говорим, что наоборот, он будет выдавать только правую половину, а левую выдавать не будут. Да, получится, что IP-шники, которые они будут выдавать разные, и клиент может между этими самыми IP-шниками в итоге, получается, прыгать, если он сегодня финализирует аренду с одним сервером, потом завтра с другим.

Но, тем не менее, по крайней мере, не может быть такого, что адрес, который выдаст один сервер, может быть потенциально выдан быть повторно кому-то другому другим серверам. Вот. В любом случае, что бы вы ни делали, да, вы фактически можете только очень сильно надеяться, что в сети не возникнет какой-то третий сервер, который не будет вообще никоим образом синхронизировать свое поведение с первыми двумя, что он не будет внезапно посылать сообщение, бери IP-шники 192.168.168.1.1, да. Ну, то есть, в атаке от внешних каких-то узлов протоколи DHCP, к сожалению, отбить штатно средствами DHCP самого никак нельзя. Когда-то давным-давно индустрия пыталась придумать, как можно защититься от левых DHCP серверов, и придумала опцию DHCP authentication. Ну, по аналогии с тем самым, как мы проходили там, допустим, в SPF,

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

на которых офферы приходить не должны. То есть смысл заключается в том, что если у нас есть свеч, на нем сидят юзеры. Раз юзер, два юзер, три юзер. Это все юзеры. И у нас есть DHCP сервер, который находится где-то в сети далеко. И, соответственно, сообщение, которое проходит от одного юзера, он начинает кричать «дайте мне адрес», посылает Discover. Discover начинает бежать, бежать, бежать до сервера. Сервер говорит «я хочу предложить IP-шник». Вот такой ответ начинает бежать, бежать, бежать и обратно. И приходит на тот вот узел, который спрашивал про Discover. И тут выясняется, что рядом с ним завелся какой-то умник, который для линдер 300 воткнул. И, соответственно, он тоже прислал оффер на спрашивающего Discover. Но этот оффер дошел существенно быстрее. И пока там тот оффер бежал, клиент уже с этим левым оффером успел финализировать аренду, уже прошел стадии request acknowledge. И получается, что здесь получился адрес вместо 10.00.17. 101.2.168.1.253. И вот такие вот вещи, да.

Защищаться от них можно только сказав, что если у нас есть обычные абонентские порты, то мы подслушиваем DHCP-шные сообщения на них. И мы по какому-то критерию не пропускаем сообщения от клиентов, если они идут с офферами. То есть вот на портах, где сидят обычные абоненты, оффер приходить в принципе не может. Это можно сделать либо с помощью какого-то расширенного механизма, когда вы говорите «давайте подслушивать сообщения, давайте смотреть, что там передается. Мы будем видеть кадры, которые идут на бродкаст. Мы будем видеть внутри IP. IP, которые идут там, допустим, с определенного IP-шника на бродкастовый IP-шник или на какой-то IP-шник. Мы будем внутри видеть UDP-шное вложение, которое будет идти с 68 на 67 порт. Или с 67 на 68. Мы будем видеть внутри тип сообщения boot request или boot reply, в случае с оффером boot reply. И мы дальше будем видеть, что это действительно идет оффер.

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

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

и посмотреть на то, что там внутри будет передаваться. Давайте приступать. Первым делом нам потребуется связь между свитчом и роутером по протоколу IP. Я предлагаю для этого сделать отдельный ВИЛАН, который не будет на свитчах передаваться между свитчами. То есть у нас сейчас все свитчи соединены в большую звезду. И между центральным свитчом и нашими маленькими свитчами есть ранки. Вот чтобы они нам не мешали, я предлагаю сделать отдельный ВИЛАН. Учитывая, что на центральном свитче этого отдельного ВИЛАНа не будет, то, соответственно, все наше взаимодействие будет ограничено одним ВИЛАНом, одним линком между нашим свитчом и нашим роутером. Поэтому делаем новый ВИЛАН. ВИЛАН, допустим, 100 плюс номер комплекта. Вот у меня номер комплекта 8, у вас номер комплекта 1, 2, 3. Поэтому ВИЛАН 108. Можно дать ему название. В моем случае я не буду давать название, я просто выйду.

И вот только в момент выхода ВИЛАН по факту создается. Просмотреть то, что ВИЛАН создается только в момент выхода, можно очень легко. Выполнить в команду do showVILAN чего-нибудь. То есть если вот сейчас, например, сделаю VILAN 110. Вот и сейчас сделаю do showVILAN brief. Это покажет текущие актуальные ВИЛАНы на железке. Вот здесь будет ВИЛАН первый, который дефолтный, который всегда есть. ВИЛАН с 1002 по 1005. И созданный заранее 108 ВИЛАН. 110 ВИЛАНа по факту сейчас нету в базе. Он только создается. Он еще не сброшен на диск. И поэтому создастся он только когда я нажму exit. И вот сейчас do showVILAN brief покажет, что ВИЛАН есть. Вот он создался. Ну да. Ну, ВИЛАН 110. ВИЛАН 110. Он не нужен. Я только для красоты его создал. Мне нужен только 108 ВИЛАН. Дальше. Мне нужно будет интерфейс, которым свитч смотрит на роутер, перевести в этот 108 ВИЛАН.

Интерфейс Ethernet 0.0 у нас между свитчом и роутером. И указываем команду switchport mode access. Switchport access VLAN 108. Что мы фиксируем режим работы на этом порту аксессовой. И фиксируем, что этот порт работает в 108 ВИЛАНе. Все кадры, которые приходят, коммутируются по базе 108 ВИЛАНа. И теперь нам нужен будет ВИЛАНный интерфейс. SWI. Switch Virtual Interface. Interface VLAN 108. Мы создаем виртуальный интерфейс, смотрящий в типа виртуальный коммутатор 108 ВИЛАНа. Он поднимается в выключенном состоянии. Вон он будет включить на ушеддаун. И через некоторое время он у нас заведется. Сейчас он может не завестись, если у вас 108 ВИЛАН в Spanning 3 еще не успел отработать. Ну вот у меня он сразу же завелся. Практически.

Есть порты, которые не заблокированы в Spanning 3. И, соответственно, вот он обнаруживает, что да, живой порт в 108 ВИЛАН смотрящий есть. Все с ним хорошо. Вот этот вот самый интерфейс ВИЛАН 108. Это полноценный нормальный интерфейс. И мы можем сделать связь IP-шную между устройствами, которые принадлежат этому ВИЛАНу. Вешаем IP-адрес. 10. 10. Дальше 0. Номер комплекта, в этом случае 8 комплект. И дальше, ну, допустим, единичка. В принципе, без разницы, какой адрес мы придумаем, учитывая, что все равно эти IP-сети не связаны пока между собой. У нас не курс роут, чтобы связываться между комплектами. У нас все-таки такая отдельная маленькая наша среда. И мы указываем, что у нас на ВИЛАНном интерфейсе висит IP-шник по 24-й маске. 255, 255, 255, 0. На роутере мы уже можем сделать ответные действия. Мы можем сказать, что у нас висит IP-шник, например, 10.0.8.2 и попингать этот самый свитч. Давайте так и сделаем, просто чтобы посмеяться, увидеть, что оно работает.

Enable, ConfT, Interface, Ethernet 0, Drop 0, IP-адрес 10.0, какой там, 8.2, 255, 255, 255, 0. И вот сейчас оно, по идее, должно пингаться. Ну, шаг, кстати. Do ping 10.0.8.1. Вот гипотетически сейчас свитч должен отвечать. Ну, вот видно, да, что пинги проходят. Но если мы хотим воспользоваться все-таки полноценным DHCP сервером, то нам нужно будет на свитче сделать пул адресов, а на роутере нужно будет сказать, что IP-шник у нас не статический 10.0, какой-то там 8.2, а получается как раз по DHCP. Давайте это дело настроим. Идем на свитч. И на свитче указываем, exit, что у нас создается новый пул адресов. IP DHCP Pool, не SHCP.

DHCP Pool и дальше даем какое-нибудь название. Ну, не знаю, VLAN 108. Это название пула, которое нужно просто, чтобы вы сами не запутались, что за адреса вы раздаете. Можно будет его по номеру VLAN назвать, можно будет его назвать по названию отдела. И дальше VLAN тоже назвать по названию отдела. То есть вы можете абсолютно как хотите, так и делайте. Главное, чтобы потом сами не запутались. Создаем пул адресов. В этом пуле у нас будут сети Network 10.0.0.8.0 по маске slash 24. Обратите внимание на пробел. Этот пробел там не случайный, потому что вы можете набрать IP адрес сети, а потом сказать, что либо вы имеете в виду классовую сеть, что очень вряд ли, либо вы имеете в виду slash 24. Это будет указание на префиксную запись сети. Либо вы можете указать десятичную маску 255, 255, 255.0. Понятное дело, что классовую сеть мы использовать не хотим.

255, 255, 255.0 мне писать очень лень, поэтому я пишу slash 24. И теперь, если у нас есть интерфейсы, на которых висят IP-шники, попадающие в эту сетку, то на них DHCP включается и начинает раздавать адреса из этого диапазона. Так. У нас такой интерфейс есть. 10.08.1 висит на VLAN-ном интерфейсе с VLAN-1. И IP-шник на нем 10.08.1. Он, очевидно, вот в этот диапазон попадает. Кроме того, мы можем выдать какие-то дополнительные опции. Ну, здесь можно в пуле раздать много всякого разного интересного. Из того, что джентльменский набор раздается обычно, это default router, это DNS-сервер, это доменное имя, то есть доменный суффикс на самом деле. Вот. Можно раздать... Раздать, раздать, раздать. Да, вот это вот некрофильские вещи про нет-биос сервера.

Винс-сервер, да. Вы можете, если у вас везде используется Windows старый с нет-биосовскими именами, которые используют нет-биосовские имена, то вот вы можете раздать имя нет-биос на им сервера. Маловероятно, что вам это когда-то пригодится, тем более, что сейчас все операционные системы Windows уже максимально широко используют инфраструктуру DNS. Ну, гипотетически, если вдруг вы это увидите, да, знаете, что это для некрофилии. Все, что не попало в списки вот этих вот опций, например, те самые 150-е, 80-е, ну, 82-е не надо сейчас опцию, 150-е опция, там, допустим, NTP-сервер, все это делается через поле Option. Вы указываете, что опцию вы создаете вручную, и указываете там, например, какой NTP-сервер нужно будет использовать. Так, ну, замечательно. Указываем, что у нас есть, ну, допустим, шлюз по умолчанию, Default Router, Epicening 10.081.

И указываем, что у нас есть DNS-сервер. DNS-сервер 10.081. Ну, такой, как уже говорил, джентльменский набор. Дальше. На свитче мы больше ничего не делаем. У нас свитч уже полностью настроен, как ни странно. Все, что нам необходимо, вот все здесь уже есть. Осталось настроить только роутер, сказав, что он должен получать адреса не статически, а по DHCP. No IP address. Убираем статику. И указываем IP address. IP. IP address DHCP. Когда Cisco получает адрес по DHCP, она на консоль выплевывает сообщение, что адрес был получен. Ну, можно это контролировать, просто show IP interface brief заказывать и посмотрев, что, соответственно, там действительно будет наблюдаться какой-то IP-шник. Ну, вот здесь нам случайно так получилось, что у нас на консоли видно такие действительно сообщения,

и пробегает сообщение, что да, адрес был получен. Но если бы мы не получили это сообщение, например, если бы мы по Тилнету подключились, можно было бы заказать do show IP interface brief. Ну, или даже в явном виде сказать 0.0 интерфейс нас интересует. И вот он. Адрес 10.082 получен по DHCP. Так. Этот адрес есть, и мы с этим адресом можем уже дальше работать. Вот. Ну, если вдруг мы захотим посмотреть на сервере, что в итоге получилось, вот на свече. Выходим из конфига и смотрим, что у нас получается. show IP DHCP pool. Вот у нас есть пул с нашим названием. У нас есть IP-шники, которые мы в этом пуле держим. С 10.081 по 10.08254. Из этого диапазона автоматом вычитается IP-шник самого роутера. Он понимает, что свой собственный IP-шник выдавать не надо.

Он говорит, что выдан сейчас один адрес. И, соответственно, вот он лежит. Я загадываюсь, что это 10.082, который получил наш роутер. И следующий адрес, который будет выдаваться, это 10.083. Дальше. Если вдруг мы захотим посмотреть, какие именно адреса были выданы. show IP DHCP binding. Покажет нам, что адрес был выдан. 10.082. Время, когда эта аренда закончится, судя по всему, завтра, через сутки. Кстати, да, вот надо время аренды указывать. Я забыл про это. Время аренды указывается, опять же, в настройках пула. Вот в параметре lease. Адрес lease time. То есть вы указываете там время, сколько дней, сколько часов, сколько минут, сколько секунд вы хотите выдавать адреса. По умолчанию на сутки. И это такое, ни нашим, ни вашим.

Для быстрых сетей, типа всяких там кафе и прочих гостевых сетей, это многовато. Для корпоративных сетей это решительно маловато. Поэтому вы определенно захотите время аренды поменять. Ну и, наконец, может быть ситуация, при которой мы захотим сделать так, чтобы у нас вот этому клиенту, нашему роутеру, выдавался адрес не 10.082, а какой-нибудь конкретный и желательно всегда одинаковый. Поэтому мы можем сделать статическую запись для этого адреса. Conf.t. Дальше. IP, DHCP, Pool. Как он назывался? LAN.108. Вот так вот. Главное не ошибиться с названием. И мы хотим сказать, что адреса, которые мы выдаем, они будут по-прежнему случайны, но вот именно для этого узла мы будем выдавать адрес вполне конкретный. Можно это сделать по-новому, можно это сделать по-старому. Если я сделаю это по-новому, я укажу адрес. Дальше указываю IP-шник. 10.082.

Дальше указываю. Мне надо каким-то образом его идентифицировать. Либо я могу по Client ID вот этот вот Client ID указать. Либо я могу Hardware Address Mac его посмотреть. Если я знаю его Mac, то я могу заранее его прописать. Понятное дело, что Mac-адрес, оно как-то чуточку более надежно. Но Mac-адрес, да, если вы его знаете, то хорошо. В моем случае я могу легко достаточно Mac-адрес посмотреть. Ну, или можно будет просто попытаться угадать, какой он есть, потому что в Client ID он так или иначе кодируется тоже. Ну, или можно, да, Client ID указать. Client ID. 1, 2, 3, 4. Так, да, система говорит, что этот адрес пока уже выдан. То есть у нас есть в списке занятых адресов уже запись 10.082, и нельзя сделать статическое резервирование для этого адреса.

Но при этом do show run include DHCP. Да, запись эта не создалась. Только не DHCP, а адрес. Да, запись эта не создалась. Если мы хотим сделать так, чтобы у нас создалась новая запись на IPшник, который мы уже выдали, то мы должны будем эту самую привязку стереть. Это будет команда clear, IP DHCP binding. И дальше указываем, какую запись мы хотим стереть. 10.082. Вот сейчас у нас нет указания, что мы выдавали адрес 10.082. Вот эта вот строчка, она пропала. И поэтому мы можем сделать новое резервирование, сказав, что именно этому узлу мы всегда будем выдавать IPшник 10.082. IP DHCP pool VLAN 108. Давайте не 10.082 выдадим, а 10.08.254.

Вот, я просто повторил эту строчку. Адрес 10.08.254, client ID какой-то там. Вот этот вот самый client ID, который здесь есть. И для того, чтобы роутер переповторил эту запись, нужно будет отбросить, выключить интерфейс и включить его заново. Но перед этим я хочу поставить время аренды поменьше. Lease. Указываю 0 дней, 0 часов, 1 минута. И, соответственно, смотрим на то, что у нас получается в итоге. Shutdown на роутере. Ну, shutdown. Так, интерфейс упал, поднялся. Адрес заново мы переполучаем. И мы видим как раз 10.08.254. Действительно, все честно, адрес выдался именно нашему роутеру, как мы и просили. Теперь, если у нас будет необходимость выдать адрес роутеру,

он всегда будет 10.08.254, потому что у нас есть статическая привязка к нему. Очень удобная вещь. Если вы прописываете адреса, то прописываете вот эти вот самые резервированные адреса прямо в самом пуле. Do show run section DHCP. То есть вот у нас наш пул. И указывается, что у нас есть статическое резервирование. 10.08.254 выдается именно вот этому клиенту. Если вдруг вы хотите воспользоваться другим способом, более, скажем, назовем это старым, то вы должны будете сделать отдельный пул. То есть IP DHCP pool R08. То есть делаете отдельный пул с названием клиента. Прописываете команду host и дальше указываете IP-шник хоста 10.08.253. Указываете маску его, которую вы будете выдавать 255.255.255.0.

И дальше указываете, как конкретно этот пул будет определять конкретного клиента. Ну, указываете либо client identifier, либо client name, либо hardware address. То есть вы можете, например, сказать, что если вы хотите определять клиента по client name, что он приходит и говорит, меня зовут R08. Тогда вы действительно должны будете сделать старый способ выдавать статическую запись по отдельному пулу, в который будет указан вот этот самый client name. Но если вам достаточно использовать MAC адреса или client ID, которые на самом деле в себе будут содержать название железки, то вы можете использовать hardware address. Так, не hardware address, а client ID. И, соответственно, сделать адрес прямо в пуле. Так, видно, что у нас есть вот этот вот самый сервер, который выдает адреса. Видно, что он показывает, какие IP-шники он выдал, как используется каждый пул.

И еще есть клиент, router R08 в моем случае, у которого есть тоже кусочек команд, которые имеют отношение к DHCP. show, если мне память не изменяет, IP, интерфейс, E00. Нет, сейчас соображу. show IP. Так. Сейчас вылетел из головы. Секундочку. Show. Interface. E00. Сейчас где-то можно свойства DHCP клиента посмотреть. Я все время забываю, где это происходит.

Вспомните. Если вдруг вы знаете, подскажите мне, потому что я сейчас буду долго тупить. Show IP. Так. Так, так, так, так, так, так. Я 0. 0. Нет. Что-то не вспоминается. А вот. Да. Show DHCP list. В IPv6 есть отдельная команда, которая покажет свойства клиента.

Здесь есть только просмотр того, что вы получили. Вам показывается, что есть временный IPшник 10.08.254. Вы получили его на интерфейсе Ethernet.00. Маска, которую вам выдали 255.255.255.0. Кто выдал 10.08.1. Оно же выдало шлюз по умолчанию. Default gateway 10.08.1. И оно же, на самом деле, выдало вам DNS сервер. Но здесь его почему-то не показывает. Показывается, какой у вас client ID. То есть вот это вот client ID. Если вдруг вы хотите посмотреть, с каким client ID вы будете бежать на сервер, то вы можете взять и вот эту вот самую штуку скопипастить. Вот. И, соответственно... А, во-во-во-во. Видите, client ID в текстовом виде Cisco. Дальше тот самый знак припинания, который я не вспомнил. Что это за знак припинания? Думал, двоеточие. Это, оказывается, минус. Дальше MAC адрес. Дальше снова минус. И название интерфейса. Ethernet 0.0. Ну, окей.

Вот. И вот эта вот строчка в виде 16-ричного дампа, где используется кодировка ASCII. То есть 63 буква C. 69 – это буква I. 73 – буква S. 63 – снова буква C. 6F – это буква O. 2D – это вот как раз тот самый знак припинания. 6,1, 6,1, 6,2, 6,2, 2E. Ну, это все буковки. 6,1 – буква A. 6,2 – это буква B. 2E – это точка, как уже говорилось. То есть это вот тупо MAC адрес. И, наконец, 31, 30, 30, 30 – это число 1000. Дальше 2D – тот самый минусик. И вот эта вот штука – это закодированная строчка E. 0,0. 45 – большая буква E. 74 – маленькая T. 30 – 0. 2F. Дробь. 3,0. Опять нолик. Вот, собственно говоря, так оно и работает.

И выдаются у нас адрес на 60 секунд. Мы можем управлять временем T. И действительно, в настройке пула у нас стоит, что адреса выдаются на 1 минуту. И стоит указание, что через 30 секунд после начала работы надо пытаться выполнить продление аренды. И если у нас не получится сделать это за 49 секунд, то есть спустя 50 секунд, спустя 49 секунд после начала аренды, мы должны зарать на всю Ивановскую, бродкастом. Мужики, продлите адрес, пожалуйста. То есть renewal time – это время T1. Rebind time – это время T2. Т2, спустя которого вы начинаете бродкастом орать на всю сеть. Вот. Это DHCP в CISC, в IPv4. Если вы работаете с DHCP на distribution switch, то вот вы на каждой VLAN должны будете сделать отдельный пул и прописать указание, что конкретный пул будет работать с конкретной IP-сетью.

Либо же вы прописываете IP helper address. У нас нет сейчас такого сервера, куда можно было бы переслать все, поэтому LaboNet делать бессмысленно. Там всего одна команда IP help address и все, больше ничего нет. Так, давайте поговорим теперь про CISC, про то, как защититься от левых DHCP серверов. Так. Вы можете заставить ваши свитчи подслушивать DHCP сообщения. Как уже говорилось, это фича не просто про то, что можно смотреть на номера портов, а именно смотреть содержимое DHCP. И в зависимости от того, что вы будете там видеть, вы можете на это дело как-то реагировать. Самая очевидная причина, что можно с этим делать, это недоверенные офферы и недоверенные акноуледжи отбрасывать. Ну, просто по принципу, что они оттуда не должны приходить. Если у вас есть какая-то реальная сеть, вот, допустим, ваш свитч доступа Access 1, у вас другой свитч доступа Access 2. Зачем-то здесь еще связь между ними есть, ну ладно, пусть будет.

И, соответственно, вот distribution switch. Distribution 1, Distribution 2. И вот они, по идее, должны, конечно, вот так вот треугольниками друг на друга смотреть. Ну, не суть важна, как ты друг на друга смотрит. У нас есть некий компьютер, который хочет получить адрес, он отправляет запрос «discover». И этот запрос начинает разбегаться по всей сетью. Бежит, бежит, бежит, бежит, бежит, бежит, бежит на сервер. Сервер говорит «Окей, я посылаю оффер». Оффер бежит, бежит, бежит, бежит, бежит, бежит на жертву. И, соответственно, оффер приходит на жертву. Но равным образом этот discover бежит на всю сеть. И, соответственно, рядом с жертвой где-то может сидеть атакующий. Может быть, он умышленно будет атаковать. Может быть, он неумышленно просто взял и воткнул случайно железку или просто включил случайно DHCP сервер, и так случилось, что он будет рядышком находиться. И вот атакующий тоже посылает оффер. И этот оффер проходит существенно меньшее расстояние, и, соответственно, до жертвы приходит существенно быстрее. Если жертва получает два оффера, она выбирает первый, который пришел. То есть он пришел первый, она сразу начинает на него реагировать.

И, соответственно, вот второй оффер, который приходит, настоящий, он уже приходит вторым, и он не выбирается, потому что жертва, как только получила первый оффер от атакующего, она сразу начинает посылать реквест. И вот она посылает реквест на него, и, соответственно, получает окно, что давай пользуйся своим айпишником, который у нас там есть. Что можно сделать в этой ситуации? Можно на каждом порту сказать, мы доверяем на этом порту офферам и акноуледжам, или мы не доверяем на этом порту офферам и акноуледжам. Понятное дело, что из-под пользовательских портов у вас вполне штатно могут приходить реквесты и дискаверы. То есть их подслушивать, конечно, можно, но бесполезно, там ничего интересного все равно не передается. А вот, соответственно, оффер и акноуледжа – это достаточно такая криминальная вещь, и надо на портах абонентских внимательно следить за тем, что у нас там происходит. Если вот мы смотрим на абонентские порты, подслушиваем, что там передается, и видим, что там передается оффер или акноуледжа, мы говорим, мы такие кадры отбрасываем.

Но если мы видим, что на других каких-то портах приходит к нам оффер или акноуледж, и он передается, этот оффер или акноуледж, на определенный порт, мы можем записать, мы же все все равно анализируем, мы можем записать, какие именно офферы прошли на этот порт, и какие именно акноуледжа прошли на этот порт. И, соответственно, вы будете строить табличку соответствия MAC-адресов, IP-шников, VLAN-ов и портов. И вы будете знать, какой оффер, куда вы посылали. Помимо того, что вы можете отбрасывать левые кадры, вот эту вот самую табличку можно будет использовать для всяких клевых нужд. Смотрите, что здесь будет настраиваться. Если мы включаем подслушивание DHCP, то включается это, во-первых, глобально на свече команды IP DHCP-снупинг. Механизм достаточно затратный, поэтому вы по умолчанию его не будете использовать. Если вы хотите его использовать, вы его включаете, но, естественно, предполагается, что свитч доступа у вас при этом не загружен в какую-то там стопроцентную нагрузку.

Потому что если вы включаете эту штуку, она вносит определенную задержку в транзитные кадры, и, соответственно, у вас начнут теряться кадры, которые просто не получат достаточное количество процессорного времени. Дальше. По умолчанию, даже если вы включили движок снупинга, он ничего не снупит. Вы должны будете сказать, что снупинг включается отдельно на виланах. То есть трафик, который проходит через какой-то вилан, он будет снупиться. Вторая команда — это говорим, что не просто мы сам движок включили, а включаем механизм подслушивания трафика в определенных виланах. Виланы 10-е и 20-е. Вот. И, соответственно, когда у нас идет подслушивание в этих двух виланах, весь трафик, который проходит через эти виланы, мы анализируем, похож он на DHCP-шный или нет. Если мы видим офферы или аккноледжа, смотрим, откуда они пришли. На некоторых портах мы должны будем сказать, что если кадр пришел из-под этого порта, мы его отбрасываем совсем. А на некоторых других портах, если мы видим, что кадр пришел из-под порта, где мы его не выбрасываем, мы должны будем запомнить, куда он ушел и что там было написано.

И для этого вы должны будете на тех портах, которые доверенные, которые правильные, хорошие, сказать команду IP DHCP-SNOOPING-TRUST. По умолчанию все порты не доверены, ни на каких портах вы не включаете отправку офферов или аккноледжей. Поэтому сначала на самом деле имеет смысл включить IP DHCP-SNOOPING-TRUST и только потом включать сам snooping. Потому что если вы, допустим, включите сначала snooping и забудете прописать snooping-trust, то у вас весь DHCP в сети поломается. Указывайте на портах, на которых у вас реально могут приходить офферы, команду IP DHCP-SNOOPING-TRUST. Это уже полдела. Дальше вы можете сказать, что вы начинаете вести базу, кто за каким портом сидит. И эта база на самом деле очень ценная. Потому что если вы, основываясь на нее, будете какие-то дальнейшие действия предпринимать, например, будете отбрасывать кадры, которые приходят из-под неправильных IP-шников, потому что у вас же есть указание, кто за каким IP-шником будет сидеть,

это все в базе будет написано. Вот если вы эту базу будете хранить в оперативке и вы перезагрузитесь, то узел, который получил IP-шник, он же его уже получил. Он же штатно посылает IP-пакеты с этого адреса. Вот вам имеет смысл базу DHCP, базу подслушивания DHCP, в нашем случае на свече, хранить на флешке. Она, конечно, будет часто изменяться. И может такое быть, что у вас эта флешка очень быстро убьется, но тем не менее это вполне имеет смысл, если вы снупинг включаете. Если вы знаете, что ваш свитч может перезагрузиться, то вы должны будете сказать, что складываем базу в какое-то комплектное место. По умолчанию она хранится в оперативке. Использовать на компакт-флеш хорошая идея. Проблема в том, что если взять вот здесь какой-нибудь 2960, снупинг на нем есть, а флешки у него только встроены. Компакт-флеша у него нет. Поэтому здесь надо очень хорошо подумать, что вы можете сделать.

Либо сложить на флешку и почти гарантированно убить флешку через несколько лет, либо вы можете сказать, что свитч у нас перезагружается крайне редко, оптаймы там годами идут. Если вдруг свитч даже перезагрузится, ну типа хрен бы с ним, и все равно рано или поздно продлим аренду. До того момента, как аренда будет продлена, соответственно, у нас трафик от абонентов ходить не будет. Ну, в общем, тут надо будет аккуратно подумать. Скорее всего, вы захотите включить хранение данных на флешке. Дальше. На портах, которые доверены, вы указываете, что это порты доверены. Можно ли загружать на сеть? Кстати, хороший вопрос. Честно говоря, не знаю. Обычно рекомендуют на флешку сбрасывать. А вот по поводу типа куда-нибудь на FTP складывать, не знаю. Интересная мысль. Нет ли там какого-то механизма инкрементального обновления?

Нет, к сожалению, нет. То есть там целиком файл. Как правило, он не очень большой. То есть там подслушивается не так много. Но все равно записи происходят. Так. Если базу DHCP бейдингов можно сбрасывать, то, скорее всего, эту штуку тоже можно. То есть они обычно рядышком лежат. И база того, что в DHCP выдана, и база того, что подслушана на свечах. Это все как бы один и тот же механизм. Так что, скорее всего, можно ее тоже выгрузить на какой-то внешний сервер. Так. Да. На доверенных портах вы указываете, что они доверенные. На недоверенных портах вы ничего не указываете. И тем самым даете указание, что они недоверенные. Здесь есть еще одна команда IP DHCP Snooping Limit. Это очень полезная вещь. И она защищает от другой атаки. Знаете, какая атака? Не то, что кто-то левый вбросит вам DHCP-шные сообщения. А то, что есть у вас вот настоящий DHCP-сервер. Хороший, легальный.

Который раздает сетку. Там, допустим, 10.001-24. У него IP-шник висит. Раздает сетку 10.00. И дальше атакующие начинают говорить. Дайте адрес. И вы ему говорите, ну я тебе выдаю адрес 10.002. А потом он снова говорит, дайте адрес. Только другой. И вы ему говорите, ну да, 10.003. И дальше вот он начинает вас бомбардировать запросами. Дай адрес, дай адрес, дай адрес, дай адрес. И у вас вся вот эта вот сетка, она очень быстро заканчивается. Вы можете указать, с какой частотой можно запрашивать сообщения. И команда IP DHCP Snooping Limit Rate, в нашем случае 10, скажет, что не больше 10 сообщений в секунду можно будет посылать. То есть если вдруг атакующий будет посылать сообщения реже, чем 10 раз в секунду, то типа все в порядке. Понятное дело, что хороший грамотный атакующий, он все равно сможет найти способ сделать так, чтобы отправлять там 9 сообщений в секунду. То есть сначала 9, потом еще 9, потом еще 9.

И тем самым избежать этого ограничения. Но все-таки если у вас сработает вот этот вот самый DHCP Snooping, и у вас будет отброшен какой-то запрос, все равно вам позволит это немножко сохранить работоспособность. Вы же это можете увидеть в логах, вы можете это увидеть в Syslog, например, в том же самом. Если у вас на Syslog приходит сообщение, что вас пытаются по Rate Limit кто-то поломать, ну вы на это как-то можете отреагировать заранее, проактивно. Это, как правило, очень редко происходит внезапно само по себе. Ну да, то есть там, как правило, это все сопровождается какими-то другими факторами. Можно будет посмотреть, чего ваш свитч нащупал. Команда show ipdhcp-snooping покажет, во-первых, где snooping включен, во-вторых, где настроен вот этот вот самый Rate Limiter. В нашем случае на Gigabit 0.0 лимитер стоит десятка, и вот на FastCethernet 0.1 тоже стоит Rate Limit десятка. Gigabit 0.0 у нас Trusted порт, FastCethernet 0.1 – Untrust.

Ну и 82-я опция. Здесь вот показано, что она доверенная, здесь недоверенная. Ну, 82-я опция нам сейчас не нужна. Так. Да, можно посмотреть содержимое, не содержимое, а, скажем, информацию про базу данных снопинга, насколько она живая, насколько она хорошая. Учитывая, что это механизм, на котором будут основаны многие другие штуки, связанные с безопасностью, в общем, здоровье базы будет интересоваться очень сильно. Команда showip.http.snupping.database покажет, сколько, соответственно, у нас, сколько попыток было записи в эту базу, и были ли какие-то проблемы с этой базой. То есть, если у нас есть какие-то failed reads, failed writes, повод задуматься на тему того, что флешку вы-таки добили до конца, и пора уже что-то с этим делать. Ну, если мы видим, что в нашем случае вот мы один раз записали на флешку указание,

да, что у нас какой-то новый IP-шник проявился, ну, значит, скорее всего, здесь база у нас не просто хорошо себя чувствует, она еще и практически пустая. Там всего один адрес. Можно будет посмотреть showip.http.snupping.statistics. Покажет оно, сколько пакетов пришло на недоверенных портах, и мы их отбросили. То есть, сколько пакетов отброшено всего, и сколько из них не отброшено, потому что они пришли на нотрастен портах. В эту цифру включается также rate limited. И, соответственно, первая цифра – это сколько пакетов DHCP мы нормально обработали. Вот эта вот статистика вас спасет, конечно же, от… Не спасет, а позволит вам понять, что у вас где-то случился rate limit. Ну, и showip.http.snupping.binding покажет содержимое базы. Вот нам тут обещали, что одна запись прошла в базу. Вот она и есть. Указывается, какой MAC-адрес, какой IP-шник, на каком порту, в каком Вилане получил привязку. Насколько времени выдано?

Ну, 86400 явно оригинальное значение было. Это одни сутки. И тип записи DHCP-снуpping показывает, что мы узнали, что адрес 10.002 был получен MAC-адресом AABB-CC002010 на интерфейсе FastZernet02. Вот эту вот базу дальше можно будет использовать, например, для того, чтобы смотреть, какие IP-шники источника в пакетах идут, какие MAC-адреса источники в пакетах идут. Ну, соответственно, если мы видим, что у нас адрес 10.002 зафиксирован за FastZernet02, то на каком другом порту мы этот адрес, например, разрешать уже, может, не захотим. Такие вот вещи, они, конечно, очень сильно позволяют дальше продвинуться в части безопасности, сказав, какой трафик у вас хороший и какой трафик у вас плохой. Если кто-то попросил IP-шник, получил IP-шник и дальше с этим IP-шником он может работать, то, соответственно, вот вы можете легко и непринужденно, если он начинает подменять IP-шник, если он начинает подменять MAC-и, отследить этот процесс и прибить такие пакеты.

Ну и заодно насрать влог, и дальше у вас на сит-логе пробежит какое-то красное сообщение, администратор увидит это, пойдет разогревать паяльник и жаловаться в КГБ. Так, это вот что касается DHCP V4. Вы можете включить снопинг, вы можете включить все механизмы, которые на этот снопинг будут завязаны, они у нас чуть дальше будут, и вы можете, ну, собственно говоря, сам DHCP включить, это в обязательном порядке вы, наверное, должны сделать. Я вам настоятельно рекомендую включать DHCP снопинг, может быть, не на уровне введения базы, но на уровне хотя бы отслеживания, на каких портах могут приходить DHCP-шные сообщения, на каких нет. Потому что у меня был опыт трэблшутинга сети, в которой был левый DHCP-сервер. И я вам скажу, на свечах, которые не поддерживают всякие вот эти вот продвинутые вещи, отслеживать такое, это очень тяжело. То есть у вас просто начинают появляться какие-то левые адреса внезапно, ни за ниоткуда.

И дальше отследить, кто на каком порту, куда, зачем, почему начинают отдавать эти IP-шники, ну, удовольствие ниже среднего. Поэтому, если есть возможность от такой атаки защититься, это стоит сделать. Тем более, что атака очень популярная, и, как я уже сказал, да, не обязательно она вызвана злым умыслом. Она может быть вполне вызвана тем, что просто кто-то по незнанию взял, притащил какую-то железку из дома. В IPv6 у нас DHCP тоже есть. Он, как я уже говорил, немножко отличается от DHCP в IPv4 тем, что это не допиленный до ума bootpy классовый, а прям совсем отдельный протокол. Тем не менее, задачу он решает точно те же. У него точно также есть сообщение «Мужики, дайте адрес». «Хочешь, на тебе вот такой». Я согласен. Я тоже согласен. То есть, это Dora, которая была в IPv4. Только сообщения там будут немножко по-другому называться. Но смысл этих сообщений будет тот же самый. Если вы хотите получить адрес, то вы можете это сделать.

Вы покричите на всю сеть, дайте адрес, и адрес вам дадут. Но, учитывая, что в IPv6 есть стейтлес адрес авто конфигурэйшн, задачи у DHCPv6 основной все-таки будет не раздача адресов. В IPv4 у нас без DHCP было очень сложно жить, потому что автоматического механизма настройки узлов не было. В IPv6 есть штатный механизм слаг, который позволяет узлам генерировать столько IP-шников, сколько им будет потребно. Если им хочется миллиард IP-шников, не проблема, слаг им сделает миллиард. Но, соответственно, эти IP-шники самостоятельной ценности особо не имеют. Если, допустим, с помощью механизма Neighbor Discovery или Router Advertisement можно раздать указание, что там роутер будет шлюзом, то DNS вы так не раздадите. DNS тоже можно там, правда, в Router Advertisement впихнуть, но только Windows, например, вот читать не умеет эту опцию DNS сервера. Если вы хотите, например, NTP сервер раздать, то это вообще в Router Advertisement сделать не получится никак.

Но поэтому DHCP v6 все равно нужен в сетях с IPv6, но у него основная будет задача не раздать IP-шники, а раздать именно опции. Соответственно, у нас будет два режима работы. Один режим работы, при котором адреса раздаются так же, как в IPv4, это будет у нас режим Stateful. Мы раздаем адреса, мы запоминаем, кому чего раздали, ведем базу, бла-бла-бла. То есть Stateful — это с отслеживанием состояния. Вот мы по каждому адресу можем отчитаться. Он свободен, он занят. Если занят, то когда освободится и так далее. И Stateless нам все равно, какие адреса в сети используются. Мы выдаем только опции, они все одинаковые. И к нам кто-то приходит, мы ему выдаем опции. Неважно, приходил он пять минут назад или нет. Мы, если он через пять минут придет, мы точно те же самые опции дадим. Если Вася придет, мы ему опции дадим. Если Петя придет, мы ему опции дадим. Если Коля придет, мы ему эти опции дадим. Если Сережа придет, эти опции попросит. Мы ему все равно те же самые опции дадим. То есть это режим без отслеживания состояния. И он, соответственно, существенно проще.

Вместо бродкаста будет использоваться мультикаст. Естественно, что в IPv6 бродкаста нет. У нас есть специальные отдельные мультикастовые адреса. FF02.2.1.2. Это все серверы и агенты в сети. То есть вы, если хотите нащупать адрес соседа, то вы используете FF02.2.1.2.2. По определению области действия этого мультикаста в адресе все узлы в вашем широкомощательном домене. Есть адрес FF05.2.1.2.3. Область действия этого мультикаста в адресе – это предприятие. Вот на это пятерка указывает. То есть это маршрутизируемый мультикаст. Если у вас настроена маршрутизация мультикаста, то вы можете запросы на DHCP сервера, все DHCP сервера в предприятии маршрутизировать. Если вдруг кому-то понадобится получить какой-то адрес или опции

с любого доступного сервера, не обязательно тот, который с ним в одной сети находится, то вы можете это сделать. Учитывая, что это не вложение в BootP, используются другие UDP-шные порты, потому что 67 и 68 – это все-таки BootP-шные, BootP-клиент, BootP-сервер. Здесь у нас получается другой протокол, и порты тоже будут другие – 546 и 547. Но точно так же логика будет та же самая, что вы отправляете запрос из-под своего порта на порт другого. То есть если вы клиент, то вы из-под 546 порта посылаете на 547. Да, по поводу Stateful и Stateless уже все рассказал. Stateful с отслеживанием состояния. Слово State – это состояние. Значит, Stateful – значит, с отслеживанием состояния, с сохранением состояния клиентов. Мы отслеживаем, что мы делаем. Stateless DHCP – это без отслеживания состояния. Мы выдаем всегда всем все одинаковое. Мы не отслеживаем, кто к нам с чем, зачем.

И поэтому всем одинаково отдаем все одинаковые настройки. В DHCP v6 сообщения будут называться немножко по-другому. Не так, как в IPv4 DHCP. То есть то сообщение, которое называлось Discover, в IPv6 называется Solicit. И, соответственно, то сообщение, которое называлось Offer, оно называется Advertise. То есть вместо Discover и Offer у нас Solicit и Advertise. Request остался реквестом. Там ничего интересного нет. Вместо Acknowledge в IPv6 DHCP, в DHCP v6, используется сообщение Reply. То есть ты, типа, послал сообщение Request, я тебе на него отвечаю Reply. Это более разумно, потому что, ну да, если какой-то реквест у нас есть, какой смысл Acknowledge-ить реквест? Никакого нет. Так что это сообщение будет называться более правильно, более логично. Там же есть Information Request. Если вы запрашиваете только опции, то вы можете не полноценный реквест посылать, а только вот 11 тип, это Information Request,

типа, дай опции, которые нужны для работы в этой сети. Реквест – это целиком IPшник, а Information Request – это только опция. Там же есть, на самом деле, много всяких других кодов сообщений. Ну, то есть, например, есть сообщение Release, так же, как в IPv4. Есть сообщение Decline, что клиент попросил IPшник, ему дали какой-то IPшник, а клиент его использовать не смог. Он с помощью алгоритма Duplicate Address Detection потестировал этот адрес и убедился, что он занят. Причем занят не им, естественно. В этом случае он посылает сообщение Decline. Ты попытался дать мне адрес Reply, а я не хочу его брать, потому что он уже кем-то используется. Ну, в общем, да. Вам не будет нужно на экзамене помнить все эти типы сообщений, но на экзамене нужно будет помнить, что вместо DOR у нас используется Solicit Advertise Request Reply. Названия эти будут нужны. Да. В IPv4 и в IPv6 DHCP

есть штука, которая называется Rapid Commit. Эта штука будет полезна в ситуации, когда у вас всего один сервер в норме отвечает на запросы. И эта штука будет работать следующим образом. У вас есть клиент, и, соответственно, этот клиент орет на всю сеть. Дайте адрес. Если вы хотите использовать короткую схему, то вы можете не использовать всю схему DOR или Solicit Advertise Request Reply в IPv6. Вы можете использовать только два сообщения Solicit и, соответственно, сразу Reply в ответ на него. Rapid Commit, она позволяет избавиться от промежуточных сообщений «Хочешь вот такой IPшник?» И ответа «Хочу такой IPшник». То есть клиент говорит «Дайте какой-нибудь адрес». И сервер говорит «На тебе какой-нибудь адрес». Все, точка. Просто используй его и все. В IPv4 эту схему мало кто поддерживает, потому что там может быть такое, что у вас есть несколько серверов, вам нужно будет, чтобы сервера,

которые, возможно, одновременно с основным сервером тоже выдали адрес, чтобы они этот адрес пометили как освобожденный, то есть там нехорошо будет, если у нас постоянно будут висеть записи в базе, что вы какой-то адрес кому-то предложили, а он не сказал, что на самом деле какой-то адрес там принимает или не принимает. В IPv4 эта схема Rapid Commit, она есть, но она не очень популярная. В IPv6, ну, предложил другой сервер IPшник, ну, не узнал он, что клиент отказался от этого IPшника, ну и что? Ну, пусть у него повисит в базе это все. Он все равно не позже, чем через некоторое время освободит эту строчку. Ну, ничего страшного. Поэтому, если будет у вас 10 DHCP серверов, и все 10 в ответ на Solicit будут предлагать свои Advertiser, ну, не Advertiser, там, Reply они отправят, да, с Rapid Commit, какой из них клиент выберет, заранее неизвестно. Ну, какой бы он не выбрал, но он выбирает их, там, допустим, на один месяц. Вот через месяц он снова придет, дайте адрес, скажет, и через месяц все сервера, которые старые

Advertiser посылали, они их сбросят в любом случае. Поэтому в IPv6 задачи экономить адреса нету, адресов очень много, достаточно для любых задач, поэтому то, что там вы пару тысяч или пару десятков тысяч адресов зарезервируете по всякие бесполезные вещи, ну, в принципе, никто от этого особо не расстроится. То есть вы выкидываете Advertiser и Request, а ниже Offer и Request, и оставляете только Solicit и Reply, а ниже Discover и Acknowledge. Тем самым вы немножко сокращаете время, которое требуется на аренду адреса. То есть выкидывая два сообщения, ну, да, у вас на несколько десятков миллисекунд клиент получит адрес быстрее. Так, если вы хотите настроить DHCP v6 в CISC, то вы можете это сделать в любом режиме, который вы захотите. Хотите сделать Stateless, хотите сделать Stateful,

вот, ну, если Stateless, все просто. Вы делаете Pool, указываете, что у вас есть Pool с каким-то названием, даете там опции, в нашем случае, вот DNS-сервер, гугловый DNS, доминный имя какое-то мы делаем, и дальше на интерфейсе прописываем, что у нас, во-первых, работает Slack, то есть мы на себя вешаем IP-шник, и если у нас включен IPv6 Unicast routing, то наличие маршрутизируемого IP-шника на интерфейсе сразу начинает отсылать connected prefix в виде рашек, в prefix information. Вот в нашем случае мы видим IPv6 адрес 2001 DB8 B1 6 B5 2 2 1 Вот эта вот штука 2001 DB8 B1 6 B5 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 3 2 2 2 2 3 2 2 2 2 2 2 2

2 2 2 3 2 3 4 4 4 4 4 4 5 5 5 5 6 6 6 6 6 7 7 8 8 9 9 9 9 10 9 10 10 10 10 11 11 11 12 12 12 12 13 14 14 14 14 14 14 14 14 14 14 15 15 15 16 15 16 15

15 16 16 15 15 16 16 16 21 18 22 21 21 22 21 22 22 стать дефолт роутером вот ну и соответственно да после того как вы это сделали у вас где чтепи клиент начинает работать получает ip-адрес вот show ipv6 интерфейс gigabit 00 покажет что у вас настроен действительно global unique астовый адрес на этом интерфейсе он прислался по слаку вот 2001 db8 b16 bb5 префикс который нам прислали в рашки и вот эта вот штука это у нас интерфейс айди который мы сами придумали по и вы 64 откуда я знаю что по ее 64 а вот она call

указывать на то что у этого адреса есть какой-то срок жизни то есть мы его не на совсем придумали мы будем им пользоваться только ограниченное время и если вдруг и рашки будут приходить дальше то мы будем постепенно это время продлять и продлять и продлять но если вдруг рашки перестанут приходить то в течение некоторого времени мы этим адресом все еще будем пользоваться а потом перестанем по умолчанию prefered lifetime это время в течение которого адреса можно пользоваться без ограничений включая и установление новых сессий из-под этого адреса это неделя то есть вот 660 604 184 секунды это приблизительно одна неделя и соответственно 2 миллиона пятьсот девяносто на тысяча триста восемьдесят четыре это приблизительно один месяц чуть чуть больше чем в четыре раза больше чем 600 тысяч велит lifetime это значит что вы можете этим адресом пользоваться но только для сессий которые были установлены с использованием этого адреса то есть новые сессии устанавливать нельзя новые юзю пишные данного грамма целать нельзя для

приложения которые новые запущены и так далее и при означает что текущее состояние этого адреса это prefered он прямо сейчас вполне разумный вполне можно будет пользоваться так дальше шоу ipv6 dhcp интерфейс вот как раз опция которой в ipv4 нету это вы можете посмотреть состояние dhcp клиента на интерфейсе и вот здесь показано что у нас действительно есть на гигабитном нулевом интерфейсе клиент дэйси пи прямо сейчас префикс на этом интерфейсе получен по slacka и мы не запрашиваем адреса по дичьи пи никоим образом то есть idle значит мы не просим не запрашиваем префиксы на дичьи пи сервера мы не запрашиваем адреса мне запрашиваем префиксы мы запрашиваем только опции если бы что если вдруг мы захотели мы могли сказать а ну-ка сервер придумай нам ip-шник или а ну-ка сервер придумай нам пачку префиксов чтобы мы их дальше раздавали нашим

клиентам но ничего этого мы не просили мы просто сказали дай опции и все и поэтому нам показали что у нас есть сервер вот такой вот который услышал наш мультикаст и ответил нам своим link local адресом пожалуйста забирай вот твои опции соответственно dns сервер вот такой доменное имя опция вот такая rapid commit у нас не используется ни для префиксов не для адресов то есть мы послали сообщение информ и получили на него сразу reply так далее если бы у нас был стейтфол джи цепи на на джи цепи серверы настройка на самом деле очень похожи то есть мы точно так же создаем пул мы точно также даем какие-то опции но мы добавляем вот эту вот штуку адрес префикс чего-то там адрес префикс указывает на то из какой сети будут генерироваться адреса это

аналог network и дальше мы указываем лайф таймы для этих адресов в джи цепи у нас как вы помните лайф таймы есть это первый лайф тайм это в течение как какого срока адрес можно будет использовать и соответственно в айпи в четвертом джи цепи этого было достаточно для джи цепи и пиве 6 мы выдаем два времени это infinite время в течение которого адрес вообще можно использовать и 8 6 400 это время при фирме то есть течение которого адрес можно использовать без ограничений вот ну чаще всего вы захотите здесь допустим сказать 8 6 400 здесь какой-нибудь условно там 42000 43 тысячи двести что prefered lifetime будет только половина что ну или две трети не суть важно да вы указываете что у вас адреса выдаются на определенное время и в течение некоторого времени вы используете эти адреса без ограничений

можно задавать лайф тайм одинаковые они не не сильно это будет на что-то влиять ну и дальше вы на интерфейсе точно так же как состоит ли с конфигурацией вешаете айпишник вешаете джи цепи сервер вот он то есть здесь принципе гипотетически мы могли уже сказать что айпишник на этом интерфейсе у нас такой же который попадает вот сюда вот но это уже не важно потому что в явном виде на интерфейсе надо будет повесить джи цепи сервер есть нюанс когда вы указываете что у вас есть вот этот самый джи цепи сервер вам нужно будет сказать что клиенты должны получать адреса с этого сервера они не должны использовать слаг а у вас рассылкой рашек работает потому что вы повесили маршрутизируемый айпишник на интерфейсе и у вас есть ipv6 unique astro тин поэтому вы рашки по умолчанию отсылаете на всех интерфейсах где у вас есть живые адреса а если вы не хотите этого делать то вы должны будете сказать что у вас есть префикс на этом интерфейсе 2001 db 8 b16 bb 5 connected и вы его не отсылаете но

отвертаясь это вот галочка которая можно поставить сказав что этот префикс отсылать по по рашкам не надо ну и тогда у вас адрес есть вы про него никому ничего не рассказываете клиенты не генерят адреса автоматически но им надо будет сказать ребят вы должны будете рашки получать и в этих рашках должно быть написано сходите в дичьи пи сервер и слав получите адреса с дичьи пи сервера в предыдущем варианте состоит ли софта конфигурации мы устал выставляли флаг азар для дичьи пи для того чтобы получать адреса поди чтп надо будет указать менеджер конфиг флаг и айпи 6 нд менеджер конфиг флаг именно это и делает то есть вы отправляете рашки в этих рашках нет опции префикс информация для нужной сети но есть указание адреса получаются на дичьи пи сервере так да на клиенте ipv6 адрес дичьи пи в общем предсказуемо будет включаться получение и пишника единственный нюанс смотрите какая штука дичь себе клиент

работает по ipv6 он для того чтобы получить адрес должен с использованием какого-то адреса ну в частности link local адреса побежать на сервер и сказать дай адрес но есть проблема в том что адрес боевой у вас появляется тогда когда вы на интерфейсе прописываете указанию что на этом интерфейсе есть либо ipv6 и не был либо ipv6 маршрутизируем адрес вот если вы просто указываете ipv6 адрес 10 теперь то вы дичь себе клиент запускаете адрес не порождаете и у вас нету link local адреса когда вы делаете а пиви 6 адрес дичь себе это нелогично это неразумно но вот вы должны в явном виде прописать а пиви 6 и не был я на это накалывался в свое время сейчас вот с вами делюсь то есть это противоестественно на мой вкус но вот циска работает так также как и в случае с предыдущим сценарием у нас есть возможность посмотреть на пулы как вот который мы создаем и вот у нас есть еще а пиви 6 дичь себе пул который

показывать что да у нас раздаются сеть 2001 db8 бодин 6 бэба 5 у нас есть в элит lifetime вот это и prefered lifetime бесконечность 137 лет кроме того раздаются какие-то опции и у нас даже есть один лох который нашелся и взял такой айпишник еще и пиви 6 дичь себе байдинг ну аналогичная команда швай пидж себе байдинг показывает что это был за клиент показывается какой адрес мы ему сгенерировали и какие лайфтаймы у этого адреса будут при фирме тайф тайм вот такой вылет тайф тайм бесконечности бесконечности на самом деле 136 лет так при этом то что вы проставили prefered lifetime 86 тысяч 400 на самом деле означает что этот адрес можно без каких-либо ограничений использовать течение одного дня циска автоматически сказала что это время т и автоматически поделила его пополам получила время т1 43 200 и автоматически взяла

три четверти от времени т и сказала что это будет время т2 в течение которого надо будет продлить аренду каким-либо образом т1 это вы пытаетесь продлить аренду с своего сервера в мульти кастом в смысле со своего сервера генекастом это 2 вы пытаетесь продлить аренду мульти кастом так еще одна вещь которая на самом деле реально будет очень полезная вообще конечно место этому этому слайду было бы наверное на курсе по роутингу но уж как получилось так получилось в блюпринте свеча он есть поэтому как бы приходится рассказывать это здесь штука называется prefix delegation смысл ее заключается в следующем у вас есть айпи 6 сеть особенно вот это кстати будет актуально провайдером или тем кто подключается к провайдером то есть у вас есть айпи 6 сеть это например здесь где-то здесь есть интернет у вас есть

ну вот например вот это вот эта провайдерская сеть у вас есть клиенты которые подключаются к провайдеру и у них за спиной у каждого роутера цп ешки будет отдельные широкопечательный домен с конечными узлами и ваша цп ешка должна при подключении к провайдеру получить пачку адресов которые будут как называется которая будет использоваться во внутренней сети то есть вам нужно будет каким-то образом отсюда получить от префиксы которые будут использоваться вот здесь вот и в айпи в 4 такой возможности не было а вот в айпи в 6 она появилась называется dhcp в 6 pd dhcp в 6 префикс delegation используется там новая опция dhcp префикс который опять же раньше не было но и смысл ее будет следующим цепь ешка будет подключаться по dhcp в 6 будет заказывать префиксы вот он

говорит дай префикс и соответственно ответ пдшки ответ 10 пи сервера будет я тебе выдаю префикс который ты можешь использовать вот пришла одна пдш пришла одна цп ешка ей выдали вот такой префикс пришла другая цп ешка другого клиента она тоже сказала да и префикс и выдали уже другой префикс то есть вот здесь вот b501 здесь бы 502 и выдаются префиксы по какой-нибудь там не знаю либо слышь 48 либо слышь 56 либо слое 60 ну то есть раздается пачка префиксов которые потом цп ешка может взять и подербанить на более мелкие части по 64 маски и дальше цп ешка скажет я получила префикс ну допустим слышь 60 из него можно получить 16 64 сеток и вот она эти сетки начинает раздавать на своих внутренних интерфейсах вот например у нас здесь был получен b501 2 2.6 60 вот здесь вот опять 0 1 60 как подозрительно да такого быть не может ну ладно не суть важно вот она получила какой-то префикс по 60 маски дальше

назначает уже отдельные префиксы по 64 маски на абонентов то есть здесь у нас используется уже обыкновенной рашки клиенты генерируют адреса посла q и получается что вот этот вот роутер который взял префикс слое 60 и разбил на части по 64 маски он знает в таблице в амортизации есть указание где какой кусочек префикса используется здесь у нас один кусочек префиксы здесь у нас другой кусочек префиксы здесь третий кусочек префиксы здесь 4 кусочек префикса внешний роутер который раздает внешний сервер который раздает адреса он раздает префикс целиком и он говорит я забирай пожалуйста весь префикс целиком ты среди прочего он еще параллельно и маршрут на эту сетку ставит до того кто забрал этот префикс поэтому когда пакеты из интернета будут приходить на любой из этих адресов на этот на этот на этот на этот в любом случае маршрутизация будет выполняться на цепи ешку клиента который получил

всю пачку адресов целиком то есть это все связано с маршрутизацией и это все связано с тем как сделать так чтобы адреса клиенту на можно было выдавать большими пачками и настраивать маршрутизацию тоже большими пачками сразу в сторону клиента помните да что у нас задача при подключении к 6 интернету на самом деле несколько первое как получить маршрут по умолчанию но это легко решается статикой второе это как получить адреса и третье как сделать так чтобы на наш роутер роутер провайдера поставил свой маршрут вот это вот как раз самая важная задача которая решается с помощью опции джи тебе префикс мы запрашиваем определенный префикс определенную сетку нам это выдается и параллельно на нас ставится маршрут на эту сеть вот если мы хотим в джи пиве 6 сервера cisco скам это сделать то это делается достаточно легко у нас соответственно будет настройка на сервере на каком-то роутер ну как условно cпш к ну и какой-то обычный клиент который будет просто получать

адреса то есть вот это вот это сервер это у нас сервер это у нас ну типа cпш к в нашем случае это железка с названием свитч ну потому что это обычно как раз на свечах все делается ну и обычный клиент нас можно получать айпишники что нужно будет и где сделать на серверах нужно будет сказать что у вас есть некий пул адресов из которого вы будете вычленять отдельные префиксы будете отсылать их клиентам то есть создаем айпи 6 local pool дальше название пула pd префикс и указываем какие сетки мы будем раздавать какую сетку мы будем раздавать 2001 db 8 вы . 12 2 . слышь 48 и указываем по какой маски мы будем префикс отдавать слышь и сядь то есть мы берем 2001 db 8 2 . единицу дербанием ее на части на сервере и отдаем кусочки этой сети в сторону тех кто просит префиксы префиксы мы отдаем по 60 маски

приходит один клиент мы ему даем один кусочек приходит другой клиент мы другой кусочек и так далее дальше нам нужно будет сделать пул айпи 6 dhc пи пул pd пул это пул в которой мы сложим кусочки этого самого этой сетки которые мы сделали с помощью pd префикс префикс делегей шин пол дальше указываем pd префикс то есть что в этот дичь и пишетный пол мы складываем кусочки префиксного пола pd префикс и наконец на интерфейсе указываемой пиве 6 не щепи сервер pd пул в принципе если вы включаете дичь и пи сервер вам не обязательно на интерфейсе иметь маршрутизируемый адрес то есть на предыдущем слайде мы указывали что у нас есть действительно а и пишник маршрутизируемый который из той же самой сети что мы раздаем бла-бла-бла но в ipv6 все взаимодействие идет с link local адресов и большому счету вам абсолютно не надо иметь

маршрутизируемый адреса на интерфейсах поэтому вам в принципе достаточно сделать а пиве 6 enable что здесь я пиве 6 enable что сейчас вернусь на предыдущий слайд что в принципе вот здесь вот вы могли на интерфейсе вилана сказать а пиве 6 enable все и дальше вам даже вот эта штука не понадобилась бы ну окей сделали так сделали вот здесь мы указываем просто пиве 6 enable указываем что у нас есть здесь теперь сервер каким-то образом делаем делаем указание что на этом интерфейсе мы раздаем префиксы то есть вот у у нас айпере 6 джеки сервер pd pool как раз и раздает это это все происходит в рамках джеки сервера и наконец идем на цепь и ошку и говорим что у нас есть интерфейс который мы смотрим на провайдера мы на этом интерфейсе генерируем адрес автоматически мы можем в принципе и пишет не попросить подище пи сказать ну да и адрес но это не обязательно и пиве 6 адресов конфиг дефолт что мы генерим адрес

посла оку каким-то образом для этого наверное здесь надо иметь слаг но не суть важно дальше указываем а и пиве 6 dhcp client pd и дальше даем какое-то название префиксу который мы получим с помощью префикс делегейшен здесь у нас будет работать следующая штука мы получим префикс кусочек вот этой вот сети по 60 маски мы его сложим в в в емкость который называется префикс сущность который называется префикс и дальше мы на интерфейсах вот у нас интерфейс вилан 1 скажем айпи в 6 адрес дальше название префикс вот это вот самое та самая сущность тот самый префикс который мы получили по префикс делегейшен и дальше сделаем хвост от этого адреса хвост он естественно будет нужного размера то есть мы должны будем знать какого размера префикс мы получаем и вот мы указываем что возьмем префикс

который мы получили и наложим его на адрес 2 2 2.1 2.0 2.0 2.0 2.1 64 то есть вот эта вот штука это наш интерфейс айди а вот вся вот эта вот часть это она указывает что возьмем то что прислали нам по 60 маски и приклеим к ней единичку и дальше интерфейс ади 0 0 0 1 на другом интерфейсе мы говорим возьмем вот этот вот префикс по 60 маски приклеим к нему двоечку и тоже интерфейс ади 0 0 0 1 и у нас получится на одном интерфейсе вилан 1 1 адрес db 0 1 db 8 там 2.1 2.1 единичка она на другом интерфейсе 2001 db 8 2.1 2.2 и дальше два 2.1 на обоих интерфейсах мы взяли один и тот же префикс 2001 db 8 единицы 2001 db 8 единица дальше приклеили единицу и двойку и все остальное забили чем попало интерфейс айди вот один раз получили

префикс порезали его на части и раздали клиентам можно будет в принципе получить префикс и целиком его отдать клиенту просто сказать мы получили префикс там сло 64 и этот префикс мы вешаем на единственном интерфейсе который у нас есть вилан один просто приклеиваем к нему хвост длиной 64 бита чем такая штука хороша тем что вы не знаете какие у вас будут айпишники вы динамически получаете и адреса от вашего провайдера и вы динамически эти адреса раздаете вашим клиентам и клиенты эти адреса динамически получают динамически все с ними делается вам не надо ничего статически прописывать на цп ешки то что провайдер вам отдает то соответственно вы просто используете вот именно с помощью такой схемы чаще всего будет происходить подключение к интернету по ipv6 вы настраиваете префикс делегейшн в сторону провайдера провайдера вам отдает префикс и вы этот префикс раздаете на ваших клиентов если у вас нет префикс делегейшн а то есть не поддерживается почему-то действие в 6pd то вы заставляете вашего провайдера

прописывать на вас маршрут руками и конечно провайдер будет очень несчастлив если вы это делаете ну как правило до подавляющее большинство железок которые работают с ipv6 которые могут работать с пешками они вполне нормально работает с префикс делегейшн но бывает такие упорты провайдера которые говорят а мы не умеем а вот давайте выжать давайте мы ручками по старинке пропишем все статикой ничего не сделаешь тогда с ними проще то убить их сделать новую планету которая населена нормальными здравым здравомыслящими людьми так аналог команды ip и dhcp snooping в ipv6 тоже есть это соответственно штука будет называться на 10 6 guard вы будете ее включать на уровне отдельного интерфейса и если у вас есть свитч который на каком-то интерфейсе работает в коммутирующем и пардон на каком-то интерфейсе работает в коммутирующем режиме то есть там работает свеч порт вы на этом интерфейсе

указывайте а и пиве 6 dhcp guard и она будет на этом интерфейсе блокировать неправильные ответы будет блокировать не плат неправильный advertisement и неправильные реплай то есть это вариант с сну пингом но очень очень очень простой обратите внимание настраивается это не глобально на железке настраивается это не глобально на уровне вилана настраивается на уровне отдельного порта вы можете если захотите включить и глобальный механизм дичь и пиквард сказать что в каких-то случаях вы можете пропускать сообщения только от определенных адресов только на определенные адреса с какими-то правильными префиксами с какими правильными адресами то есть вы можете достаточно гранулярно это сделать делается это через политике вы должны будете создать политику дичь и пигвард делается это вот так вот вот отсюда и

соответственно вот досюда это политика политике достаточно мощные вы можете нации ски взять прописать эту самую политику сказать что конкретно вы хотите пропускать нашу случаем и делаем по лифм который 0 называется DHCP Guard Service Policy. И мы указываем, что если вдруг мы видим какие-то сообщения в reply и advertisement, то мы пропускаем такие сообщения, если они идут от сервера, попадающего под определенный access-лист, если они содержат в себе reply с определенными префиксами, если там передается сообщение с определенными преференсами, вот в таком вот диапазоне. Ну и вот если мы говорим, что мы хотим повесить эту политику, то нам понадобятся и сами access-листы, естественно, в нашем случае вот DHCP Server Access List Prefix List DHCP Prefixes. И нам потребуется на уровне отдельного интерфейса сказать IPv6 DHCP Guard Attach Policy. Не просто DHCP Guard Policy, а Attach Policy.

И дальше вы указываете, какая политика вас интересует. Вот. Полезная штука, опять же, если у вас используется DHCP V6, ну, естественно, более она будет полезна для компаний, которые используют DHCP Stateful режим. Если вдруг вы хотите отслеживать, кто у вас действительно какой IP-шник получил, чтобы, не дай бог, не получилось, что кто-то внутри сети зародился из-под неправильного IP-шника, отправил какие-то неправильные данные. Ну, в свете актуальных, скажем, изменений в государстве, это вполне может быть осмысленное явление. Вот. В этом случае вы делаете DHCP сервер, в котором ведете четкий учет, кто, куда, зачем и почему. И вы можете, соответственно, на уровне интерфейсов прописать политику, кто имеет право отправлять адвертайзменты и реплаи, и что в этих адвертайзментах реплаи может содержаться. Ну, если вы такое будете делать, то тогда у вас сеть ваша будет надежно работать, безопасно, волосы будут гладкими шелковистыми.

Учитывая продвижение IPv6 на рынке, пока что, наверное, в предприятиях это все-таки не самая популярная будет штука, хотя в ближайшее время наверняка будет расти ее доля. Так что представлять, что это существует, по крайней мере, точно нужно. Я предлагаю на сегодня закругляться. Наше дозволенное время для речей закончилось. Так что DHCP V6, как вы видите, протокол в принципе не сложный. Можно будет сказать, что очень похож на IPv4. Вот. IPv4 и DHCP надо будет на экзамене знать, как очень наш IPv6, ну, представлять, как он работает. Ну и, в общем-то, все. Дальше у нас следующий модуль будет посвящен уже совсем новой теме, будет посвящен Spanning 3. На сегодня все. Спасибо за внимание.