Почему при включённом dhcp после перезагрузки, пк пытается принять занятый ip-адрес?
Устроился на работу эникеем-сисадмином, без опыта. Предыдущий сотрудник уволился за полгода до моего прихода, не оставив контактов. Парк оборудования включает в себя: windows server 2012, 22 пк, 16 МФУ и пару устройств по мелочи. Сетевое оборудование - помимо сервера, работающего в режиме фтп-хранилища - два свитча l2 уровня, два маршрутизатора, 4 роутера и 4 усилка вайфай. Меняя все пароли и проверяя бэкапы на сервере, обнаружил, что предыдущий сотрудник настроил четыре жестких диска сервера в raid0 и решил (по неопытности), сделать ручной бэк и переустановить систему. Делал по какой-то инструкции из интернета и вроде все получилось. Но через примерно месяц начались проблемы с сетью. На пк пользователей начали конфликтовать айпи. Сразу оговорюсь - проблема была только на пк, мфу со статикой работают до сих пор стабильно. Начал разбираться, выяснил, что включил на сервере службу DHCP и вообще узнал про конфликт при включённом DHCP на разных устройствах. Пробежал по всем роутерам, оставил службу включенной только на одном роутере. В моменте это помогло, но где-то еще через месяц проблема начала повторяться, причем, судя по всему, только на машинах, которые не подключены напрямую к главному свитчу. То есть, например, мой пк и еще около 5 вообще не испытывают проблем с получением айпи. На остальных, при перезагрузке пк айпи сбрасывается и пытается перебором снова взять допустимый адрес, попутно перекидывая адреса с моего 192 на 169. На роутере поставил пул резервацию для статики с 200 по 250, для МФУ, с 1 до 10 для роутеров и сервера, остальное для dhcp. И каждый раз минут по 20 пользователи тратят на получение адресов. В теории, петлю я обнаружил и перенастроил, отключив службу везде кроме одного роутера. Но в командной строке при команде /renew продолжает писать про конфликт айпи. Что я делаю не так?
Для правильного вопроса надо знать половину ответа
перекидывая адреса с моего 192 на 169
169.254.0.0/16 - сеть автоконфигурации, устройство берёт себе адрес из этой сети если не прописана статика и оно не может получить его по DHCP.
Но в командной строке при команде /renew продолжает писать про конфликт айпи.
Перед /renew надо делать /release
Необходимо убедиться, что DHCP раздаётся только с одного сервера, этот сервер в одном broadcast-домене с остальными устройствами и на свитчах не включена блокировка DHCP (если они это умеют). Затем проверить конфигурацию сервера и убедиться, что пул адресов достаточен для всех устройств.
Да, про автоконфиг я понимаю, а вот про reset не знал, я писал release чтобы освободить адрес.
DHCP, как написал, отключил на всех роутерах с веб-интерфейсом и на самом сервере. Оставил только на одном роутере от Ростелекома, ZTE. Насчет свитчей еще не разобрался как они функционируют, не могу зайти в их интерфейс, хотя по логике, он должен быть, раз модели l2 уровня.
Про пул адресов - у меня стоит диапазон 70-200 что должно быть достаточно для двадцати с небольшим машин и около 50 непостоянных подключений по вайфай. Тоже проверял это. (
А, ну тогда да, делал. Но опять же, это не работает с конфликтом адресов, если я правильно все понял. Получается, схема такая - пользователь включает утром пк - с некоторым шансом (зависит от того, попадет он на незанятый адрес по нижнему пределу айпи) все ок, DHCP выдает адрес и пк автоматически попадает в сеть. И соответственно, с каждым новым сотрудником включающим пк, шанс попасть на занятый адрес возрастает и пк начинает перебор айпи. Причем доходит до верхнего предела и начинает заново перебирать, бывает. Но по карте arp -a и по списку устройств в IP scanner, и в интерфейсе роутера я вижу, что адреса свободны. Время lease в веб интерфейс ставил от одного часа до суток - одинаковый результат
Sevoran, ПК не перебирает IP. DHCP работает по другому.
Discover - Компьютер шлёт в сеть broadcast-пакет "мне нужен адрес".
Offer - Каждый DHCP-сервер, получивший этот пакет, выбирает IP-адрес либо из завязанных на MAC, либо свободный из пула и шлёт компьютеру своё предложение.
Request - Компьютер выбирает из предложенных адресов любой (обычно от того, кто ответил первым) и отправляет серверу запрос на занятие этого адрес.
ACK - Сервер отмечает у себя, что адрес зарезервирован и шлёт компьютеру подтверждение.
При этом сервер может с помощью arp-запроса предварительно проверять, что такой адрес никто не захватил статически. А может и не проверять.
Запустите на компьютере wireshark и посмотрите, что отправляется с компьютера и что ему отвечают.
Спасибо, попробую Wireshark завтра.
По поводу замечания - я понимаю о чем вы, но у меня такое ощущение, что на моменте получения запроса, dhcp сервер не выбирает свободный адрес, а шлет по очереди доступные из пула. То есть, в моменте включения пк, идет запрос от пк на получение адреса, а сервер говорит - бери *.70. Не? Тогда бери *.71 и тд, пока не попадет на свободный адрес. Говорю это потому, что при просмотре ipconfig /all я вижу следующее - условно, получает адрес *.70(Основной). Обновляю /all - получает адрес *.70(повторяющийся). Обновляю - получает адрес 169.*(основной). Обновляю - получает адрес *.71(основной). Ну и тд.
Sevoran, Возможно, у вас какие-то проблемы с DHCP-сервером. Он должен резервировать (lease) у себя выданные адреса с привязкой к MAC на заданное время и при повторном обращении в течение этого времени выдавать тот же адрес. Соответственно, выданные адреса он знает и другому он их предлагать не должен до истечения срока аренды или до явного освобождения их устройством.
Rsa97, думаю, что действительно проблемы, вот и пытаюсь понять какие.)
Для резервации ведь не нужно вручную указывать мак, верно? То есть, если условный пк1 имеет настройку "Автоматически получать ip-адрес", он получил сегодня адрес *.100 и lease стоит на 72 часа, то завтра при включении он должен получить тот же *.100? Я по маку сделал привязку только для одной машины и вне пула dhcp.
Sevoran, Всё верно. Если не настроена привязка к MAC, то всё определяется lease time. Только надо учитывать, что на сервере обычно указывается минимальное и максимальное время аренды, а клиент запрашивает желаемое им время.
Но всё-таки послушайте через wireshark, может второй сервер обнаружится.
Rsa97, "клиент запрашивает желаемое им время" - вот это не совсем понял. На сервере у меня доступно только максимальное время, если ничего не путаю, но там в одном меню все настройки dhcp-сервера, вроде бы. А что значит "Запрашивает желаемое время"?
По второму серверу - опять же, может быть, конечно, проверю обязательно еще раз, но при ipconfig /all разве не должны отображаться разные сервера в таком случае? В моем случае, когда подбирает адрес из моего днс-а, всегда отображает только один корректный адрес роутера
Sevoran, Клиент, например, запрашивает "выдели мне адрес на сутки". Сервер проверяет минимальное и максимальное время аренды и устанавливает время с учётом своих ограничений, например 6 часов.
Некоторые реализации серверов всегда ставят одно и то же время, где-то только максимум ограничивается, где-то и минимум и максимум.
при ipconfig /all разве не должны отображаться разные сервера в таком случае?
Могут отвечать два сервера, просто один всегда быстрее, с него и берёт. Тут лучше просто убедиться, что такого не происходит, чем потом ловить странные глюки.
Rsa97, а как клиент может запросить стандартными средствами айпи на время? Я думал, что айпишник, если не указано со стороны сервера иного, получается до разрыва соединения по какой-либо причине, например - выключение пк.
Да, конечно лучше убедиться. Я так, теорию пытаюсь понять
Sevoran, Выключение компьютера или разрыв соединения, сами по себе, не отменяют аренду. Для этого клиент должен явно послать команду на освобождение адреса или должно истечь время аренды.
При этом активный клиент периодически запрашивает продление аренды.
Rsa97, Итак, ситуация такая:
При первом включении одной машины с утра по arp -a я вижу, что один мак (если правильно понимаю - главный роутер с включенным dhcp), хватает несколько айпи:
По вайршарку - не совсем уверен куда смотреть, но если прав - в столбике info я вижу, что запрос "who has" на большинство айпишников отвечает похожими адресами - .54 и .184. И значений прям очень много, что наверняка не слишком хорошо:
Скорректируйте, пожалуйста, правильно ли я делаю
Sevoran, В wireshark надо поставить фильтр dhcp
Таблица arp показывает только то, что известно на момент команды. Если долго не было обращений к какому-нибудь адресу, то и информации о нём в arp-таблице не будет. А через 2-10 минут неактивности информация из таблицы удаляется.
Who has - это запрос MAC-адреса по IP. Плохо - это дублирование адреса .54 (duplicate use of).
Sevoran, У вас Decline периодически проскакивает. Это происходит, когда клиент отказывается от предложенного ему адреса из-за того, что этот адрес уже кем-то используется. В норме такого быть не должно.
Sevoran, Посмотрите содержимое пакетов с decline, там вроде должен быть адрес, от которого отказывается клиент.
Ну и найдите, почемуу у вас дублируется .54
То есть устройство делает запрос на .63 айпи, но ему говорят, что айпи занят?
А в arp -a вообще мрак -
мак занимает половину списка адресов, включая, например, серверную .10. И не знаю пока, что за 54, а вот 55 - открывает веб интерфейс некоего tp link TL-WA855RE =\
То есть устройство делает запрос на .63 айпи, но ему говорят, что айпи занят?
Нет.
DHCP-сервер .1 предлагает устройству адрес .63 (offer).
Устройство проверяет этот адрес через arp-запрос и обнаруживает, что он уже занят.
Устройство посылает серверу отказ (decline) от предложенного адреса.
Короче. Чуда не произошло, как говорится и, разумеется, сам дурак. Нашел устройство "мак занимает половину списка адресов, включая, например, серверную .10. И не знаю пока, что за 54, а вот 55 - открывает веб интерфейс некоего tp link TL-WA855RE =\" - оказывается, на одном из этажей пользователь подключил "усилитель сигнала вайфай". И, разумеется, оно автонастройкой начало раздавать айпи. Не знаю, верно ли я все понял, надо до завтра проверить, но сейчас через вайршарк и данные чище и после пары перезагрузок айпи выдается на двух машинах без проблем.
Sevoran, Теперь понятно, откуда нестандартные MACи. Смартфоны при подключении по WiFi обычно генерируют их случайно, чтобы избежать трекинга по MAC.
Если у вас управляемые свитчи, то поищите настройку DHCP snooping или её аналог. Она блокирует DHCP-offer с недоверенных портов. Правда, в таком случае, как у вас, она не поможет - если точка доступа сама раздаёт смартфонам адреса из вашей сети, то всё равно возможно дублирование адресов.
Rsa97, Ага, надо самому вникнуть разобраться в то, как грамотно настроить управляемые свитчи. Спасибо большое за советы, вайршарк в связке с айпи сканером прям помогли
Sevoran, судя по тому, что в arp-таблице несколько ip светятся с одним MAC, на повторителе включен (и скорее всего не отключаем) proxy-arp, так что одним отключением DHCP тут не обойтись и оно ещё будет стрелять. Крайне не рекомендую оставлять в сети предприятия оборудование для дома из нижнего ценового сегмента. По-хорошему от репитеров в принципе стоило бы отказаться вот как раз по таким причинам. Если сотрудникам настолько не хватает WiFi, то поставьте им туда какую-нибудь точку доступа
ElxkoT, Да, спасибо, отобрал игрушку. Это не предприятия, а личный девайс, ибо "слабый вайфай у меня тут"
Написано
Кот Абсолютный
@CityCat4 Куратор тега Сетевое оборудование
Sevoran, Проблема, с которой сталкивается каждый админ. Есть просто дураки, есть умные. А есть инициативные дураки. Первые две категории обычно в сеть не лезут - первые в силу глупости, вторые - в силу того, что понимают, что прилетит. А вот третьи - это вечная проблема. То какой-нибудь репитер-хренитер притащат, то адрес сами статикой вобьют...
Проблема это не только техническая, но и административная, это стоит начальству обозначить.
ЗЫ: вайфай контора обычно обеспечивать не обязана, разве только у него в ТД и ДИ что-то такое прописано. А то недавно одна умница тут у меня требовала чтобы ей обеспечили вайфай, чтобы она с телефона мессенджером могла в Казахстан звонить (было это уже после бана wa, но еще до бана телеги).
Кот Абсолютный, Ну да, успел уже вкусить этот момент. Вроде перебираешь все по учебникам, ищешь, где разрыв физический, прозваниваешь кабеля, все нормально. Потом выясняется, что на одном из этажей под потолком неучтенный маршрутизатор, который предыдущий сотрудник купил перед увольнением и не успел на учет поставить, а бухи забили. И знает только начальник об этой коробке)
Написано
Кот Абсолютный
@CityCat4 Куратор тега Сетевое оборудование
Sevoran, Потому и говорят - первое дело на новом месте - схема сети :)
Кот Абсолютный, Да, тут мой косяк был, конечно. Понадеялся на перечень оборудования, за которое я принял мат.ответственность. Ну это небольшое БУ, наверное, в крупных частных компаниях получше с этим, все-таки)
в крупных частных компаниях получше с этим, все-таки
Где как. Вполне может оказаться, что и там бас-фактор на каком-то участке был равен единице и теперь концов не найдёшь или пароли не узнаешь. Бардак, он везде встречается.
Но, если есть финансовая и организационная возможность, то для админа проще обеспечить централизованный WiFi, чем в очередной раз ловить глюк, потому что "умный" сотрудник принёс свою точку доступа или, что ещё хуже, роутер.
Написано
Кот Абсолютный
@CityCat4 Куратор тега Сетевое оборудование
Rsa97, Разумеется. У нас например директор принял такое решение - "для повышения удобства работы" закупили пять точек, расставили. Когда у тебя в окно видно один оборонный завод, а стоит немного пройти по корпусу - там уже светится граница "зоны безопасности" другого завода - никак по-другому :D
Написано
Кот Абсолютный
@CityCat4 Куратор тега Сетевое оборудование
Sevoran, Это от админа зависит. Кому-то плевать, в голове есть и ладно, а кто-то ответственно подходит.
у меня примерно такая же история была — главный роутер раздаёт, а часть машин всё равно 169 получает. Оказалось промежуточные роутеры в NAT-режиме работали, делали отдельные подсети, броадкаст DHCP туда не проходит. Перевёл в режим точки доступа (кабель в LAN-порт, не в WAN, NAT выключить) — заработало.
Нет-нет, я не сразу, конечно, но дошел до этого тоже, выключил на двух управляемых роутерах и nat и dhcp. Ну и да, перезагрузил их через 10 минут выключения
1. ipconfig /all
Показывает, какой dhcp сервер выдал ip адрес.
2. Пингануть dhcp сервер и по arp -a посмотреть Mac - адрес dhcp сервера.
По пункту 1,2 определяется, что нет нескольких dhcp серверов и нет повтора ip адресов у дубля dhcp.
3. Если конфликт для адреса 192, то это проблема выдачи ip. Если конфликт для адреса 169, то это означает что dhcp сервер не отвечает, а комп сам пытается найти свободный ip.
SunTechnik, По первым двум - делал, мак и айпи корректные, собственно, на паранойе проверял все маки пк, чтоб не прошляпить что-нибудь странное. Но нет, даже левых маков не было ни разу, все бились с оборудованием (ну то есть, е6, 7е и тд, все стандартно, левого не было). Единственное, что в /all был не адрес dns сервера, кроме моего, 192, были 217 и 212, но я так понял - это от ростела днсы. Не углублялся в этот момент, если честно. По третьему пункту - да, тревожит меня именно 192, на 169 все равно.
SunTechnik, странный мак - например 92:95:30:93:62:44 (достал из истории поиска)). Ну то есть, я через айпи сканер подписал большую часть постоянного оборудования в сети - материнки, терминал, сервер, кассы, МФУ - они определяются. Даже сотовые, получающие айпи по вайфаю определяются. А было пару адресов, типа вот этого, выше, но как выяснилось позже, это мак нда камеры)
Про отключить и включить на другом - наверное не лучшая идея, но как крайний вариант, пожалуй
... 22 пк, 16 МФУ и пару устройств по мелочи ...
...мой пк и еще около 5 вообще не испытывают проблем с получением айпи. На остальных, при перезагрузке пк айпи сбрасывается и пытается перебором снова взять допустимый адрес, ....
...И каждый раз минут по 20 пользователи тратят на получение адресов...
Ищите 2й DHCP, чудес не бывает, Wireshark в помощь
А учитывая то Вы работаете и от качества Вашей работы страдают Ваши сотрудники, а проблему в моменте решить не выходит - потрать 2 часа пропиши статику. А на 1-2 проблемных оставь DHCP и изучай Wireshark что в сети происходит. Как проблема будет локализована и устранена - еще 2 часа вернуть DHCP
Про 2 часа это минут по 5 на комп, для неспешного админа :)
Да, прописать статику было бы решением, если бы они так же после ребута не переставали выходить в сеть, причем, не показывая, что сеть отвалилась. Ну то есть, иконка подключения в трее остается нормальной, а Пинг до 8 не идет и сайты, соответственно, не открываются. Хотя локалка, разумеется, работает. Про вайршарк понял уж, погляжу с утра как и что
169 это сеть apipa, то есть получается dhcp не два, а его вообще нет, на отсутствие dhcp так же указывает длительное получение адресов, наверняка эти клиенты находятся за какими то сетевыми устройствами от dhcp.
Попробовать увеличить срок аренды адресов.
Возможно DHCP не проверяет arp перед init-boot, можно попробовать пока отключить init-reboot.
Убрать статические адреса.
Насчет init reboot - не совсем уверен как, первый раз об этом слышу от вас, но если правильно понимаю команду - это для *nix устройств? По срокам аренды - выставлял час, выставлял сутки, сейчас стоит 10 дней, при /all я вижу срок аренды. Статические адреса стоят на сервере и на мфу, за границами DHCP пула.
Sevoran, ну так как конфиги не посмотреть, приходится перебирать возможные причины). init reboot это да, с linux.
Значит дело не аренде. Скорей всего в доступности dhcp, раз так долго адреса получают и искать причины в этом направлении.
Средний
Средний
