Сетевой адаптер не имеет допустимых параметров настройки IP: Причины и Решения

Наличие проблем с подключением к сети Интернет – это стандартная ситуация, которая присуще всем устройствам, имеющими сетевые адаптеры (компьютеры, смартфоны, планшеты, телевизоры и т.д.).

Многие привыкли, что при отсутствии соединения, проблема решается простой перезагрузкой маршрутизатора/роутера, но что делать, если вы столкнулись с проблемой, в которой перезагрузка может не помочь?

Например, как поступить в ситуации, когда штатная диагностическая утилита указывает на отсутствие необходимых параметров настройки IP?

Об ответе на этот вопрос и пойдёт речь в рамках настоящей статьи.

Причины возникновения проблемы

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

Здесь правомерно будет выделить основные моменты, характерные для работы оборудования в целом:

• Настройки сети действительно имеют ошибки. Их возникновение может быть связано, как с деятельностью самого пользователя, так могут быть и результатом активности вирусного программного обеспечения;
• Некорректная работа драйвера сетевого оборудования;
• Наличие физической неисправности адаптера;
• Блокировка соединения антивирусным программным обеспечением, включая встроенные средства защиты;
• Блокировка соединения сторонними процессами (в том числе вирусными).

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

Но если ошибка «Сетевой адаптер не имеет допустимых параметров настройки IP» появляется постоянно, то следует предпринять следующий комплекс мер.

Решения

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

Кроме комплекса приведённых далее мер, следует определить действия, совершённых до возникновения ошибок, и которые теоретически могли привести к сбоям в работе сети.

Обновление получаемого IP-адреса

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

Для этого:

• Нажмите «WIN+S» и введите «cmd.exe»;
• Откройте «Консоль командной строки» с правами администратора;
• Поочерёдно выполните две команды:
  • ipconfig /release – эта команда, отправляющая информацию об отсутствие необходимости в дальнейшем использовании выделенного ip-адреса;
  • ipconfig /renew – эта команда сообщает DHCP-серверу о необходимости обновления ip-адреса для имеющегося адаптера (или всех активных адаптеров)

  • Закройте консоль и проверьте статус соединения.

Проверка используемых настроек подключения

Как уже было обозначено выше, на корректность работы сетевого подключения могут оказать влияние сторонние процессы, в особенности вирусное программное обеспечение.

Поэтому стоит уделить внимание проверке имеющихся настроек:

• Используя «Центр управления сетями и общим доступом» или с помощью выполнения команды «ncpa.cpl», откройте раздел «Сетевые подключения»; 

• Выберите активный адаптер, с которым и возникли рассматриваемы сбои, и откройте его «Свойства»; 

• В открывшемся окне выберите «IP версии 4 (TCP/IPv4) и нажмите кнопку «Свойства»; 

• Далее, всё зависит от того, что вы увидите и какой используете тип подключения.

Проверьте все вкладки на наличие подозрительных адресов и значений.

Если у вас активно автоматическое получение IP-адреса , то попробуйте прописать его вручную, за основу взяв адрес роутера. Например, доступ к web-интерфейсу вы получаете по адресу «192.168.0.1», тогда укажите «192.168.0.20», а в основной шлюз пропишите адрес роутера.

Если обратная ситуация, то попробуйте сменить получение IP на автоматическое, предварительно запомнив указанные там значения.

Кроме того, можно попробовать прописать вручную адреса DNS-серверов, например, публичные DNS Google – 8.8.8.8 и 8.8.4.4. 

Сброс параметров TCP/IP

Данный вариант может пригодиться, если вы нашли в параметрах из шага выше что-то подозрительное.

Реализовать его в рамках операционной системы Windows 10 можно двумя способами:

Но предварительно убедитесь, что вам известны значения настроек сети, особенно если у вас построена локальная сеть и её обслуживанием занимается администратор!

Первый — «Использование раздела «Параметры»

:

• Нажмите «Пуск» — «Параметры» — «Сеть и Интернет»; 

• В разделе «Состояние» пролистайте список вниз и найдите кнопку «Сброс сети»; 

• В следующем окне нажмите на кнопку «Сбросить сейчас».

Второй – «Использование командной строки»:

• Откройте командную строку с правами администратора;
• По порядку выполните три команды: 
  • netsh int ip reset
  • netsh int tcp reset
  • netsh winsock reset

• Закройте консоль и перезагрузите компьютер.

Если после перезагрузки доступ к сети восстановлен не был, попробуйте ещё раз воспользоваться утилитой «Диагностика неисправностей» и проверить не поменялась ли причина.

Дополнительные варианты решений

Как показывает практика, в большинстве случае помогает именно сброс параметров TCP/IP, но это может устранить саму проблему, но не причину её появления.

Каждому пользователю стоит обратить внимание на следующее:

1. Установлено ли у вас программное обеспечение, которое использует в своих целях сетевое подключение. Некоторые пользователи смартфонов от компании «Apple» отмечаются, что проблема была решена после удаления программы «Bonjour».

Это же относится и к другим утилитам, например, к различным оптимизаторам операционной системы и клиентам.

2. Попробуйте отключить антивирусное программное обеспечение, включая Firewall. 

3. Попробуйте вручную удалить сетевой адаптер из «Диспетчера устройств», после чего нажать на кнопку «Обновить конфигурацию оборудования» и/или перезагрузить компьютер.

4. Проверьте актуальность драйверов программного обеспечения, подробно о том, как это сделать можно прочитать в данной статье.

5. Проверьте наличие всех важных обновлений для операционной системы.

Заключение

В заключение, приведём несколько ссылок на статьи, которые могут оказаться полезными в решение рассмотренной проблемы:

Как отключить автонастройку IPv4-адреса в Windows

Иногда пользователи Windows могут сталкиваться с таким явлением как автонастройка IPv4-адреса. В результате происходит автоматическая подмена прописанного в настройках IP адреса. Обнаружить это можно набрав в коносли команду ipconfig /all и получив в ответ следующее сообщение:

Автонастройка IPv4-адреса: 169.254.254.183 (Основной)

Подмена происходит из-за технологии APIPA (Automatic Private IP Addressing). Используется она операционной системой Windows чтобы присвоить компьютеру IP адрес (вида 169.254.x.x) если он не может достучаться до DHCP сервера, указанного в настройках сетевого адаптера.

Чтобы отключить автонастройку IPv4 добавьте параметр DWORD «IPAutoconfigurationEnabled» со значением «0x0» в раздел реестра:

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\Adapter GUID]

Adapter GUID — это идентификатор сетевой карты. В этом разделе системного реестра хранятся её настройки.

Если параметра «IPAutoconfigurationEnabled» нет, то автонастройка IPv4 осуществляется по умолчанию.

Если при отключении автонастройки сетевая карта перестает выдавать IP-адрес, то перейдите снова в указанный ключ реестра, найдите там параметр «IPAddress» и пропишите ему в качестве значения нужный IP.

Ещё автонастройка может срабатывать если в локальной сети уже есть компьютер с IP адресом, который назначен сетевому адаптеру. В случае подобного дублирования просто смените адрес.

Andy Si

20 мая 2013 г.

74440

Обнаружен конфликт IP-адресов Windows. Что делать?

Не мало разных ошибок можно увидеть в Windows. И сегодня я расскажу о решении ошибки «Обнаружен конфликт IP-адресов Windows», которую можно часто увидеть при подключении к интернету. В том числе через роутер. В Windows 10, Windows 8 и Windows 7, в окне с ошибкой можно прочитать простое и понятное описание: «В этой сети уже есть компьютер с таким-же IP-адресом».

А вот само окно с ошибкой:

И ошибка в старой, доброй Windows XP:

Такая ошибка чаще всего появляется при подключении к маршрутизатору (к локальной сети). Дома, или где-то на работе. Появление ошибки означает, что ваш компьютер пытается получить IP-адрес, который уже занят другим устройством в сети. Поэтому и возникает конфликт IP-адресов. Ошибка на самом деле редкая, так как по умолчанию роутер автоматически раздает IP-адреса. И конфликта быть не может. Но, даже если маршрутизатор раздает IP автоматически (за это отвечает DHCP сервер), а вы на компьютере по какой-то причине прописали статический IP-адрес, который уже занят другим устройством, то появится ошибка «Обнаружен конфликт IP-адресов Windows».

Важный момент! Если вы столкнулись с этой проблемой не у себя дома, а где-то на работе, то не советую менять какие-то настройки самостоятельно. Лучше обратится к тому, кто отвечает за работу этой сети.

Ну и несколько советов, прежде всем перейти к настройкам:

• Сначала нужно просто перезагрузить маршрутизатор и компьютер.
• Если интернет подключен напрямую к компьютеру (без роутера), то можете попробовать отключить сетевой кабель и подключить обратно. Если это не поможет, то обратитесь в поддержку своего провайдера. Скорее всего конфликт IP-адресов возник по их вине.
• В окне «Сетевые адаптеры» можно попробовать отключить адаптер «Сетевое подключение». В Windows 10 он называется «Ethernet». И включить его обратно.

Если все это не помогает, нужно проверить настройки IP для сетевого адаптера. Там есть два варианта: выставить автоматическое получение адресов, и если это не поможет, то прописать статические адреса.

Как исправить ошибку с конфликтом IP-адресов в Windows 10, 8, 7, XP

Зайдите в «Центр управления сетями и общим доступом» и перейдите в «Изменение адаптеров адаптера».

Дальше нажмите правой кнопкой мыши на адаптер «Сетевое подключение», или «Ethernet» и откройте «Свойства».

Нажмите на пункт «IP версии 4 (TCP/IPv4)», затем нажмите на кнопку «Свойства». Если у вас там выставлены какие-то параметры, то установите автоматическое получение IP и DNS. Вот так:

Перезагрузите компьютер. Если после этого интернет не заработал, или у вас там было изначально выставлено автоматическое получение, то можно попробовать задать необходимые параметры вручную.

Статические IP-адреса: как вариант решения конфликта

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

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

• IP-адрес — здесь нужно указать адрес, который наш компьютер получит у роутера. Нужно сначала узнать IP-адрес роутера. Скорее всего, это 192.168.1.1, или 192.168.0.1. Затем, сменить последнюю цифру. Желательно прописать выше 100. Например: если у моего роутера IP-адрес 192.168.1.1, то я прописываю 192.168.1.110.
• Маска подсети – пропишется автоматически.
• Основной шлюз – IP-адрес маршрутизатора. В моем случае это 192.168.1.1.
• DNS-адреса можете прописать: 8.8.8.8 / 8.8.4.4

Вот так:

Думаю, эти действия помогли вам избавится от ошибки, и интернет на вашем компьютере все таки заработал. Пишите в комментариях, задавайте вопросы!

Link-local address — Википедия

Материал из Википедии — свободной энциклопедии

Текущая версия страницы пока не проверялась опытными участниками и может значительно отличаться от версии, проверенной 4 июня 2015; проверки требуют 23 правки. Текущая версия страницы пока не проверялась опытными участниками и может значительно отличаться от версии, проверенной 4 июня 2015; проверки требуют 23 правки.

Link-Local Address — адреса сети, которые предназначены только для коммуникаций в пределах одного сегмента местной сети или магистральной линии. Они позволяют обращаться к хостам, не используя общий префикс адреса.

Подсети link-local не маршрутизируются: маршрутизаторы не должны отправлять пакеты с адресами link-local в другие сети.

Адреса link-local часто используются для автоматического конфигурирования сетевого адреса, в случаях, когда внешние источники информации об адресах сети недоступны.

Типичное использование link-local адресов — автоматическое конфигурирование IP-адресов в локальных сетях Ethernet. Адрес из диапазона link-local назначается ОС хоста автоматически в случае недоступности других источников информации, например сервера DHCP.

Диапазоны и правила формирования адресов link-local[править | править код]

IPv4

Для IPv4 в качестве link-local адресов выделена подсеть 169.254.0.0/16 (за исключением первой и последней /24 подсети, зарезервированных для этого же на будущее). Согласно RFC 3927 (2.1), для link-local адресов зарезервирован блок с 169.254.1.0 по 169.254.254.255^[1].

Раздел 2.1 RFC 3927 требует, чтобы адрес формировался на основе генератора псевдослучайных чисел, инициализированного адресом MAC (при его наличии).

IPv6

Для IPv6 в качестве link-local адресов выделена подсеть FE80::/10.

Согласно RFC 4862 (5.3) и RFC 4291 (2.5.1 и Appendix A), адрес формируется на основе так называемого «идентификатора интерфейса» IEEE EUI-64, уникального для интерфейса. В сетях Ethernet для его формирования используются адрес MAC (IEEE MAC-48, EUI-48), где в середину добавляют байты 0xFF и 0xFE и инвертируют U/L-бит (второй справа) в первом байте (слева). Например, из MAC адреса 00:21:2F:B5:6E:10 получится EUI-64 02:21:2F:FF:FE:B5:6E:10.

1. ↑ Первые и последние 256 адресов в блоке 169.254/16 зарезервированы для будущего использования согласно RFC 3927 (2.1).

• RFC 3927 — Dynamic Configuration of IPv4 Link-Local Addresses
• RFC 4862 — IPv6 Stateless Address Autoconfiguration
• RFC 4291 — IP Version 6 Addressing Architecture

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

21.10.2016&nbsp windows | для начинающих

Одна из распространенных ситуаций у пользователей Windows 10, 8 и Windows 7 — неполадки с работой Интернета и сообщение о том, что сетевой адаптер (Wi-Fi или Ethernet) не имеет допустимых параметров настройки IP при использовании стандартной утилиты диагностики неполадок и устранения неисправностей сети.

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

Примечание: прежде чем выполнять описанные далее действия, попробуйте отключить ваше интернет-подключение Wi-Fi или Ethernet, а затем снова включить его. Для этого нажмите клавиши Win+R на клавиатуре, введите ncpa.cpl и нажмите Enter. Кликните правой кнопкой мыши по проблемному подключению, выберите «Отключить». После того, как оно будет отключено, тем же образом включите его. Для беспроводного соединения попробуйте также выключить и заново включить ваш Wi-Fi роутер.

Повторное получение параметров IP

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

1. Запустите командную строку от имени администратора и по порядку используйте следующие команды.
2. ipconfig /release
3. ipconfig /renew

Закройте командную строку и проверьте, была ли решена проблема.

Часто этот способ не помогает, но, одновременно, он является самым простым и безопасным.

Сброс параметров протокола TCP/IP

Первое, что следует попробовать при появлении сообщения о том, что сетевой адаптер не имеет допустимых параметров настройки IP — выполнить сброс сетевых настроек, в частности параметров протокола IP (и WinSock).

Внимание: если у вас корпоративная сеть и настройкой Ethernet и Интернета занимается администратор, выполнение следующих действий нежелательно (можно сбросить какие-то специфичные параметры, необходимые для работы).

Если у вас Windows 10, я рекомендую воспользоваться предусмотренной в самой системе функцией, познакомиться с которой можно здесь: Сброс сетевых настроек Windows 10.

Если у вас другая версия ОС (но подойдет и для «десятки»), то выполните следующие действия.

1. Запустите командную строку от имени администратора, после чего по порядку выполните следующие три команды.
2. netsh int ip reset
3. netsh int tcp reset
4. netsh winsock reset 
5. Перезагрузите компьютер

Также для сброса параметров TCP/IP в Windows 8.1 и Windows 7 вы можете использовать утилиту, доступную для загрузки на официальном сайте Майкрософт: https://support.microsoft.com/ru-ru/kb/299357

После перезагрузки компьютера, проверьте вернулась ли работоспособность Интернета и, если нет, показывает ли диагностика неполадок то же сообщение, что и раньше.

Проверка параметров IP подключения Ethernet или Wi-Fi

Еще один вариант — проверить параметры настройки IP вручную и изменить их при необходимости. После выполнения изменений, указанных в отдельных пунктах далее, проверяйте, была ли устранена проблема.

1. Нажмите клавиши Win+R на клавиатуре и введите ncpa.cpl
2. Кликните правой кнопкой мыши по соединению, для которого нет допустимых параметров настройки IP и выберите пункт «Свойства» в контекстном меню.
3. В окне свойств в списке протоколов выберите «Протокол интернета версии 4»  и откройте его свойства.
4. Проверьте — установлено ли автоматическое получение IP адреса и адресов DNS серверов. Для большинства провайдеров это должно быть так (но если ваше подключение использует Static IP, то менять этого не нужно). 
5. Попробуйте вручную прописать DNS серверы 8.8.8.8 и 8.8.4.4
6. Если вы подключаетесь через Wi-Fi роутер, то попробуйте вместо «получать IP автоматически» вручную прописать IP адрес — тот же, что у роутера, с измененным последним числом. Т.е. если адрес роутера, например, 192.168.1.1, пробуем прописать IP 192.168.1.xx (лучше не используйте в качестве этого числа 2, 3 и другие близкие к единице — они могут уже быть выделены другим устройствам), маска подсети установится автоматически, а основной шлюз — адрес роутера.
7. В окне свойств подключения попробуйте выключить TCP/IPv6.

Если же ничто из этого не оказалось полезным, попробуйте варианты из следующего раздела.

Дополнительные причины того, что сетевой адаптер не имеет допустимых параметров настройки IP

Помимо описанных действий, в ситуациях с «допустимыми параметрами IP» виновниками может оказаться сторонние программы, в частности:

• Bonjour — если вы устанавливали какое-то ПО от Apple (iTunes, iCloud, QuickTime), то с большой вероятностью в списке установленных программ у вас есть Bonjour. Удаление этой программы может решить описываемую проблему. Подробнее: Программа Bonjour — что это?
• Если на вашем компьютере установлен сторонний антивирус или фаервол, попробуйте временно отключить их и проверить, исчезла ли неполадка. Если да — попробуйте удалить, а затем снова установить антивирус.
• В диспетчере устройств Windows попробуйте удалить ваш сетевой адаптер, после чего в меню выбрать «Действие» — «Обновление конфигурации оборудования». Произойдет переустановка адаптера, иногда это срабатывает.
• Возможно, полезной окажется инструкция Не работает интернет на компьютере по кабелю.

На этом всё. Надеюсь, какой-то из способов подошел для вашей ситуации.

А вдруг и это будет интересно:

Процесс получения IP-адреса по DHCP. Как взаимодействуют DHCP-клиент и DHCP-сервер.

Привет, посетитель сайта ZametkiNaPolyah.ru! Продолжаем изучать основы работы компьютерных сетей. Продолжаем разбираться с протоколом DHCP в рамках подготовки к CCNA. На этот раз мы посмотрим на процесс получения IP-адреса по DHCP, а также разберемся с тем как и при помощи каких сообщений происходит взаимодействие между DHCP-сервером и DHCP-клиентом.

9.2.1 Введение

Содержание статьи:

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

9.2.2 Упрощенный алгоритм взаимодействия DHCP-сервера и DHCP-клиента.

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

Первое и важное условие нормальной работы DHCP-сервера заключается в том, что он должен находиться в одной подсети/канальной среде с клиентом, иначе ничего работать не будет. В дальнейшем мы убедимся, что это не всегда так и если сервер и клиент находятся в разных подсетях, то им необходим посредник, который называется DHCP Relay Agent. Ну а теперь перейдем к алгоритму взаимодействия между клиентом и сервером по DHCP.

1. Как и в любой порядочной схеме клиент-сервер, взаимодействие по DHCP инициирует клиент. Когда клиент просыпается и осознает, что сетевые настройки нужно получить по DHCP, он формирует специальное широковещательное сообщение, называемое DHCPDISCOVER, этим сообщением он пытается найти DHCP-сервер в своей сети. Вы же помните, что широковещательные сообщения в протоколе Ethernet не выходят за пределы канальной среды?
2. Если в канальной среде с клиентом находится сервер, то он получит DHCPDISCOVER, если сервера нет, то, возможно, это сообщение получит DHCP Relay Agent и перешлет его серверу, если нет и его, то клиент обломится.
3. Но представим, что сервер есть и сообщение он получил. В ответ на DHCPDISCOVER сервер сформирует сообщение, называемое DHCP-предложением или на древнерусском DHCPOFFER. В сообщение DHCPOFFER содержится IP-адрес, который сервер хочет предложить клиенту и другая информация, которая может пригодиться. Сообщение DHCPOFFER может быть отправлено сервером как broadcast, так и unicast, ведь мак-адрес клиента сервер уже изучил. От чего это зависит мы увидим чуть позже.
4. В нашей сети может быть несколько DHCP-серверов, и они все могут получить DHCPDISCOVER от клиента и направить ему DHCPOFFER. Естественно, клиент их все получит и обычно выберет первое неконфликтное предложение от одного единственного сервера. В ответ на выбранный DHCPOFFER клиент сформирует сообщение DHCPREQUEST, из которого будет понятно, с каким сервером он станет дальше дружить. DHCPREQUEST – широковещательное сообщение, это сделано специально, чтобы все сервера в сети видели, какие параметры выбрал клиент и с кем он дальше решил работать.
5. Все серверы получают DHCPREQUEST, но только выбранный сервер продолжит взаимодействие с клиентом, на DHCPREQUEST сервер ответит сообщением DHCPACK, которое служит подтверждением или, если хотите, официальным разрешением от сервера на использование клиентом выбранного IP-адреса.
6. Как только клиент получил сообщение DHCPACK, он переходит в рабочее состояние и смело пользуется IP-адресом.

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

9.2.1 DHCP сообщения, которыми обмениваются клиент и сервер, когда клиент пытается получить IP-адрес

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

9.2.3 DHCP-клиент и DHCP-сервер, базовая настройка.

Теперь нам нужно закрепить полученные знания о взаимодействие между DHCP-сервером и DHCP-клиентом на практике, для этого мы расчехлим Cisco Packet Tracer и соберем простую схему, которая показана ниже.

9.2.2 Схема сети для демонстрации взаимодействия между DHCP-клиентом и сервером

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

Перед началом настройки схемы не забудьте переключить Cisco Packet Tracer в режим симуляции. Роутеру и двум серверам нужно будет назначить статический IP-адрес, так как здесь адреса ни при каких сбоях не должны измениться, роутер для клиентов является основным шлюзом, а DHCP-сервера источником настроек. Клиент должен получать настройки динамически.

9.2.3.1 Настройка протокола DHCP на сервере и клиенте в Cisco Packet Tracer

Покажу настройку только одного DHCP-сервера, на втором настройки должны быть идентичны, за исключением IP-адреса. Для начала назначим серверу IP-адрес вручную, сам себе сервер выдавать IP-адреса не умеет.

9.2.3 Настройки протокола IP на DHCP сервере

Серверу я не стал давать адрес шлюза по умолчанию, так как серверу не нужен доступ в Интернет, где найти IP настройки для устройств в Cisco Packet Tracer, вы уже должны знать, показывал и не один раз. Следующим пунктом нашей программы будет настройка DHCP на сервере. Для этого перейдите на вкладку Services и в левом меню выберете DHCP.

9.2.4 Настройки DHCP на сервере

Обратите внимание, здесь уже заполнены поля Start IP Address и Subnet Mask, мы же еще помним, что и клиент, и сервер должны находиться в одной канальной среде, чтобы было всё гуд. Когда мы назначили IP-адрес на интерфейс сервера, Cisco Packet Tracer сам назначил значения в эти поля за нас, если IP-адрес не назначать, то в этих полях будут унылые нули.

Предлагаю пока не трогать эти поля, а изменить значения у полей Pool Name и Default Gateway. Мои настройки показаны ниже.

9.2.5 Продолжаем настраивать DHCP сервер

Все изменения я выделил, для начала был включен DHCP при помощи чекбокса, затем я дал имя новому пулу IP-адресов, который сервер будет использовать для выдачи клиентам, а также была указана дополнительная опция в виде адреса шлюза по умолчанию. Чтобы пул был добавлен, следует нажать кнопку Add, после чего внизу у нас появится два пула IP-адресов: один – этот тот, что создали мы, второй – это тот, что был создан Cisco Packet Tracer автоматически. Чтобы не было проблем, удалите второй, для этого его нужно выделить и нажать на кнопку Remove, если не получится удалить автоматический пул, настройте его так, как я показал и удалите свой собственный. На втором сервере настройки нужно сделать аналогичными, разница будет только в IP-адресе, который вы назначите серверу.

Итак, что мы сделали, чтобы настроить DHCP-сервер, а сделали мы следующее:

1. Настроили IP-адрес на интерфейсе сервера.
2. Создали пул IP-адресов, из которого сервер будет выдавать настройки клиенту.
3. Дали этому пулу имя, так как пулов у DHCP-сервера может быть несколько.
4. Указали начальный IP-адрес пула (поле Start IP Address), это означает, что сервер будет пытаться выдавать IP-адреса, начиная с 192.168.0.1 (а не с 192.168.0.0, ведь сервер понимает, что это номер сети, а также он немного в курсе о том, что в 21 веке мы все используем маску подсети переменной длины, а про классовые сети мы все уже забыли).
5. Также мы дали указание серверу выдавать две опции: маску подсети и IP-адрес шлюза по умолчанию.

Собственно, это всё, что нам сейчас необходимо. Сейчас мы сконфигурировали DHCP-сервер в режиме автоматической выдачи динамических IP-адресов, для нас этот режим самый интересный.

9.2.3.2 Настройки DHCP на клиенте

Настройка DHCP на клиенте гораздо проще, нужно только поставить галочку напротив «Получать IP-адрес по DHCP» и забыть про утомительный ручной труд.

9.2.6 Настройка протокола DHCP на клиенте

Фразы «Гибкая настройка» и Cisco Packet Tracer плохо совместимы, в реальных операционных системах вы сможете задать: какие параметры рабочая станция должна получить по DHCP, а какие параметры вы можете ввести своими руками. Но это нам сейчас не интересно, нам важно разобраться с тем, как клиент получает IP-адрес от DHCP сервера и это мы сделаем. Настройка протокола DHCP на клиенте на этом закончена.

9.2.4 Как клиент получает IP-адрес по DHCP

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

9.2.7 Клиент сформировал сообщение DHCPDISCOVER

На зеленый пакет, сформированный сервером, не обращайте внимание. Нас интересует желтый пакет, который сформировал клиент, это и есть DHCPDISCOVER, давайте на него посмотрим.

9.2.8 Сообщение DHCPDISCOVER в Cisco Packet Tracer

Здесь сразу видно, что пртокол DHCP работает на прикладном уровне моделей OSI 7 и TCP/IP. Также тут видно, что клиент еще не разу не получал IP-адрес от сервера и даже не знает, где этот сервер находится. На транспортном уровне протокол DHCP инкапсулируется в UDP дейтаграммы, когда клиент делает запрос серверу, то в качестве порта источника он выбирает 68 порт, а в качестве порта назначения используется 67 порт.

Клиент не знает IP-адрес сервера, да и своего у него еще нет, поэтому на сетевом уровне в качестве IP-адреса источника он использует IP-адрес 0.0.0.0, а в качестве IP-адреса назначения используется 255.255.255.255. Мы видим, что это широковещательный запрос.

На канальном уровне клиент указывает свой мак-адрес в качестве источника и широковещательный мак-адрес в качестве назначения. Ниже показана структура пакета DHCPDISCOVER, но с ней мы будем разбираться на примере дампа Wireshark.

9.2.9 Структура пакета DHCPDISCOVER в Cisco Packet Tracer

А сейчас продолжим разбираться и посмотрим, что будет, когда запрос DHCPDISCOVER дойдет до серверов.

9.2.10 Запрос DHCPDISCOVER дошел до всех участников канальной среды

Здесь мы видим, что DHCPDISCOVER, посланный клиентом, дошел до всех участников канальной среды, что и не мудрено, ведь он широковещательный, но этот запрос оказался интересным только двум нашим DHCP-серверам. Когда сервер получил DHCPDISCOVER он понял, что в сети появился клиент, которому нужно выдать IP-адрес, сервер смотрит на пул IP-адресов, который у него есть и ищет свободный адрес, обычно это процесс упорядоченный и клиенту будет выдан первый свободный адрес из пула.

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

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

ARP-запрос – это зеленый пакет, на котором нет значка паузы. Наши сервера настроены одинаково, базы данных у них сейчас одинаковые, поэтому и ARP-запросы они делают одинаковые, сам запрос показан ниже.

9.2.11 DHCP-сервер делает ARP запрос, чтобы проверить занятость IP-адреса

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

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

9.2.13 ARP-запрос от DHCP сервера, на который никто не ответит

Тут опять же, всё зависит от конкретного DHCP-сервера, ARP-запрос может быть повторен, а после него сервер может еще и попробовать опросить адрес по ICMP, все это нужно, чтобы убедиться, что адрес еще никто не занял, а только после этого формировать сообщение DHCPOFFER.

9.2.14 Сообщение DHCPOFFER от первого DHCP-сервера клиент уже получил, а от второго сервера OFFER еще в буфере коммутатора

На рисунке показано ниже, что сообщение DHCPOFFER широковещательное, хотя это бывает и не всегда так, тут учитывается два момента:

1. Клиент может сообщить DHCP-серверу о том, как он хочет получать ответ: broadcast или unicast.
2. Выбор способа доставки сообщения DHCPOFFER может зависеть от реализации самого сервера и некоторых значений в DHCP пакете.

2.15 Сообщение DHCPOFFER в Cisco Packet Tracer

В любом случае, для доставки DHCPOFFER у сервера есть возможность использовать на канальном уровне как broadcast, так и unicast, ведь мак-адрес клиента он уже изучил, когда получил сообщение DHCPDISCOVER. На рисунке показано, что клиент получил DHCPOFFER от первого сервера. DHCPOFFER второго сервера находится еще в буфере коммутатора, оба сервера предлагают клиенту адрес 192.168.0.4.

9.2.16 Внутренности пакета DHCPOFFER

Рисунок выше показывает, что при первом получении IP-адреса по DHCP в своем пакете сервер указывает свой IP-адрес, а в качестве адреса клиента используется 0.0.0.0. Поскольку это сообщение сформировано сервером, то порт источника 68, а порт назначения 67. Если сейчас заглянуть во внутренности пакета DHCPOFFER, то без всяких пояснений можно увидеть несколько интересных моментов.

Во-первых, сервер понимает, что у клиента еще нет IP-адреса, понимает сервер это потому, что в его базе данных еще нет мак-адреса клиента и нет сопоставления этого мак-адреса с IP-адресом, который был выдан. Во-вторых, мы видим, что сервер предлагает клиенту получить IP-адрес 192.168.0.4. В-третьих, в пакете DHCPOFFER сервер указывает свой IP-адрес, чтобы клиент знал, кто ему это всё предложил.

Получив DHCPOFFER клиент не забирает себе IP-адрес, сперва он должен убедиться, что этот адрес еще никто не использует, для этого он делает ARP-запрос в сеть, в данном случае ему был предложен адрес 192.168.0.4, значит и спрашивать клиент будет: кто в сети использует адрес 192.168.0.4? Клиенты не используют ICMP для проверки, им это не надо, а вот серверам надо, в дальнейшем мы поймем – в каких ситуациях это действительно необходимо.

Если клиент не получит ARP-ответ на свой запрос, то он может смело соглашаться на предложение DHCP-сервера, при этом соглашаться он будет на предложение того сервера, от которого был получен первый DHCPOFFER. Если клиент получит ARP-ответ на свой запрос, то он отправит серверу сообщение DHCPDECLINE, в котором сообщит о том, что он отказывается от его предложения, если же ARP-ответа не будет, то клиент сформирует широковещательное сообщение DHCPREQUEST и отправит его. Таким образом все сервера поймут две вещи:

1. С каким сервером клиент захотел работать.
2. На какой IP-адрес клиент согласился.

В процессе написания я столкнулся с еще одной странностью в Cisco Packet Tracer: после ARP-запроса клиент получил IP-адрес и на этом всё закончилось. Поэтому дальше только словесное описание, а потом мы его дополним дампами из Wireshark.

DHCP сервер, с которым клиент решил сотрудничать, тоже получит DHCPREQUEST и на этот REQUEST сервер должен будет выслать подтверждение в виде DHCPACK. Так сервер сообщает клиенту: пользуйся адресом на здоровье, я внес в свою базу данных информацию о том, что IP-адрес 192.168.0.4 закреплен за тобой. Сообщение DHCPACK может быть отправлено как адресно, так и широковещательно, чаще всего оно отправляется адресно.

Если в командной строке клиента сейчас выполнить команду ipconfig, то можно будет увидеть настройки, которые клиент получил от сервера.

C:\>ipconfig   FastEthernet0 Connection:(default port)   Link-local IPv6 Address………: FE80::202:17FF:FE54:C07B IP Address………………….: 192.168.0.4 Subnet Mask…………………: 255.255.255.0 Default Gateway……………..: 192.168.0.1

C:\>ipconfig       FastEthernet0 Connection:(default port)       Link-local IPv6 Address………: FE80::202:17FF:FE54:C07B   IP Address………………….: 192.168.0.4   Subnet Mask…………………: 255.255.255.0   Default Gateway……………..: 192.168.0.1

Чтобы окончательно убедиться в том, что все работает, можете попробовать пропинговать адрес шлюза по умолчанию.

C:\>ping 192.168.0.1   Pinging 192.168.0.1 with 32 bytes of data:   Reply from 192.168.0.1: bytes=32 time=1ms TTL=255 Reply from 192.168.0.1: bytes=32 time<1ms TTL=255 Reply from 192.168.0.1: bytes=32 time<1ms TTL=255 Reply from 192.168.0.1: bytes=32 time<1ms TTL=255   Ping statistics for 192.168.0.1: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 1ms, Average = 0ms

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

C:\>ping 192.168.0.1       Pinging 192.168.0.1 with 32 bytes of data:       Reply from 192.168.0.1: bytes=32 time=1ms TTL=255   Reply from 192.168.0.1: bytes=32 time<1ms TTL=255   Reply from 192.168.0.1: bytes=32 time<1ms TTL=255   Reply from 192.168.0.1: bytes=32 time<1ms TTL=255       Ping statistics for 192.168.0.1:   Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),   Approximate round trip times in milli-seconds:   Minimum = 0ms, Maximum = 1ms, Average = 0ms

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

9.2.5 Выводы

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

Как в настройках роутера присвоить статический IP адрес устройству по MAC адресу?

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

Сейчас в нескольких словах постараюсь объяснить что это такое и зачем все это делать.

Роутер, он как правило раздает IP адреса автоматически. Это делает DHCP сервер, который по умолчанию включен. Ноутбук, или телефон подключается к роутеру и получает свободный IP адрес. Как правило, в рамках от 192.168.1.100 до 192.168.1.199.

Но, иногда, возникают проблемы с такой раздачей адресов и с подключением к роутеру. Или по какой-то другой причине нужно, что бы определенное устройство получало все время один и тот же адрес в Вашей сети. Вот для этого, мы сделаем привязку IP адреса для определенного устройства. За MAC адресом например ноутбука мы закрепим какой-то определенный IP.

Закрепляем определенный IP адрес за устройством

На примере роутера TP-LINK TL-WR841N (о настройке которого я писал в этой статье).

Для начал, как всегда, нам нужно зайти в настройки роутера. Адрес 192.168.1.1,  192.168.0.1. Логин и пароль, по умолчанию admin и admin (эти данные указаны снизу маршрутизатора).

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

В настройках переходим на вкладку DHCP – DHCP Clients List (Список клиентов DHCP). Тут мы можем посмотреть все устройства, которые подключены к роутеру. Нам нужно скопировать MAC адрес нужного устройства.

Если Вы по имени не можете определить устройство, то MAC можете посмотреть на самом компьютере, телефоне, ноутбуке. Как посмотреть на ноутбуке (обычном ПК), смотрите тут. На телефоне, или планшете смотрим в настройках, в разделе о телефоне, техническая информация.

Значит, скопируйте нужный MAC адрес (выделите его и нажмите Ctrl+C), если нужное устройство подключено к маршрутизатору.

Теперь откройте вкладку DHCP – Address Reservation (Резервирование адресов). Сейчас мы зарезервируем статический IP за MAC адресом нужного нам устройства.

Нажмите кнопку “Add New…”.

• В строке MAC Address указываем адрес устройства, за которым мы хотим закрепить IP. Этот адрес мы скопировали в предыдущем пункте, или посмотрели в телефоне, ноутбуке и т. д.
• Напротив Reserved IP Address указываем собственно сам IP. Можно указать любой от 192.168.1.100 до 192.168.1.199. Например 192.168.1.110.
• Status – оставляем enabled.

Нажимаем кнопку Savе (сохранить).

Вы увидите созданное правило, которое при желании можно изменить, или удалить. Или можете создать еще одно правило для другого устройства.

Все заработает только после перезагрузки роутера!

Маршрутизаторы Asus

Как правило, в роутерах от Asus, это делается на вкладке Локальная сеть, затем вверху вкладка DHCP-сервер и внизу можно задать все необходимые параметры и нажать на кнопку добавить (+).

Правда, в Asus есть разные панели управления, но разберетесь. Ориентируйтесь по “DHCP”.

Указываем статический IP на компьютере, телефоне, планшете

После того, как Вы проделали все что я уже написал выше, при подключении к сети, ваше устройство уже будет получать определенный IP адрес.

Но можно еще задать этот адрес в параметрах для подключения к сети (часто, именно этот нюанс решает возникшие проблемы с подключением). Сейчас я покажу как это сделать на телефоне, или ноутбуке.

На телефоне, или на планшете может быть по разному. Но как правило, при подключении к сети, есть кнопка дополнительные параметры, или расширенные настройки. Нажмите на нее и выберите DHCP, статический IP и т. п.

Укажите установленный Вами IP адрес и подключитесь к сети.

На компьютере нужно зайти в Панель управления\Сеть и Интернет\Центр управления сетями и общим доступом слева выбрать Изменение параметров адаптера, затем нажать правой кнопкой мыши на Беспроводное сетевое соединение и выбрать Свойства.

А дальше сделать все как у меня на скриншоте.

Внимание! После установки таких “жестких” параметров, могут возникнуть проблемы с подключением к другим сетям. Если возникнуть проблемы, то установите получать IP автоматически.

Все! Если возникнут какие-то проблемы, спрашивайте. Сложно написать конкретную инструкцию, так как все отличается: панели управления маршрутизаторами разные, процесс подключения к Wi-Fi на телефонах так же отличается. Много разных нюансов.

Всего хорошего!