Протокол DHCP и его роль в IP-сетях

Еще один протокол, который понадобится нам для служебных задач в IP, помимо протокола ARP, который мы только что разобрали, это DHCP. На самом деле он очень полезный протокол, несмотря на то, что гипотетически можно жить и без него. Впрочем, без ARP тоже можно жить. Вы можете всем записям просто статически привязать IP-шник к MAC, но это будет неудобно. DHCP тоже протокол, который заметно упрощает жизнь администратора, требуя минимального количества статических привязок. Для того чтобы в IP-сети работать, нужно каждому узлу дать достаточно немаленький набор стартовых настроек. Как минимум, это IP-шник и в бесклассовом мире, естественно, маска сети. Как минимум, это адрес шлюза, если вы работаете в IP-сети, которая требует межсетевого взаимодействия, а скорее всего это так и будет. Вам нужно будет какие-то вспомогательные службы выдать — DNS, TFTP, NTP и что там еще полагается. Вам нужны будут стартовые настройки IP в части, например, TTL или если вдруг вам необходимо какой-то нестандартный выдать.

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

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

Поэтому по факту в такой ситуации будет здорово, если у вас будет какая-то автоматизированная система, которая будет назначать IP-адреса сама. Причем делать это будет автоматически с исключением вероятности коллизий на хостах. Протокол DHCP — это как раз протокол, который такую задачу и будет решать. На самом деле это не какой-то самостоятельный протокол. Это надстройка над протоколом BootP, который тоже решал ту же самую задачу. У вас BootP — протокол, который назначал IP-шники на хосты, а он, в свою очередь, решал ту же самую задачу, что до него решал протокол Reverse ARP, который мы уже с вами рассмотрели, когда говорили про ARP, который орал на всю сеть: у кого из вас есть IP-шник, соответствующий моему MAC, скажите мне его, пожалуйста. Reverse ARP просто не позволяет ничего, кроме одного адреса, выдать, потому что там количество полей в заголовке очень сильно ограничено.

BootP в этом смысле был более продвинутый протокол, он позволял назначить IP-шник, он позволял работать со сценарием вида «вам нужен IP-шник на некоторое время», он позволял отдавать эти адреса потом, если они вам были не нужны. BootP был более продвинутый протокол, чем RARP, но у него тоже был недостаток такой же, как у RARP. Он был сугубо классовый. В нем нельзя было выдать маску, например. В нем нельзя было выдать DNS-сервер, в нем нельзя было выдать шлюз. Можно было выдать IP-шник, и можно было вести учет этих IP-шников. Но эти возможности BootP были ограничены. А DHCP — это надстройка над BootP, заголовок BootP-шный остался, но дополнительно к нему, так же как в заголовке IP было поле options — какое-то место, куда можно чего-нибудь дополнительно написать — у BootP тоже было такое аналогичное поле options, в которое можно чего-нибудь дополнительно написать. И DHCP как раз в это самое поле активно всякое разное пишет.

И это всякое разное — то, чем мы по факту сегодня и пользуемся. Штатным заголовком BootP по факту DHCP сегодня мы не пользуемся практически. Чем DHCP хорош? Именно тем, что он решает задачи, которые в сегодняшнем мире необходимы. Он выдает узлам IP-шники и выдает им их на время, соответственно, дает их на некоторый срок. И после окончания этого срока надо будет либо продлить аренду, либо забрать этот адрес, пометить его снова как неиспользуемый и при необходимости выдать кому-нибудь еще. Можно будет ввести некий список фиксированных привязок IP-шников к MAC-у. Если вдруг вы захотите, чтобы у вас конкретный узел всегда получал один и тот же IP-шник, не проблема. Вы можете такой список ввести. И когда конкретный узел по DHCP к вам обратится за IP-шником, вы будете ему выдавать его собственный адрес. DHCP не гарантирует отсутствие конфликтов,

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

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

что у Васи IP-шник такой, у Коли — сякой, у Пети — третий, у Сережи — четвертый. Они не пересекаются, и это прямо ручками в конфигурации сервера где-то жестко записано. И третий способ выбора адреса для выдачи клиенту — это автоматический. Это помесь динамического и ручного размещения. Выбор будет для новых клиентов осуществляться из пула свободных адресов, но после того, как адрес выбрался из пула, он сопоставляется с клиентом на постоянной основе. Он становится фактически как вручную размещенный адрес. Помните, в Port Security была концепция sticky, когда адрес распознавался как хороший динамически, а потом прилипал к running-конфигу и фактически вел себя как статический адрес. Это та же самая история. У вас есть пул свободных адресов, и вы из этого пула, когда приходит кто-то новенький, выбираете свободный адрес, и дальше запоминаете этот адрес за этим новеньким уже на постоянной основе.

Если новенький снова придет, вы ему выдадите тот же самый IP-шник. Эти три термина могут быть на экзамене: Dynamic, Manual и Automatic. И смысл за ними будет именно такой. В реальности вы с ними никогда встречаться не будете, поэтому просто надо запомнить и все. Какой бы способ выбора IP-шника для конкретного клиента вы ни выбрали, в любом случае вы адрес даете в аренду. Даже если у вас адреса выдаются с ручными привязками, все равно вы выдаете адрес на некоторый срок. А дальше клиент должен будет продлить использование этого адреса, если вдруг ему не захочется его вернуть. Или, соответственно, если он его вернет в кавычках, то он у нас будет в кавычках «возвращен на сервер». Но он в любом случае будет ждать, пока именно его настоящий обладатель снова придет и снова IP-шник попросит. Клиент не может заказать, какой он адрес хочет. Клиент просто говорит «дай адрес», а сервер уже целиком и полностью отвечает за то, какой адрес выдать.

В DHCP у нас будет использоваться вложение в протокол UDP, который мы с вами еще пока не разбирали, но дальше разберем. Я думаю, что вы догадываетесь, что у UDP есть такая штука, как порты. Если догадываетесь — хорошо, если нет — ничего страшного. Здесь не совсем правильно нарисовано. Порт клиента 68, порт сервера 67. И когда вы отправляете этот самый DHCP-шный запрос, у вас там есть два порта: порт клиента и порт сервера. Кто кому отправляет. И клиент будет отправлять на сервер UDP-шную датаграмму, в которой будут содержаться IP-шные вложения с DHCP-шными опциями. И там будут указаны порты 67 и 68 соответственно. В обратную сторону от сервера к клиенту будет с 67 на 68. Если мы говорим про заголовок IP, в который вкладывается UDP-шная датаграмма,

то там будут указаны адреса. Если у нас есть какой-то клиент, который хочет получить IP-шник, он, как правило, на тот момент, когда он хочет получить адрес, еще не имеет никакого адреса, поэтому он отправляет свои запросы на широковещательном уровне, на адрес 255.255.255.255 с адресом 0.0.0.0. 0.0.0.0 — это единственный случай, когда вы имеете право заполнить такой адрес в качестве адреса-источника. Это случай, когда у вас нет никакого IP-шника. Если у вас есть собственный адрес, вы его обязаны указывать в source-адресе. Но если у вас никакого IP-шника нет, например, в ситуации, когда у вас DHCP-запрос идет, то вы можете указать там пустой адрес. И дальше вы должны будете указать один из типов сообщений, которые вы будете посылать. В DHCP есть достаточно большое количество сообщений. Там их в рамочном стандарте 9 штук, плюс еще дополнительные стандарты предусматривают всякие дополнительные механизмы.

И из наиболее часто используемых типов сообщений — их 13 штук. Все 13 запоминать не надо, даже знать не надо. Из тех, которые действительно используются, которые вы можете встретить в реальном мире, надо знать 4 сообщения. Эти 4 сообщения могут быть на экзамене, они абсолютно точно будут у вас в реальной жизни. Это сообщения Discover, Offer, Request и Acknowledge. Если вы посмотрите на первые буквы этих сообщений, получится D, O, R и A. Как английское имя Dora. Эту Dora надо будет запомнить. Это штатная схема взаимодействия в DHCP, и на экзамене она почти наверняка будет. Discover будет нужен для того, чтобы клиент мог обнаружить серверы. У вас клиент проснулся, у него нет IP-шника, ему очень хочется. Он орет на всю сеть: ребята, кто-нибудь из вас есть сервер, я хочу IP-шник. Он discover-ит эти самые серверы. В ответ на Discover сервер или серверы — их может быть много — присылают Offer.

Они говорят: смотри, у меня есть вот такой IP-шник, хочешь его? Если у вас несколько серверов, то они могут присылать вам разные офферы. Вам нужно на один из этих офферов согласиться. Вы посылаете Request, говорите: я согласен на твой оффер. И этот Request автоматом означает, что на все остальные офферы вы не согласны. Остальные серверы понимают, что их отвергли. И последнее сообщение — Acknowledge, оно завершает процедуру начала аренды. И после того, как Acknowledge отправлен, адрес числится за клиентом уже на постоянной основе. До тех пор, пока аренда не закончится. Как только она закончилась, клиент больше права использовать адрес не имеет. Если он хочет использовать адрес даже после окончания этого срока, ему следует до окончания аренды выполнить процедуру продления этой самой аренды. Он посылает на сервер, который выдал ему адрес, сразу Request. И сервер, если склонен продлить аренду, отвечает Acknowledge.

То есть Request, Acknowledge, Request, Acknowledge. Эту самую Dora надо будет запомнить. У нас есть клиент, он орет Discover. Сервер — один или несколько — отправляет офферы. Клиент соглашается на один из этих офферов, посылает Request. И тот сервер, который получил Request, отвечает Acknowledge. Все аренды, которые у вас есть, выполняются на ограниченное время. И время этой самой аренды указывается сервером в сообщениях Acknowledge и Offer. И оно указывается в секундах. Это будет называться так называемое время T. Вы отправляете сообщение, вы говорите: я тебе даю адрес на, допустим, одну секунду, или на 60 секунд — на минуту, или на 3600 секунд — на час, или на 86400 секунд — на сутки. В любом случае вы указываете просто количество секунд,

в течение которого этот адрес клиент может использовать. Если время аренды закончилось, а клиент продлить аренду не смог, то клиент не имеет права этот адрес больше использовать. Он его фактически выкидывает, а сервер со своей стороны, если он видит, что клиент не продлил аренду, возвращает этот адрес в пул свободных адресов и может его предложить кому-нибудь еще. Если вдруг клиент хочет продлить аренду, то он это должен делать не в совершенно произвольный момент. Он может это сделать в произвольный момент, но есть рекомендуемое время, когда ему это стоит делать. Во-первых, это имеет смысл делать, пока аренда действительна, то есть до того, как она закончилась. После того, как она закончилась, надо заново запускать процедуру Dora. Есть помимо времени T, который идет в сообщении с Acknowledge, дополнительные времена, которые идут в том же самом сообщении, это время T1 и время T2. Это тоже количество секунд, которое проходит с начала времени аренды.

Вы получили IP-шник, вы начинаете считать это количество секунд. Допустим, тут лежит число 3600. Это будет 1 час. 3600 секунд — 1 час. Вы получили адрес, вы начинаете считать: 1, 2, 3, 4, 5, 6. Если досчитали до 3600 — время аренды — и аренду вы не продлили, то адрес вы выкидываете. Но как только вы досчитали до времени T1, которое меньше, чем время T, естественно, и обычно оно равно половине времени T, вы пытаетесь продлить аренду. Прошла половина срока, в нашем случае 1800 секунд. Вы говорите: у нас, кажется, прошло полчаса, надо бы продлить аренду. И если вдруг у вас это получилось сделать, то заново начинает тикать время T, которое вы получили уже в момент продления аренды. Опять же, через полчаса вы снова продляете аренду и так далее. Если вдруг у вас не получилось продлить аренду сразу, то вы через некоторое время повторно пытаетесь продлить аренду. Не надо слишком часто это делать.

Там есть рекомендация, как часто это делать. И обычно она заключается в том, что вы делите оставшийся срок пополам, и через половину оставшегося срока снова пытаетесь продлить аренду. У вас за 3600 секунд устаревает адрес целиком. Время T1 — это рекомендуемые 1800, обычно половина времени T. Через полчаса вы говорите: надо бы продлить аренду. У вас не получилось. Вы говорите: окей, у нас осталось еще 1800 секунд нормальной аренды. Через 900 секунд я повторю попытку продления аренды. И на 45-й минуте действия адреса вы еще раз пытаетесь продлить аренду. А потом еще раз через половину оставшегося срока. И тут обычно подходит время T2, которое равно 7/8 времени T. Что значит, что вы дошли до времени T2? Это значит, что вы уже, скорее всего, как минимум три раза выполнили попытку продления аренды, и у вас не получилось это сделать.

Смысл заключается в том, что продление аренды — вы посылаете Request и получаете Acknowledge на него. Вы делаете это не бродкастом. Вы это делаете юникастом к тому серверу, который вам выдал адрес. И у вас есть клиент. Этот клиент орал на всю сеть «дайте адрес». И тут у нас был какой-то сервер, который выдавал вам IP-шник. Вы сначала по схеме Dora, Discover нашли такой сервер. Он вам выдал IP-шник, и вы начали считать свое время T. Что значит, что у вас не получилось за 7/8 времени T, за время T2 обнаружить этот самый сервер и продлить с него аренду? Например, это может означать, что сервер недоступен, он выключен, или какая-то проблема с сетью с ним связана. Но вы можете после времени T2 пытаться бродкастом продлить аренду в логике, что есть какой-то другой сервер, который вправе распоряжаться теми айпишниками, которые у вас есть.

Это у нас сервер 1, а это сервер 2. Это другой сервер, у него другой айпишник, но, возможно, он распоряжается той же самой базой. Поэтому вы бродкастом пытаетесь продлить аренду, посылаете реквест бродкастом. И если вдруг в сети есть какой-то другой сервер, который уполномочен продлить вам аренду вашего адреса, он попытается это сделать. И вы получите acknowledge от него, и вы сможете использовать адрес, продлённый уже с другого сервера. Но если даже это не получилось сделать, то вы должны будете, дождавшись конца срока аренды, адрес выкинуть. И никто вам в этом случае не мешает выполнить схему DORA повторно и получить IP-шник хотя бы с кого-нибудь. Можно досрочно прекратить аренду, если вы, например, получили IP-шник, и вам его выдали, не знаю, на месяц, а вы хотите выключиться. И вы в эту сеть больше вообще никогда не планируете вернуться. Будет некрасиво, наверное, если у вас сервер будет в течение месяца

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

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

BootP-заголовок, а вы просто посмотрите на неё и поймёте, чего здесь можно сделать, чего нет. Это формат сообщения. Ещё раз подчеркну, BootP на самом деле, не DHCP, BootP. Первое — это оп-код, то есть код операции. Единичка — это запрос, и двоечка — это ответ. Запрос — это, например, Discover или Request. Это то, что клиент просит чего-то сделать, это будет request. А со стороны сервера в сторону клиента идут ответы, boot-reply. H-type — тип аппаратного адреса. Для Ethernet мы уже видели в ARP — это единичка. H-len — это длина аппаратного адреса, для Ethernet — это шестёрка, 6-байтовый MAC-адрес. Где-то мы это уже видели. И Hops — не сильно полезное поле, указывает на количество промежуточных так называемых агентов ретрансляции

или релеев, которые у вас есть между вашим сервером исходным и клиентом. Смысл заключается в том, что клиент, когда орёт на всю сеть «Мужики, дайте адрес», он орёт обычным бродкастом. И гипотетически бывают ситуации, когда у вас есть клиент, он орёт на всю сеть «Дайте адрес», и он находится в сети, в которой есть роутер, который настроен как релей. И он будет тоже через какую-то цепочку роутеров связан с неким сервером, который будет готов выдавать адреса. В этом случае бродкаст распространяется в этой сети, в этом широковещательном домене. Дальше агент ретрансляции перекладывает этот пакет в виде какого-то другого пакета на другой роутер, и другой роутер уже перекладывает дальше, и всё это доходит до сервера в итоге. В BootP это имело некий смысл, но не очень много этого смысла было. А в DHCP процедура перекладывания больше, чем один раз, потеряла весь смысл целиком. Потому что если вы перекладываете данные

между разными средами, вы можете из бродкастового пакета здесь сделать юникастовый пакет, который пойдёт напрямую на тот сервер. Поэтому, как правило, в современных сетях хопов у вас не сильно много будет. Агентов ретрансляции либо не будет вовсе, либо будет только один. Когда клиент отправляет запрос, он выставляет это поле в нолик, и дальше следующие агенты ретрансляции, которые появляются, добавляют единичку к этому полю. Эта штука в BootP была хоть сколько-то актуальна, а сейчас по факту это поле может принимать только одно значение: либо нолик, либо единичку, если это не нолик. Если есть хотя бы один агент ретрансляции, то он всего один. XID, он же Transaction ID. Клиент генерирует некое случайное число, и дальше, когда ведётся взаимодействие в рамках транзакции получения IP-шника, все узлы будут указывать

этот номер транзакции. У вас есть какой-то клиент, он говорит: я бы хотел получить IP-шник, он генерирует некое случайное число, 4-байтовое, отправляет Discover с указанием этого числа, и дальше все офферы будут ссылаться на тот самый Discover. Они будут указывать этот номер транзакции как то, что это идёт ответ на то сообщение. И клиент будет видеть, что он отправил один запрос, и дальше в рамках этого запроса пришла куча офферов, и это офферы именно его. Гипотетически может быть ситуация, когда у вас два разных клиента, они орут на всю сеть «дайте адрес», и надо не спутать, кто какой адрес попросил. В этом случае серверы будут указывать, на какие сообщения они отвечают, с использованием этого самого XID. Дальше, CI-адр, client-IP-адрес. Если вдруг у клиента уже есть IP-шник, он может его указать, он будет говорить:

я хотел бы получить вот этот адрес, например. Your-IP-адрес — это то, что сервер предлагает клиенту. SI-адрес — это server-адрес. И GI-адр — это gateway-IP-адрес, тот самый адрес агента ретрансляции или релея, который последний выполнил ретрансляцию. CH-адр — это client-hardware-адрес, аппаратный адрес клиента, по сути своей это MAC-адрес клиента. И учитывая, что гипотетически DHCP или BootP мог работать не только с Ethernet, он мог выбирать длину аппаратного адреса произвольным образом, максимальная длина аппаратного адреса предполагалась не больше чем 16 байт. Но по факту, если мы сюда записываем шестёрку, то из этих 16 байт

у нас 6 будет занято MAC-адресом, и ещё 10 будет забито нулями, мусором, который ничего не будет означать. Если сервер захочет, он может представиться, он может сказать, как его зовут, и в этом случае у нас будет поле Sname 64-байтовое, которое будет указывать как раз на то, какой сервер это. И рядышком Там ещё есть поле File. Это необязательное, но имя файла на сервере, который будет использоваться для бездисковой загрузки. У вас есть какой-то клиент, он проснулся, заорал на всю сеть, дайте, пожалуйста, IP-шник, ему выдали не просто IP-шник, а ему ещё и дополнительно сказали, на тебе IP-шник сервера или имя сервера, с которого следует попытаться загрузиться, и вот тебе название файла, с которого нужно будет загружаться, то есть образ операционной системы или конфигурация или что-то ещё. И дальше поле опций, вот как раз вся магия

будет заключаться там. Даже начинается это поле опций с так называемого Magic Cookie, магическая печенька для DHCP, всегда одно и то же число, 63-82, 53-63. Как только вы видите, что у вас есть BOOTP-шный пакет, начинающийся с этой самой Magic Cookie, вы понимаете, что дальше идёт именно DHCP-шная опция. Сами эти опции, запоминать их не нужно, но некоторые просто надо знать, что они бывают. Самая первая опция, у неё есть код, то есть номер опции, потом указывается маска. BOOTP — протокол классовый, но если мы используем дополнительные опции, мы можем указать маску и сказать, вот тебе IP-шник, your IP-адрес, и вот тебе маска к этому IP-шнику. Можно указать шлюз по умолчанию, это опция Router с кодом 3, можно указать DNS-сервер, это опция номер 6,

Name Server. Можно указать TTL, можно указать MTU, тайм-аут кэша ARP, например, сделать так, чтобы у вас все записи в кэше ARP устаревали очень быстро, и в некоторых ситуациях это может быть интересно. Можно указать имя хоста, с которого надо брать файл конфигурации, например, для телефонов очень актуальная вещь. Если будете настраивать IP-телефон, как раз каждому телефону надо будет сказать, где он должен брать конфигу, и это IP-шник сервера и имя файла, имя файла телефон, как правило, сам генерит. Можно отдать DNS-имя, и тогда вам потребуется дополнительный Name Server, или сразу IP-адрес сказать, то есть 66-я или 150-я опция, это либо требуется DNS, либо не требуется. И самая последняя опция будет с кодом 255, она будет завершать перечисление всего-всего-всего.

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

DHCP-серверами в сети довольно тяжело. То, что вы можете увидеть, например, в Active Directory есть такая штука, авторизованные DHCP-серверы в Active Directory, это всё не про то, что неавторизованные серверы у вас не смогут работать. Они точно так же смогут работать в Active Directory, если вдруг вы будете авторизовать DHCP-серверы. Это просто чтобы они показывались в списке или не показывались. Но это не про то, что неавторизованные серверы не смогут выдавать IP-шники. Для того чтобы защититься от каких-то левых серверов, вы должны будете настраивать на ваших коммутаторах анализ проходящего DHCP-трафика, так, чтобы ваши коммутаторы просто на портах доступа блокировали передачу DHCP-шных сообщений. Если ваши свитчи это позволяют, вы можете сказать, анализируйте проходящие DHCP-сообщения, если вдруг вы видите, что на порту обычного клиента внезапно начинают раздаваться DHCP-офферы,

пристреливайте такой порт или пристреливайте такие офферы, что-то с ними надо будет делать. Как раз, если мы говорим про, допустим, оборудование Cisco для корпоративных сетей, Cisco-вские свитчи такие вещи, конечно же, поддерживают и немало усилий будут гипотетически тратить на анализ такого трафика, и поэтому часто задают вопрос, Cisco стоит там 50 тысяч рублей за свитч, и какой-нибудь другой бренд производит коммутаторы, вроде такие же коммутаторы, вроде такие же стоечные свитчи, вроде всё то же самое, количество портов такое же, скорости портов такие же, PoE либо есть, либо нет, точно так же, как на Cisco. Но почему-то Cisco стоит сильно дороже. А вот эта фича, на самом деле, допустим, защититься на портах доступа от всяких левых неприятных атак, она достаточно много ресурсов жрет, и ее реализовать действительно довольно дорогое удовольствие. Но зато, если у вас есть сеть, в которой любой даунтайм приводит к, там,

сотням тысяч рублей потерь, это может оказаться очень и очень, скажем, выгодно купить свечи с поддержкой определенных защитных технологий, включить эти защитные технологии, и в случае, когда у вас атакующий внезапно начнет раздавать какие-то левые айпешники, у вас не будет даунтайма, не будет такого, что вы, там, попадаете на деньги, на какие-то неустойки или что-то еще, и, соответственно, теряете деньги. То есть, опять же, да, это, IT, это жест, это строгая наука, это не про то, что давайте сделаем что-нибудь и посмотрим на результат. IT, это сугубо математика. И надо будет уметь считать деньги. Если вы знаете, что у вас минута простоя стоит, условно говоря, 10 тысяч рублей, то, возможно, стоит защититься от, там, 10 минут простоя и сэкономить 100 тысяч рублей, заплатив 50 тысяч рублей вперед, как бы переплатив по сравнению с другим решением. Это вам по факту сэкономит деньги напрямую.

Так, по поводу времени аренды. Я уже рассказал, что сервер выдает все адреса во временную аренду. Время, соответственно, будет указываться в секундах. И, соответственно, это 32-битное число время в секундах. Соответственно, самое маленькое значение, которое можно отправить, что адрес выдается на одну секунду, но это перебор. И самое большое время, которое можно отправить, это 4 миллиарда 295 миллионов и дальше там 2 в 32 степени минус 1 секунда. Это примерно 136 лет. То есть, гипотетически DHCP не может выдать адрес на там 138 лет. Он просто не умеет такое делать. Но есть специально особые случаи, то есть, если вы выдаете адрес на 136 лет, то есть 2 в 32 степени минус 1 секунд, это называется бесконечность, инфинити. Ну, да, то есть наши внуки вряд ли доживут до этого. По поводу того,

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

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

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

И не получится так, что у вас там пропускная способность аэропорта, вот она в какой-то момент будет достаточно большой и не получится так, что у вас просто кончится пул адресов. Очень часто бывает так, что в аэропорту Вы подключаетесь к Wi-Fi, а система вам не может выдать IP-шник. Именно потому, что она всё ещё помнит, какие IP-шники были у тех, кто уже сидит в своём самолёте и выключил телефон в соответствии с требованиями безопасности. Поэтому для того, чтобы в такой гостевой сети не было неприятностей с клиентами, которые не могут получить адрес, выставляем срок аренды как можно меньше. Адреса будут освобождаться быстрее, и, соответственно, в пуле у вас постоянно будут свободные IP-шники. Если говорить про релеи, про агенты ретрансляции, как они будут работать? У нас есть клиент, он может заорать на всю сеть, мужики, дайте адрес, но это будет работать только в пределах широковещательного домена, потому что он орёт бродкастом 255.255.255.255.

Local Broadcast. Для того, чтобы отправить такое сообщение на какой-то внешний сервер, мы должны будем взять и переложить это сообщение из бродкаста в Unicast. Соответственно, source у клиента у нас 0.0.0.0, и destination 255.255.255.255. Агент ретрансляции, который будет перекладывать это сообщение из бродкаста в Unicast, он сделает абсолютно то же самое BOOTP-сообщение с практически теми же самыми опциями, но он сделает source-адресом IP-шник своего интерфейса, которым он получил этот бродкаст. Здесь у него висит 10.0.0.1, и он, соответственно, скажет: я с IP-шника 10.0.0.1 посылаю на адрес 10.2.2.2 —

DHCP-сервер. 10.2.2.2. И Unicast такое сообщение посылает на сервер. Зачем такая штука сделана? Зачем, в частности, брать IP-шник с того интерфейса, на котором вы получили DHCP-запрос? Смысл в том, что на этом сервере может быть много разных пулов адресов. Соответственно, будет пул с одними адресами, с другими адресами, с третьими адресами, он же не только вас может обслуживать, он будет обслуживать других клиентов. И надо выдавать такие адреса клиентам, которые имели бы смысл в этом широковещательном домене. Если вы указываете, что у вас IP-шник на интерфейсе, которым вы получили, 10.0.0.1, то сервер посмотрит, куда попадает IP-шник 10.0.0.1, в какой из этих пулов, и скажет: в этот пул попадает адрес 10.0.0.1. Мы из этого пула выберем свободный адрес и выдадим его клиенту. Скажем, у нас свободный адрес 10.0.0.3. И в оффере,

который пойдёт Unicast на 10.0.0.1, будет указано: я тебе предлагаю взять 10.0.0.3. Соответственно, роутер получает такой оффер, перекладывает его в виде бродкаста в тот интерфейс, через который он был получен, и клиент получает оффер бродкастом. Что? Я просил IP-шник, мне предлагают 10.0.0.3. Как здорово, я согласен его взять. Соответственно, бродкастом говорит: я согласен взять. Опять роутер Unicast перекладывает в сторону сервера. Сервер говорит: хорошо, я вижу, что я сделал оффер на 10.0.0.3, я вижу реквест на этот оффер, и, соответственно, я подтверждаю аренду, DHCP Acknowledge, Unicast посылаю на релей сообщение, всё хорошо. И оно, в свою очередь, тоже бродкастом перекладывается в сторону клиента. По поводу бродкаста здесь есть небольшой нюанс. Почему изначальный Discover идёт бродкастом, я думаю, объяснять не надо, потому что клиент не знает, кто по факту является

DHCP-сервером. Поэтому изначальный Discover в любом случае идёт бродкастом. В ответ на этот бродкаст несколько серверов, возможно, захотят предложить свои офферы. Когда у нас Discover проходит бродкастом, офферы будут приходить на этого клиента. И в ситуации, когда у нас клиент ещё не имеет IP-шника, у него нет никакого адреса. Фактически, на уровне IP единственная опция, которая есть, это послать ответный бродкаст. Какой-то адрес надо указать, и адрес 0.0.0.0 в качестве адреса получателя указать нельзя. Поэтому ответные пакеты тоже должны быть бродкастовые. 255.255.255.255. Но есть нюанс. В этом оффере, который придёт, уже содержится некий IP-шник. Когда сервер говорит: я тебе согласен выдать адрес, он говорит: я тебе, например, согласен выдать адрес 10.0.0.3. Гипотетически, сервер мог бы послать Unicast

на адрес 10.0.0.3, но на MAC-адрес того, кто спрашивал. Чтобы получатель понял, что это именно на его сообщение идёт предложение. Именно клиент отвечает за то, как будет отправлен ответ ему. Если он понимает — бывает такая ситуация, что он заорал на всю сеть бродкастом, дайте адрес, и тут ему на какой-то совершенно левый IP-шник с его точки зрения приходит ответ: я тебе согласен дать именно этот самый левый IP-шник. Если клиент понимает, что это такое, то, соответственно, он может в Discover выставить специальный флажок: либо Unicast, либо Broadcast. Соответственно, Broadcast значит, что ответы на Discover ожидаются тоже Broadcast, или Unicast — ответы на Discover ожидаются Unicast. Unicast на тот самый IP-шник, который предлагает сервер в своем оффере.

То есть, у нас получается, вот этот вот Discover идет с 0, 0, 0, 0, на 255, 255, ну, мне время писать, сами понимаете, 255, тут куча 255-ок. А ответ идет с 10, там, 0, 0, 1, на 10, 0, 0, 3. Вот этот 10, 0, 0, 3 еще никому не выдан. Он только собирается выдаться тому, кто спрашивал дойти адрес. Ну, вот, если клиент понимает, что это будет идти именно ему, он выставляет специальный флажок. И в некоторых ситуациях, да, может быть такое, что у вас ответы на ваши Discover и request будут идти Unicast. Вот. Еще один момент. Discover идет Broadcast, понятно, почему. Оферы могут идти Broadcast или Unicast в зависимости от настроения клиента. И почему DHCP request идет Broadcast? Здесь вот неочевидный момент, потому что, в принципе, гипотетически IP-шник сервера

у нас, кажется, уже есть, мы можем отправить ему напрямую запрос. IP-шник, который нам предлагают, тоже фактически у нас уже есть. Почему бы не отправить Unicast request? И дело в том, что здесь как раз авторы протокола DHCP заложились под то, что может быть несколько офферов. И когда вы отправляете request, вы его отправляете Broadcast, и тот, кто предложил вам оффер, с которым вы согласны, понимает, что, соответственно, с его оффером согласны, он у себя делает пометочку, что адрес, который он предложил, действительно зарезервирован за вами, действительно он больше не свободный. Но все остальные узлы, все остальные сервера, которые сделали вам офферы, они тоже у себя сделали пометочку, что адрес, который они предложили, они не могут его всем остальным предложить тоже, потому что иначе может быть ситуация, что несколько узлов согласятся на аренду одного и того же адреса. Поэтому они у себя сделали пометочку, что адрес, как бы, возможно, выдается прямо сейчас вам. И им надо будет эту пометочку с этого адреса снять. Поэтому, когда вы Broadcast'ом

посылаете реквест, вы также даете всем остальным офферам понимание, что оффер не пригодился, что пометочку «возможно, адрес сейчас будет зарезервирован, с этого IP-шника можно снять». Вот. Ну и, соответственно, окноулит, что же там, Unicast или Broadcast'у в зависимости от клиента, в зависимости от того, что он выставит в реквесте. Вот такой вот интересный протокол DHCP. ДИНАМИЧНАЯ МУЗЫКА