Ничего нет внутри у людей, вечно выставляющих все наружу

49% несчастных случаев происходит после слов: ...

За последние две недели компания Mozilla заблокировала 197 дополнений к Firefox
Sun, 26 Jan 2020 10:17:41 +0300

Выпуск дистрибутива Solus 4.1, развивающего рабочий стол Budgie
Sun, 26 Jan 2020 08:51:24 +0300

Выпуск композитного сервера Weston 8.0
Sat, 25 Jan 2020 11:21:54 +0300

Выпуск проекта DXVK 1.5.2 с реализацией Direct3D 9/10/11 поверх API Vulkan
Sat, 25 Jan 2020 09:14:18 +0300

Проект Geneva развивает движок для автоматизации обхода цензурирования трафика
Fri, 24 Jan 2020 22:59:26 +0300

Критические уязвимости в медицинских приборах для мониторинга состояния пациентов
Fri, 24 Jan 2020 10:17:44 +0300

7 уязвимостей в системе управления контентом Plone
Fri, 24 Jan 2020 10:08:42 +0300

Выпуск GNU Mes 0.22, инструментария для самодостаточной сборки дистрибутивов
Fri, 24 Jan 2020 09:44:35 +0300

SystemE, шуточная замена systemd на Emacs Lisp
Fri, 24 Jan 2020 08:23:05 +0300

Обновление ОС Qubes 4.0.3, использующей виртуализацию для изоляции приложений
Thu, 23 Jan 2020 20:33:36 +0300

Выпуск пользовательского окружения Sway 1.4, использующего Wayland
Thu, 23 Jan 2020 12:40:15 +0300

Релиз СУБД SQLite 3.31 с поддержкой генерируемых столбцов
Thu, 23 Jan 2020 10:26:27 +0300

Доступна сборка Android-x86 9.0-rc2
Thu, 23 Jan 2020 10:06:04 +0300

Google продлил до 8 лет время поддержи устройств на базе ChromeOS
Thu, 23 Jan 2020 09:54:13 +0300

Intel выпустил движок распределённой трассировки лучей OSPRay 2.0
Thu, 23 Jan 2020 08:12:07 +0300

Выпуск GhostBSD 20.01
Wed, 22 Jan 2020 22:52:30 +0300

Доступен GameMode 1.5, оптимизатор производительности игр в Linux
Wed, 22 Jan 2020 21:25:43 +0300

Новая версия встраиваемого JavaScript-движка от основателя QEMU и FFmpeg
Wed, 22 Jan 2020 18:10:27 +0300

Выпуск nginx 1.17.8 и njs 0.3.8
Wed, 22 Jan 2020 14:54:50 +0300

Открыт код клиентских приложений ProtonVPN
Wed, 22 Jan 2020 10:44:18 +0300

Технический комитет OASIS утвердил спецификацию OpenDocument 1.3
Wed, 22 Jan 2020 10:03:53 +0300

Дистрибутив Kubuntu начал распространение ноутбука Kubuntu Focus
Wed, 22 Jan 2020 08:38:45 +0300

Для Btrfs представлена асинхронная реализация DISCARD
Wed, 22 Jan 2020 04:48:18 +0300

Стабильный релиз Wine 5.0
Tue, 21 Jan 2020 23:14:20 +0300

Сanonical предложил Anbox Cloud, облачную платформу для запуска Android-приложений
Tue, 21 Jan 2020 14:37:47 +0300

Red Hat развивает JIT-компилятор MIR
Tue, 21 Jan 2020 08:48:56 +0300

Samsung предложил новый вариант драйвера exFAT для ядра Linux
Tue, 21 Jan 2020 08:01:58 +0300

Обновление Firefox 72.0.2. В Firefox 74 появится возможность запрета открепления вкладок
Mon, 20 Jan 2020 22:23:21 +0300

Rust-фреймворк actix-web возрождён и будет передан сообществу
Mon, 20 Jan 2020 21:36:52 +0300

Выпуск файлового менеджера Midnight Commander 4.8.24
Mon, 20 Jan 2020 21:17:09 +0300

В Минэкономики РФ предложили создать архив кода, дублирующий GitHub
Mon, 20 Jan 2020 19:05:46 +0300

Сотрудник Red Hat представил сборочную систему Goals. Выпуск GNU Make 4.3
Mon, 20 Jan 2020 10:18:42 +0300

Первый релиз wZD 1.0.0, сервера компактного хранения мелких файлов
Sun, 19 Jan 2020 14:29:36 +0300

Выпуск платформы совместной разработки OneDev 3.0
Sun, 19 Jan 2020 10:34:21 +0300

Доступны мобильные браузеры Firefox Lite 2.1 и Firefox Preview 3.1.0
Sun, 19 Jan 2020 09:39:11 +0300

Копилефт лицензии постепенно вытесняются пермиссивными
Sat, 18 Jan 2020 22:55:51 +0300

Бета-выпуск интегрированного набора интернет-приложений SeaMonkey 2.53
Sat, 18 Jan 2020 22:07:53 +0300

Разработчик Rust-фреймворка actix-web удалил репозиторий из-за травли
Sat, 18 Jan 2020 20:17:10 +0300

Критические уязвимости в WordPress-плагинах, имеющих более 400 тысяч установок
Sat, 18 Jan 2020 12:26:09 +0300

Представлена платформа Nextcloud Hub для организации совместной работы
Sat, 18 Jan 2020 10:33:49 +0300

IP Управляющие ICMP, ARP, IGMP Транспортные UDP, TCP Работа ТСР RFC
Управляющие протоколы Интернета

Помимо протокола IP, используемого для передачи данных, в Интернете есть несколько управляющих протоколов, применяемых на сетевом уровне, к которым относятся ICMP, ARP, IGMP, RARP, ВООТР и DHCP. В данном разделе мы рассмотрим их все по очереди.

За работой Интернета следят маршрутизаторы. Когда случается что-то неожиданное, о происшествии сообщается по протоколу ICMP (Internet Control Message Protocol — протокол управляющих сообщений Интернета), используемому также для тестирования Интернета. Протоколом ICMP определено около дюжины типов сообщений. Наиболее важные из них приведены ниже. Каждое ICMP-сообщение вкладывается в IP-пакет.

Основные типы ICMP сообщений

Тип сообщения

Описание

Адресат недоступен

Пакет не может быть доставлен

Время истекло

Время жизни пакета упало до нуля

Проблема с параметром

Неверное поле заголовка

Гашение источника

Сдерживающий пакет

Переадресовать

Научить маршрутизатор географии

Запрос отклика

Спросить машину, жива ли она

Отклик

Да, я жива

Запрос временного штампа

То же, что и Запрос отклика, но с временным штампом

Отклик с временным штампом

То же, что и Отклик, но с временным штампом

Сообщение АДРЕСАТ НЕДОСТУПЕН используется, когда подсеть или маршрутизатор не могут обнаружить пункт назначения или когда пакет с битом DF (не фрагментировать) не может быть доставлен, так как путь ему преграждает сеть с маленьким размером пакетов.

Сообщение ВРЕМЯ ИСТЕКЛО посылается, когда пакет игнорируется, так как его счетчик уменьшился до нуля. Это событие является признаком того, что пакеты двигаются по замкнутым контурам, что имеется большая перегрузка или установлено слишком низкое значение таймера.

Сообщение ПРОБЛЕМА ПАРАМЕТРА указывает на то, что обнаружено неверное значение в поле заголовка. Это является признаком наличия ошибки в программном обеспечении хоста, отправившего этот пакет, или промежуточного маршрутизатора.

Сообщение ГАШЕНИЕ ИСТОЧНИКА ранее использовалось для усмирения хостов, которые отправляли слишком много пакетов. Хост, получивший такое сообщение, должен был снизить обороты. В настоящее время подобное сообщение редко используется, так как при возникновении перегрузки подобные пакеты только подливают масла в огонь, еще больше загружая сеть. Теперь борьба с перегрузкой в Интернете осуществляется в основном на транспортном уровне. Это будет подробно обсуждаться в главе 6.

Сообщение ПЕРЕАДРЕСОВАТЬ посылается хосту, отправившему пакет, когда маршрутизатор замечает, что пакет адресован неверно.

Сообщения ЗАПРОС ОТКЛИКА и ОТКЛИК посылаются, чтобы определить, достижим ли и жив ли конкретный адресат. Получив сообщение ЗАПРОС ОТКЛИКА, хост должен отправить обратно сообщение ОТКЛИК. Сообщения ЗАПРОС ВРЕМЕННОГО ШТАМПА и ОТКЛИК С ВРЕМЕННЫМ ШТАМПОМ имеют то же назначение, но при этом в ответе проставляется время получения сообщения и время отправления ответа. Это сообщение используется для измерения производительности сети.

Кроме перечисленных сообщений, определены и другие. Их полный список хранится в Интернете по адресу www.iana.org/assignments/icmp-parameters.

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

Таким образом, возникает вопрос: как устанавливается соответствие IP-адресов и адресов уровня передачи данных, таких как Ethernet-адреса? Чтобы понять, как это работает, рассмотрим показанный на рисунке пример, в котором изображен небольшой университет с несколькими сетями класса С (ныне называемыми сетями класса /24). На рисунке мы видим две сети Ethernet: одна на факультете кибернетики с IP-адресом 192.31.65.0, а другая — с IP-адресом 192.31.63.0 на электротехническом факультете. Они соединены кольцом FDDI с IP-адресом 192.31.60.0. У каждой машины сетей Ethernet есть уникальный Ethernet-адрес (на рисунке — от El до Е6), а у каждой машины кольца FDDI есть FDDI-адрес (от F1 до F3).

Рассмотрим, как пользователь хоста 1 посылает пакет пользователю хоста 2. Допустим, отправителю известно имя получателя, например, al@eagle.uni.ru Сначала надо найти IP-адрес для хоста 2, известного как eagle.uni.ru Этот поиск осуществляется службой имен доменов DNS (Domain Name System). На данный момент мы просто предположим, что служба DNS возвращает IP-адрес для хоста 2 (192.31.65.5).

Теперь программное обеспечение верхнего уровня хоста 1 создает пакет со значением 192.31.65.5 в поле Адрес получателя и передает его IP-программе для пересылки. Программное обеспечение протокола IP может посмотреть на адрес и увидеть, что адресат находится в его собственной сети, но ему нужно как-то определить Ethernet-адрес получателя. Одно из решений состоит в том, чтобы хранить в системе конфигурационный файл, в котором были бы перечислены соответствия всех локальных IP-адресов Ethernet-адресам. Такое решение, конечно, возможно, но в организациях с тысячами машин обновление этих файлов потребует много времени и подвержено ошибкам.

Более удачное решение заключается в рассылке хостом 1 по сети Ethernet широковещательного пакета с вопросом: «Кому принадлежит IP-адрес 192.31.65.5?» Этот пакет будет получен каждой машиной сети Ethernet 192.31.65.0, а хост 2 ответит на вопрос своим Ethernet-адресом Е1. Таким образом, хост 1 узнает, что IP-адрес 192.31.65.5 принадлежит хосту с Ethernet-адресом Е2. Протокол, который задает подобный вопрос и получает ответ на него, называется ARP (Address Resolution Protocol — протокол разрешения адресов) и описан в RFC 826. Он ра­ботает почти на каждой машине в Интернете.

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

Затем программное обеспечение протокола IP хоста 1 создает Ethernet-кадр для Е2, помещает в его поле полезной нагрузки IP-пакет, адресованный 192.31.65.5, и посылает его по сети Ethernet. Сетевая карта Ethernet хоста 2 обнаруживает кадр, замечает, что он адресован ей, считывает его и вызывает прерывание. Ethernet-драйвер извлекает IP-пакет из поля полезной нагрузки и передает его IP-программе, которая, видя, что пакет адресован правильно, обрабатывает его.

Существуют различные методы повышения эффективности протокола АRР. Во-первых, машина, на которой работает протокол ARP, может запоминать результат преобразования адреса на случай, если ей придется снова связываться с той же машиной. В следующий раз она найдет нужный адрес в своем кэше, сэкономив, таким образом, на рассылке широковещательного пакета. Скорее всего, хосту 2 понадобится отослать ответ на пакет, что также потребует от него обращения к ARP для определения адреса отправителя. Этого обращения можно избежать, если отправитель включит в ARP-пакет свои IP- и Ethernet-адреса. Когда широковещательный ARP-пакет прибудет на хост 2, пара (192.31.65.7, El) будет сохранена хостом 2 в ARP-кэше для будущего использования. Более того, эту пару адресов могут сохранить у себя все машины сети Ethernet.

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

Чтобы разрешить изменение соответствий адресов, например, при поломке и замене сетевой карты на новую (с новым Ethernet-адресом), записи в ARP-кэше должны устаревать за несколько минут.

Посмотрим снова на рис. 5.53. На этот раз хост 1 хочет послать пакет хосту 4 (192.31.63.8). Обращение к ARP не даст результата, так как хост 4 не увидит широковещательного пакета (маршрутизаторы не переправляют широковещательные пакеты Ethernet-уровня). Есть два решения данной проблемы. Во-первых, маршрутизатор факультета кибернетики можно настроить так, чтобы он отвечал на ARP-запросы к сети 192.31.63.0 (а также к другим местным сетям). В таком случае хост 1 добавит в свой ARP-кэш строку (192.31.63.8, ЕЗ) и будет счастлив посылать весь трафик для хоста 4 локальному маршрутизатору. Такой метод называется ARP-прокси. Второе решение состоит в том, чтобы хост 1 сразу выявлял нахождение адресата в удаленной сети и посылал весь внешний трафик по Ethernet-адресу, обрабатывающему все пакеты для удаленных адресатов, то есть по адресу маршрутизатора ЕЗ. В этом случае маршрутизатору факультета кибернетики не нужно знать, какую именно удаленную сеть он обслуживает.

В любом случае хост 1 помещает IP-пакет в поле полезной нагрузки Ethernet-кадра, адресованного маршрутизатору ЕЗ. Получив Ethernet-кадр, маршрутизатор факультета кибернетики извлекает из поля полезной нагрузки IP-пакет и ищет его IP-адрес в своих таблицах. Он обнаруживает, что пакеты, адресованные сети 192.31.63.0, должны пересылаться маршрутизатору 192.31.60.7. Если ему еще не известен FDDI-адрес маршрутизатора 192.31.60.7, то он посылает по кольцу широковещательный ARP-пакет и узнает, что нужный ему адрес F3. Затем он помещает IP-пакет в поле полезной нагрузки FDDI-кадра, адресованного маршрутизатору F3, и отправляет его по кольцу.

Когда кадр попадает на маршрутизатор факультета электротехники, FDDI-драйвер извлекает из поля полезной нагрузки IP-пакет и передает его IP-программе, которая понимает, что этот пакет следует переслать 192.31.63.8. Если такого IP-адреса еще нет в ARP-кэше, маршрутизатор посылает широковещательный ARP-запрос по сети Ethernet факультета электротехники и узнает, что нужный ему адрес принадлежит хосту E6, поэтому он создает Ethernet-кадр, адресованный хосту Е6, помещает IP-пакет в поле полезной нагрузки и передает его по сети Ethernet. Получив Ethernet-кадр, хост 4 извлекает из поля полезной нагрузки IP-пакет и передает его IP-программе для обработки.

Пересылка хостом 1 пакетов в удаленную сеть по глобальной сети работает аналогично, с той разницей, что на этот раз маршрутизатор факультета кибернетики узнает из своих таблиц, что пакет следует переслать маршрутизатору глобальной сети, чей FDDI-адрес равен F2.

Групповое вещание (multicast) требует некоторых расширений в протоколах узлов, они описаны в RFC 1112. Там же описан и простой протокол IGMP (Internet Group Management Protocol — протокол управления группами). Поддержка группового вещания узлами может быть реализована на трех уровнях:

— не поддерживается.
— поддерживается передача групповых сообщений (необходимые допол­нительные средства минимальны).
— поддерживается передача и прием.

Каждый из адресов диапазона класса D (224.0.0.0—239.0.0.0) представляет идентификатор вещательной группы. Группы делятся на постоянные (permanent) и временные (transient). Адреса постоянных групп назначаются административно. Для временных групп адреса выделяются динамически из незанятых постоянными. Адрес 224.0.0.0 использовать запрещается. Адрес 224.0.0.1 (all-hosts address) используется как общий адрес для всех абонентов группового вешания, непосредственно подключенных к конкретной подсети. Адрес 224.0.0.2 (all routers) используется для обращения ко всем маршрутизаторам IGMP. Эти два адреса служат для распространения информации по протоколу IGMP. Нет способа задать групповой адрес сразу всех узлов глобальной сети. Группы получателей формируются динамически, узел может быть членом нескольких групп.

Трафик вещающего узла передается всем членам группы без гарантии доставки, но с «максимальным старанием». Передача группового трафика в сетях Ethernet использует присущий им механизм многоадресной передачи. При этом младшие 23 бита идентификатора многоадресной IP-группы помещаются в 23 младших бита группового адреса Ethernet 01-00-5Е-00-00-00. Поскольку IP-идентификатор имеет разрядность 28 бит (4 бита занимает признак класса D), возможно, что в одну группу Ethernet будут попадать сообщения нескольких (до 32) IP-групп. Это дает дополнительную нагрузку на нижний протокольный уровень узла, поскольку ему придется фильтровать приходящие пакеты.

Распространение межсетевого группового трафика управляется протоколом IGMP. Все сообщения этого протокола передаются по адресам 224.0.0.1 и 224.0.0.2, поле TTL=1, так что сообщение не выходит за пределы, доступные не­посредственно по локальному интерфейсу. Узел, желающий вступить в группу, передает сообщение Host Membership Report, в котором указывается идентификатор группы. Для верности это сообщение он повторяет 1-2 раза (подтверждений в IGMP не предусматривается). Маршрутизатор, поддерживающий IGMP, принимает это сообщение и заносит идентификатор в свою таблицу с привязкой к порту, от которого получено сообщение. Маршрутизатор периодически посылает запросы Host Membership Query, на которые отвечают узлы, считающие себя членами какой-либо группы. Если на пару опросов для определенной группы никто не отозвался, маршрутизатор исключает эту группу из своей таблицы. Для сокращения избыточного служебного трафика узлы отвечают не сразу, а через случайный интервал времени. Если за время этой задержки узел, собравшийся ответить, услышал такой же ответ от другого узла, он свой ответ аннулирует. О выходе из группы узел явно не сообщает, он просто перестает отвечать на опросы. Протокол IGMP используется и для обмена информацией об используемых группах между маршрутизаторами, поддерживающими групповую пересылку. Маршрутизаторы организуют пересылку пакетов группового вещания между портами, для которых в таблицы занесены соответствующие идентификаторы. Конечно же, распространение этого трафика контролируется и средствами сетевого администрирования.

Групповое вещание позволяет экономить трафик при количестве получателей более одного: рассылка одной и той же информации нескольким получателям обычными двухточечными средствами приводила бы к росту трафика пропорционально количеству приемников. Групповое вещание позволяет организовать аудио и видеовещание по сети передачи данных. Вышеописанные средства не страхуют от ошибочной доставки пакетов, эта страховка достигается протокольными средствами (идентификации, аутентификации, шифрования) высших протокольных уровней. Механизм динамического назначения идентификаторов групп в RFC 1112 не оговаривается, предполагается, что он должен выполняться высокоуровневыми протоколами.

После RFC 1112 появилась новая версия IGMP V.2, обратно совместимая с исходной. В версии 2 введены следующие изменения:

- Определен выбор маршрутизатора-опросчика IGMP — для каждой локальной сети им будет маршрутизатор с наименьшим IP-адресом.
- Определен новый тип сообщения — Group-Specific Query, в котором указывается список групп, принадлежность к которым интересует маршрутизатор в данный момент.
- Определено новое сообщение Leave Group, которым хост явно указывает на намерение выйти из группы (групп). Сообщение посылается по спецпальному адресу 224.0.0.2 (all routers).

Эти меры нацелены на экономию полосы пропускания — сокращение лишнего группового трафика.

Версия 3 предполагает возможность выбора источников, данные от которых интересуют групповых получателей. До сих пор, как только узлы заявляли о вхождении в какую-либо группу, маршрутизаторы доставляли им пакеты от всех источников (их может быть множество) данной группы. Теперь сообщением Inclusion Group-Source Report хост заказывает трафик интересующих источников, а сообщением Exclusion Group-Source Report отказывается от его получения. Таким образом сеть освобождается от ненужного трафика.

Для передачи группового трафика требуется сеть маршрутизаторов (и коммутаторов), поддерживающих протоколы IGMP. Поскольку' в глобальной сети на это способны далеко не все маршрутизаторы, применяют туннелированпе. Пакеты с групповыми адресами инкапсулируются в обычные одноадресные пакеты (IP-Over-IP) и в таком виде пересылаются между шлюзами. Туннели, по которым проходят инкапсулированные пакеты, соединяют шлюзы, расположенные в «островках» сети, на которых имеется полная поддержка группового вещания. В шлюзе на конце туннеля многоадресные пакеты извлекаются из одноадресных и далее рассылаются в пределах «островка» вышеописанным способом. Построение магистральной сети распространения группового трафика Multicast Backbone (MBONE), являющееся нетривиальной задачей, отметим лишь, что для передачи этого трафика используются протоколы DVMRP (Distance Vector Multicast Routing Protocol), MOSPF (Multicast OSPF) или PIM (Protocol-Independent Multicast).

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

Первым для решения проблемы был разработан протокол RARP (Reverse Address Resolution Protocol — протокол обратного определения адреса), описанный в RFC 903. Этот протокол позволяет только что загрузившейся рабочей станции разослать всем свой Ethernet-адрес и сказать: «Мой 48-разрядный Ethernet-адрес — 14.04.05.18.01.25. Знает ли кто-нибудь мой IP-адрес?» RARP-сервер видит этот запрос, ищет Ethernet-адрес в своих файлах конфигурации и посылает обратно соответствующий IP-адрес.

Использование протокола RARP лучше внедрения IP-адреса в образ загружаемой памяти, так как это позволяет использовать данный образ памяти для разных машин. Если бы IP-адреса хранились бы где-то в глубине образа памяти, каждой машине понадобился бы свой отдельный образ.

Недостаток протокола RARP заключается в том, что в нем для обращения к RARP-серверу используется адрес, состоящий из одних единиц (ограниченное широковещание). Однако эти широковещательные запросы не переправляются маршрутизаторами в другие сети, поэтому в каждой сети требуется свой RARP-сервер. Для решения данной проблемы был разработан альтернативный загрузочный протокол ВООТР. В отличие от RARP, он использует UDP-сообщения, пересылаемые маршрутизаторами в другие сети. Он также снабжает бездисковые рабочие станции дополнительной информацией, включающей IP-адрес файлового сервера, содержащего образ памяти, IP-адрес маршрутизатора по умолчанию, а также маску подсети. Протокол ВООТР описан в документах RFC 951, 1048 и 1084.

Серьезной проблемой, связанной с применением ВООТР, является то, что таблицы соответствия адресов приходится настраивать вручную. Когда к ЛВС подключается новый хост, протокол ВООТР невозможно использовать до тех пор, пока администратор сети не присвоит ему IP-адрес и не пропишет вручную в конфигурационных таблицах пару (Ethernet-адрес, IP-адрес). Для устранения влияния этого фактора протокол ВООТР был изменен и получил новое имя: DHCP (Dynamic Host Configuration Protocol — протокол динамической настройки хостов). DHCP позволяет настраивать таблицы соответствия адресов как вручную, так и автоматически. Этот протокол описан в RFC 2131 и 2132. В большинстве систем он уже практически заменил RARP и ВООТР.

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

Для отыскания своего IP-адреса загружаемая машина широковещательным способом распространяет специальный пакет DISCOVER (Поиск). Агент ретрансляции DHCP перехватывает все широковещательные пакеты, относящиеся к протоколу DHCP. Обнаружив пакет DISCOVER, он превращает его из широковещательного в одноадресный и доставляет DHCP-серверу, который может находиться и в другой ЛВС. Агенту ретрансляции необходимо знать всего одну деталь: IP-адрес DHCP-сервера.

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

НОВОСТИ: Обновление ОС Qubes 4.0.3, использующей виртуализацию для изоляц ... Thu, 23 Jan 2020 20:33:36 +0300

Сформировано обновление операционной системы Qubes 4.0.3, реализующей идею использования гипервизора для строгой изоляции приложений и компонентов ОС (каждый класс приложений и системные сервисы работают в отдельных виртуальных машинах). Для загрузки подготовлен установочный образ размером 4.6 Гб. Для работы необходима система с 4 Гб ОЗУ и 64-разрядным CPU Intel или AMD с поддержкой технологий VT-x c EPT/AMD-v c RVI и VT-d/AMD IOMMU, желательно наличие GPU Intel (GPU NVIDIA и AMD недостаточно хорошо протестированы). В новом выпуске отмечено только обновление версий программ, формирующих базовое системное окружение (dom0). Доступны шаблоны для формирования виртуальных окружений на базе Fedora 30, Debian 10 и Whonix 15.

???????@Mail.ru Opera Firefox INFOBOX - хостинг Google Chrome