Как проверить работу dhcp сервера windows

Если вы используете сервера DHCP для автоматической настройки параметров TCP/IP для рабочих станций в вашей организации, то нерабочий DHCP может привести к нарушению работы всей организации. К тому же, если рабочая станция не сможет получить IP адрес, то она не сможет получить доступ к ресурсам в вашей сети или в интернет. В этой статье мы обсудим некоторые техники, которые вы сможете использовать для устранения неисправностей, связанных с DHCP сервером.

Назначение неправильного адреса

Самая частая проблема, связанная с DHCP, заключается в назначении неправильного IP адреса. Например, предположим, что ваш сервер DHCP был настроен на использования интервала IP адресов с 192.168.0.1 по 192.168.50. Вам следует ожидать, что сетевому компьютеру будет присвоен IP адрес из этого интервала. Теперь предположим, что рабочая станция в вашей сети начала испытывать проблемы при обращении к другим сетевым серверам. Вам необходимо использовать команду IPCONFIG /ALL для того, чтобы увидеть сетевую конфигурацию и IP адрес. Вместо адреса из ожидаемого интервала адресов мы видим, что рабочей станции был присвоен адрес, начинающийся с 169.254. Так что же произошло? Если компьютеру в вашей сети неожиданно был присвоен адрес, начинающийся с 169.254, то вы можете быть абсолютно уверены, что этот адрес был присвоен не вашим DHCP сервером. Случилось то, что ваша рабочая станция не смогла соединиться с сервером DHCP server. Если такое происходит, что рабочая станция сама назначает себе IP адрес, с помощью средства Windows под названием Automatic Private IP Addressing (APIPA или автоматическая адресация).

Microsoft встроил автоматическую адресацию в операционную систему Windows в качестве помощи тем, кто использует очень маленькие сети. Например, если вы создали небольшую сеть Windows, то вам не нужно вручную настраивать IP адреса, даже если нет сервера DHCP в сети. APIPA поможет вам автоматически присвоить уникальный адрес класса В каждой машине в сети. Это великолепно для небольших домашних сетей, но абсолютно неприменимо для больших сетей. Если рабочая станция воспользовалась услугами APIPA, то это означает, что на ее запрос на получение IP адреса не пришло ответа. Причин возникновения такой ситуации может быть несколько. Если вы знаете, что все остальные компьютеры в вашей сети нормально запрашивают IP адрес у вашего DHCP сервера, то вы можете заключить, что причиной проблемы является не DHCP server.

Более чем вероятно, проблема связана с сетевым аппаратным обеспечением, которое установлено на рабочей станции. Например, для карты сетевого интерфейса используется неправильный драйвер. Другая возможная причина может заключаться в том, что сетевой кабель, воткнутый в сетевую карту, не подключен с другой стороны к переключателю.

Конечно, только то, что один компьютер не может получить IP адрес, вовсе не означает, что наш сервер является источником проблемы. Если другие рабочие станции успешно получают IP, то вы можете быть уверены, что сервер работает правильно. Однако, может возникнуть такая ситуация, что сервер исчерпал лимит IP адресов, которые он может назначить клиентам. Вы можете легко выявить такую проблему, сравнив количество адресов, входящих в интервал, выделенный для сервера DHCP, с количеством устройств, которые запрашивают IP адрес у сервера DHCP server. Общие проблемы серверов DHCP

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

Если сервер DHCP может связаться с другими компьютерами в сети, то я рекомендую проверить, что серверу DHCP server присвоен IP адрес, и что этот адрес совместим с тем интервалом адресов, для которого этот сервер настроен присваивать адреса для рабочих станций. Например, если интервал адресов, которые сервер DHCP присваивает рабочим станциям, варьируется с 192.168.0.1 до 192.168.0.50, то сервер не сможет присваивать адреса рабочим станциям до тех пор, пока ему самому не будет присвоен статический адрес в том же самом сегменте подсети, например, 192.168.0.0 или 192.168.0.51.

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

Конфликты IP адресов

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

Были две ситуации, с которыми я столкнулся при возникновении такой проблемы. Первый раз, когда я столкнулся с этой проблемой, я смог определить, каким компьютерам были присвоены одинаковые адреса. Когда я проверил конфигурацию TCP/IP на этих машинах, то обнаружил, что на одной из них адреса были настроены вручную. Это достаточно долгая история, но если коротко, то для работы одного из приложение на этом компьютере необходимо было, чтобы у машины был статически IP адрес. Пользователю надоела постоянно настраивать это приложение под меняющийся адрес, поэтому он просто взял адрес, который был присвоен ему динамически и сделал его статическим.

Вероятность возникновения такой ситуации в наши дни достаточно невелика. Когда возникла такая ситуация повсеместно использовалась операционная система Windows 98. В операционной системе Windows 98 не хватает много инструментов для безопасности, которые есть у нас на сегодняшний день. Правильно настроенная безопасность на рабочей станции с операционной системой Windows XP или Windows Vista позволит запретить все изменения конфигурации пользователю. Но, несмотря на это, я все же хотел упомянуть эту ситуацию, т.к. иногда она поможет вам решить проблему.

Гораздо чаще проблема с конфликтом адресов возникает, когда используются несколько DHCP серверов, и эти сервера DHCP имеют пересекающиеся множества адресов. Если у вас только один сервер DHCP в вашей сети, то не совершайте ошибки, и не исключайте возможность возникновения такой ситуации в вашей сети. Есть вероятность того, что в вашей сети появился пиратский (rogue) DHCP сервер, который конфликтует с вашим основным сервером DHCP.

Операционные системы Windows 2000 Server и Windows Server 2003 спроектированы таким образом, чтобы избежать проблем с пиратскими (rogue) DHCP серверами. В них сервер DHCP может присваивать IP адреса лишь после того, как он был авторизован Active Directory. Но проблема заключается в том, что это применимо лишь для серверов DHCP, которые работают на платформе Windows. Сервера DHCP, работающие на других операционных системах могут присваивать IP адреса клиентам без необходимости быть авторизованными Active Directory.

Так существует ли какая-нибудь сложность установки пиратского сервера DHCP, который работает на платформе Linux? Вероятно, нет. Гораздо более вероятное объяснение заключается в том, что вашей проблемой является беспроводная точка доступа, или маршрутизатор. Такие устройства практически всегда имеют встроенный DHCP сервер. Эти устройства обычно используют интервал адресов с 192.168.0.x или 192.168.1.x. Если так случилось, что этот же самый интервал IP адресов используется на вашем основном DHCP сервере, что тогда вы столкнетесь с ситуацией, когда оба сервера DHCP присваивают адреса из одного и того же интервала, что приводит к конфликту.

Заключение

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

Источник: netdocs.ru

Оцените статью: Голосов

Troubleshooting on DHCP server

Verify listening ports

Verify that only the DHCP server is listening on UDP port 67 and 68. No other process or other services (such as WDS or PXE) should occupy these ports.

# Run command
    netstat -anb

Verify Event log

Check the System and DHCP Server service event logs for reported issues that are related to the observed problem.

Applications and Services Logs > Microsoft > Windows > DHCP-Server

DHCP Audit Logs

Enabling Your DHCP Audit Logs

Check DHCP audit logs are enabled

# PowerShell
Get-DhcpServerAuditLog

Result
a. Path     c:\windows\system32\dhcp
b. Enable   True

# If not enable, then enble it
Set-DhcpServerAuditLog -Enable $True -MaxMBFileSize 70
Restart-Service DhcpServer

Audit Log location

The DHCP audit logs are follow the naming context DhcpSrvLog-.log* for IPv4 logs and DhcpV6SrvLog-.log for the first three letters of the day written in English.

# Get dhcp audit logs
Get-ChildItem C:\Windows\system32\dhcp\Dhcp*SrvLog-*.log | Select -ExpandProperty Name

Understanding the Contents

Interpreting the logs is also fundamental while troubleshooting. The DHCP audit log files consists of two parts:

Roughly 32 lines mainly describing what the different event codes (ID and QResult) mean in the CSV.
A CSV with a header.
Most of the columns are pretty well-described by their headers. But the ID column can sometimes be quite cryptic, so I summarized a list of all the IPv4 ID descriptions both from the log files and Microsoft’s official documentation below:

0: The log was started.
1: The log was stopped.
2: The log was temporarily paused due to low disk space.
10: A new IP address was leased to a client.
11: A lease was renewed by a client.
12: A lease was released by a client.
13: An IP address was found to be in use on the network.
14: A lease request could not be satisfied because the scope's address pool was exhausted.
15: A lease was denied.
16: A lease was deleted.
17: A lease was expired and DNS records for an expired leases have not been deleted.
18: A lease was expired and DNS records were deleted.
20: A BOOTP address was leased to a client.
21: A dynamic BOOTP address was leased to a client.
22: A BOOTP request could not be satisfied because the scope's address pool for BOOTP was exhausted.
23: A BOOTP IP address was deleted after checking to see it was not in use.
24: IP address cleanup operation has began.
25: IP address cleanup statistics.
30: DNS update request to the name DNS server.
31: DNS update failed.
32: DNS update successful.
33: Packet dropped due to NAP policy.
34: DNS update request failed as the DNS update request queue limit exceeded.
35: DNS update request failed.
36: Packet dropped because the serve is in failover standby role or the hash of the client ID does not match.
50: Unreachable domain
51: Authorization succeeded
52: Upgraded to a Windows Server 2003 operating system
53: Cached Authorization
54: Authorization failed
55: Authorization (servicing)
56: Authorization failure, stopped servicing
57: Server found in domain
58: Server could not find domain
59: Network failure
60: No DC is DS Enabled
61: Server found that belongs to DS domain
62: Another server found
63: Restarting rogue detection
64: No DHCP enabled interfaces

There's also the QResult column that specifies if a client has been blocked from receiving an IP address with the following description to its IDs:

0: NoQuarantine
1: Quarantine
2: Drop Packet
3: Probation
6: No Quarantine

Additional data is almost always supplied in the Description column.

Parsing the auditing logs

Function Get-RemoteDhcpAuditLog {
    Param(
        [parameter(Mandatory)]
        [string[]]$ComputerName,    
        [parameter(Mandatory)]
        [ValidateSet('Mon','Tue','Wed','Thu','Fri','Sat','Sun','*')]
        [string]$Day = '*',
        [parameter(Mandatory)]
        [ValidateSet('IPv4','IPv6')]
        [string]$Protocol = 'IPv4',
        [string]$LogPath = "C:\Windows\System32\dhcp"
    )

    $Parameters = @{
        Day = $Day
        LogPath = $LogPath
    }

    Switch($Protocol){
        IPv6 {$Parameters["Protocol"] = "v6"}
        IPv4 {$Parameters["Protocol"] = ""}
    }

    $Job = Invoke-Command -AsJob -ArgumentList $Parameters -ComputerName $ComputerName -ScriptBlock {
        $Parameters = $Args[0]
    
        $LogFiles = Get-ChildItem -Path "$($Parameters.LogPath)\Dhcp$($Parameters.Protocol)SrvLog-$($Parameters.Day).log"
        Foreach($LogFile in $LogFiles){
            # Read the log file
            $LogContent = Cat $LogFile

            # Determine start row of CSV
            $StartRow = 0
            $LogContent | Foreach {
                if($_ -match "^ID,Date"){
                    Break
                }
                Else{
                    $StartRow++
                }
            }

            # Create expressions to use with Select-Object
            $DateTimeExpression = @{
                Name="Date"
                Expression={
                    $_.Date -match "(?\d\d)/(?\d\d)/(?\d\d)" | Out-Null
                    Get-Date "20$($Matches.year)-$($Matches.month)-$($Matches.day) $($_.Time)"
                }
            }
            # Output as CSV from row $StartRow
            $LogContent | Select -Skip $StartRow | ConvertFrom-Csv -Delimiter "," | Select $DateTimeExpression,* -ExcludeProperty Date,Time
        }    
    }

    $Job | Wait-Job
    $Job | Receive-Job
}

# Troubleshooting by filtering ip, mac, hostname
Get-RemoteDhcpAuditLog -ComputerName srvDhcp01 -Day Tue -Protocol IPv4 | Where-Object {$_.'IP Address' -eq "10.10.45.10"}

Чтобы тестировать сервер, у меня есть клиентский ПК Windows Vista в том же сегменте сети, что и сервер Windows Server 2008 DHCP. Чтобы все упростить, у меня больше нет никаких устройств в этом сетевом сегменте.

Я выполнил команды IPCONFIG /RELEASE, а затем IPCONFIG /RENEW и проверил, что получил IP адрес с нового сервера DHCP, как видно ниже:

Я также перешел на свой сервер Windows 2008 Server и убедился, что новый клиент Vista был в списке клиентов на сервере DHCP. Это действительно подтвердилось, как видно на рисунке ниже:

После этого я знал, что у меня получилась работающая конфигурация и что все завершено!

В заключение

В этой статье вы узнали, как устанавливать и настраивать сервер DHCP в Windows Server 2008. Во время этого процесса вы узнали, что такое сервер DHCP, как он может вам помочь, как его устанавливать, как управлять сервером и как настраивать специфичные для DHCP сервера параметры, такие как граница видимости DHCP сервера. В конце мы протестировали нашу конфигурацию и все работало! Удачи вам при настройке вашего сервера Windows Server 2008 DHCP Server!

03.06.2009 —

Опубликовал: |
ms windows server 2008

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

Метод 1: Запустите средство для исправления неполадок

Встроенная утилита, которая есть в ОС, часто помогает решить возникающие проблемы в авторежиме. Необходимо её запустить:

• Открывайте «Пуск», а далее в «Параметры».

• Выбирайте «Обновление и безопасность».

• Кликните на «Устранение неполадок».

• Жмите «Дополнительные средства устранения неполадок».

• Выбираем «Подключение к Интернету».

• Ждите окончания сканирования и проверяйте, решилась ли проблема.

Метод 2: Проверьте протокол IP версию 4

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

• В «Параметрах» жмите «Сеть и Интернет».
• Из «Состояния» идите в «Настройки параметров адаптера».

• Жмите по работающей сети и жмите «Свойства».

• Проверяйте, чтобы строчка «IPv4» была помечена галочкой, далее жмите по ней два раза ЛКМ.

• Поставьте галочки как показано на скриншоте.

• Перезагрузите ПК и выходите в сеть.

Метод 3: Проверьте DHCP-клиента

Данная ошибка иногда появляется из-за возникновения проблем в данной службе, именно поэтому стоит её проверить, а затем настроить автозапуск.

• Открывайте «Пуск» и идите в «Службы».

• Жмите два раза левой кнопкой мышки на «DHCP-клиент».

• Ставьте «Автоматически».

• Запускайте систему и попробуйте выйти в сеть, можно перезагрузить компьютер.

Метод 4: Обновите сетевые настройки

Изменение основных настроек являются еще одним советом для решения возникшей неполадки. Выполнить это нужно вручную через активацию спецкоманд в «Командной строке».

• Открывайте «Пуск», переходите в консоль, затем зайдите от имени администратора.

• Вводите ipconfig/flushdns и жмите Enter.

• После информации об очистке нужно ввести ipconfig/renew и получить обновленные настройки.

Метод 5: Проверьте работу DHCP-сервера

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

• Выполняйте авторизацию в web-интерфейсе.
• Нажмите на «DHCP».

• Затем на «DHCP Settings».

• Проверьте, в активном ли статусе сервер.

• Проверьте также диапазон полученных адресов. Пример верного диапазона такой: от 192. 168. 0. 10 до 192. 168. 0. 64. Меняйте, если что его вручную.

• Когда вы изменились DNS-серверы, задайте им нулевые значения и сохраняйтесь.

• Перезагрузите роутер и проверяйте работу интернета.

• Перезагрузите роутер и проверяйте работу интернета.

Метод 6: Измените драйвера для сетевого адаптера

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

• Жмите ПКМ на «Пуск» и в возникшем меню кликните на «Диспетчер устройств».
• В перечне жмите на сетевой адаптер и идите в «Свойства».

• Если «Откатить» активно, жмите на него и ждите завершения процедуры.

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