Перед появлением командлета Test-NetConnection в PowerShell у нас было много различных инструментов командной строки для устранения различных проблем с сетевым подключением.
У нас была команда ping для тестирования эхо-запросов и ответов ICMP; tracert для определения места, где могут быть потеряны наши пакеты; nslookup для выполнения DNS-запросов к нашим DNS-серверам; telnet для проверки открытых TCP-портов и различных других утилит. Для всего была своя утилита.
С появлением PowerShell v4 в Windows 8.1 и Windows Server 2012 R2 этот подход “одна утилита – одна задача” для устранения проблем с подключением устарел.
Позвольте мне представить вам новый, всемогущий командлет Test-NetConnection. Представьте себе PowerShell Test-NetConnection как комбинацию команд ping, tracert, nslookup, telnet и нескольких других утилит, объединенных в один пакет для устранения неполадок.
Устранение неполадок с Test-NetConnection
Давайте посмотрим, что мы можем сделать с командлетом test-netconnection в PowerShell и рассмотрим, как мы можем использовать его, когда у нас несчастное положение устранения проблем с сетевым подключением.
Чтобы продемонстрировать это, я собираюсь использовать PowerShell Test-NetConnection для устранения распространенной проблемы в реальном мире: “Не могу зайти на веб-сайт XYZ!”
То, что большинство пользователей не знают, это то, что успешное отображение веб-сайта в браузере само по себе является удивительным достижением, учитывая количество подвижных частей, которые должны взаимодействовать, чтобы это произошло. Как минимум, процесс включает в себя:
- Наличие интернет-соединения.
- Наличие маршрута к вашему DNS-серверу.
- Обращение к DNS-серверу для разрешения URL.
- Наличие маршрута к IP-адресу, к которому разрешается URL.
- Открытый TCP-порт 80.
- И так далее, и так далее.
Подтвердите ваше интернет-соединение
Для начала устранения неполадок вам нужно подтвердить, что у вас есть интернет-соединение. Вы можете сделать это, просто запустив PowerShell Test-NetConnection без параметров. Однако, если вы хотите получить больше информации, я предлагаю использовать параметр InformationLevel с аргументом Detailed.
Эта простая команда проверяет ваше локальное соединение и интернет-соединение, а также подтверждает, что ваш клиент DNS может разрешать имена, направленные на ваш DNS-сервер, все сразу. Считайте это общей проверкой состояния вашего сетевого соединения. Эта команда проверяет три из пяти процессов, необходимых для отображения веб-сайта одним махом!
Используйте Test-NetConnection для проверки соединения с хостом веб-сайта.
Мы теперь должны направить наше устранение неполадок к веб-хосту вопроса. Давайте в качестве примера используем google.com. Вы также можете использовать удаленный компьютер.
Мы можем использовать Test-NetConnection с параметром ComputerName, чтобы одновременно убедиться, что хост веб-сайта может быть разрешен в DNS, что есть доступ к маршруту TCP для доступа к IP-адресу, к которому разрешается имя, и что он может быть пингован.
Хотя этот шаг технически проверяет, что у нас есть маршрут к веб-серверу google.com, я хочу получить более подробную информацию о том, через какие маршрутизаторы проходят мои пакеты, чтобы добраться до веб-сервера google.com. Для этого я буду использовать параметр TraceRoute, чтобы получить список.
Убедитесь, что ваш TCP-порт открыт
Нашим последним тестом является проверка того, что TCP-порт, на котором мы ожидаем запуск веб-сервера, открыт. В этом случае, поскольку мы просто указываем google.com, я предполагаю, что это TCP-порт 80. Для этого мы просто добавим еще один параметр к Test-NetConnection. Поскольку Test-NetConnection понимает стандартный TCP-порт для нескольких различных служб, нам даже не нужно знать номер порта. Я могу просто передать HTTP в параметр CommonTCPPort, и он сделает работу за меня.
Однако, если веб-сайт может работать под другим портом, например, 8080, вы можете указать TCP-порт напрямую, используя параметр Port.
Мы теперь протестировали каждое из требований к подключению, изложенных в начале этой статьи. Если мы до сих пор не можем отобразить веб-сайт на данный момент, мы подтвердили, что проблема не связана с нашим клиентом, и мы можем передать проблему Google или, возможно, серверу DNS вниз по течению.