Укороченная версия: Почему Test-Connection сообщить «Произошла неустранимая ошибка во время поиска в базе данных» для автономного хоста в другой подсети?
Я использую PowerShell для проверки связи удаленного хоста с Test-Connection командлет:
$Computer = "COMPUTER01"
Test-Connection -ComputerName $Computer -Count 3
Я получаю следующее сообщение об ошибке:
System.Net.NetworkInformation.PingException: Testing connection to computer
'COMPUTER01' failed: A non-recoverable error occurred during a database
lookup ---> System.ComponentModel.Win32Exception: A non-recoverable error
occurred during a database lookup.
Все мои DNS-серверы - это контроллеры Windows AD, на которых запущена служба DNS. Я могу преобразовать имя хоста в IP-адрес, используя nslookup:
Name: computer01.domain.com
Address: 192.168.2.153
На сайте MS говорится следующее:
Это неисправимая ошибка. Это указывает на то, что во время поиска в базе данных произошла какая-то неисправимая ошибка. Это может быть связано с тем, что файлы базы данных (например, BSD-совместимые файлы HOSTS, SERVICES или PROTOCOLS) не могут быть найдены, или сервер возвращает DNS-запрос с серьезной ошибкой.
https://msdn.microsoft.com/en-us/library/windows/desktop/ms740668(v=vs.85).aspx
Вопрос: Какой "поиск в базе данных" может дать сбой?
Я пытался ping тот же хост, который также не работает, но с более знакомым сообщением:
C:\> ping COMPUTER01
Pinging COMPUTER01.domain.com [192.168.2.153] with 32 bytes of data:
Reply from 192.168.0.220: Destination host unreachable.
Бег tracert для целевого IP-адреса это подтверждает:
C:\> tracert -d 192.168.2.153
7 40 ms 40 ms 40 ms 192.168.0.220
8 192.168.0.220 reports: Destination host unreachable.
Это сообщение указывает на одну из двух проблем: либо у локальной системы нет маршрута к желаемому пункту назначения, либо удаленный маршрутизатор сообщает, что у него нет маршрута к пункту назначения ...
Если появляется сообщение «Ответ от <IP-адрес>: узел назначения недоступен», то проблема маршрутизации возникла на удаленном маршрутизаторе, адрес которого указан в поле «<IP-адрес>». Используйте соответствующую утилиту или средство для проверки таблицы IP-маршрутизации маршрутизатора, которому назначен IP-адрес <IP-адрес>.
Я просмотрел пакеты ICMP с помощью WireShark. Я вижу, что ответ от этого роутера:
Type: 3 (Destination unreachable)
Code: 1 (Host unreachable)
Пункт назначения недоступен генерируется хостом или его входящим шлюзом, чтобы сообщить клиенту, что пункт назначения по какой-то причине недоступен ... Недостижимые порты TCP, в частности, отвечают TCP RST, а не типом Destination Unreachable 3, как можно было бы ожидать.
https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol#Destination_unreachable
У меня также есть отдельное / независимое подтверждение того, что целевой хост находится вне сети, что объясняет, почему маршрутизатор не может «достичь» цели. Мне все еще интересно, почему Test-Connection командлет выдал то, что (для меня) такое вводящее в заблуждение сообщение об исключении.
Спасибо, что поделился. Вы заставили меня посмотреть документы, так как у меня была такая же ошибка.
Похоже, что это «особенность» Test-Connection; они, кажется, знают об этом, поскольку предлагают обходной путь.
Помощь для Test-Connection говорит, что если вы хотите, чтобы он возвращал только логическое значение, вы должны использовать -Quiet switch при вызове, иначе он пытается вернуть объект. Вот дословно:
Когда вы используете параметр AsJob, командлет возвращает объект задания. Когда вы используете параметр Quiet, он возвращает логическое значение. В противном случае этот командлет возвращает объект Win32_PingStatus для каждого запроса связи.
Так -Quiet это для меня, а не -ErrorAction SilentlyContinue.
После устранения неполадок, которые я применил к этому, я пришел к выводу, что Test-Connection возвращает очень бесполезное сообщение об ошибке и / или неверно интерпретирует ответ «Целевой хост недоступен», полученный от маршрутизатора.
Если кто-то еще видит это, я бы предложил запустить tracert чтобы подтвердить, есть ли на маршруте какое-либо устройство, которое может возвращать ответ на запрос ping.
Если у вас есть какой-либо другой способ, кроме ping, чтобы определить, находится ли хост в сети или нет, это сделает хорошую проверку работоспособности и поможет вам решить, можете ли вы игнорировать эти ошибки (используя -ErrorAction) при условии, что хост отключен:
$Computer = "COMPUTER01"
if(Test-Connection -ComputerName $Computer -Count 1 -ErrorAction SilentlyContinue) {
"Online"
} else {
"Offline"
}
Кстати, казалось, что единственная разница между ping и Test-Connection заключалось в том, что время жизни (TTL) пакета ICMP различалось между ping (128) и Test-Connection (80). Последний командлет действительно включает -TimeToLive переключитесь, если это кому-то важно; в моем тестировании это не имело никакого значения.