Ping Windows Server 2012 не проходит

По умолчанию Windows Server 2012 и Windows Server 2012 R2 не пингуются (ping). Отключить данную настройку можно одним из двух способов:

1. Активировать ping, используя «Проводник Windows»
2. Активировать ping, используя Powershell

Виртуальный сервер на базе Windows

• Лицензия включена в стоимость
• Тестирование 3-5 дней
• Безлимитный трафик

Откройте «Панель управления», кликните по заголовку «Систему и безопасность»:

Выберите «Брандмауэр Windows»

Выберите раздел «Дополнительные параметры»

В «Брандмауэр Windows в режиме повышенной безопасности» выберите «Правила для входящих подключений»

Найдите пункт «Общий доступ к файлам и принтеру (эхо запрос – входящий трафик ICMPv4-)»

Правый клик мыши и выбирайте пункт «Включить правило»

Убедитесь, что иконка стала зелёного цвета:

Готово. Закройте окно «Брандмауэр Windows в режиме повышенной безопасности» и Панель управления. Проверьте работу, выполнив ping IP-адреса сервера через командную строку или PowerShell-запрос.

Для того чтобы сделать тоже самое, что описано выше. Введите команды:
Import-Module NetSecurity
Set-NetFirewallRule -DisplayName “File and Printer Sharing (Echo Request – ICMPv4-In)” -enabled True

Для создания нового правила, которое разрешает и активирует ICMPv4-пинг, введите команды
Import-Module NetSecurity
New-NetFirewallRule -Name Allow_Ping -DisplayName “Allow Ping” -Description “Packet Internet Groper ICMPv4″ -Protocol ICMPv4 -IcmpType 8 -Enabled True -Profile Any -Action Allow

(для IPv6-пинга, разумеется, нужно активировать v6-правило для входящих)

Ping в Windows Server 2012

Характерной особенностью сетевой безопасности Windows Server 2012 и Windows Server 2012 R2 является то, что ответ на ICMP-запросы отключен в системе по умолчанию, иными словами, система не пингуется. Для того чтобы исправить эту проблему существует два системных способа:

1. Разрешить пинги через настройки брандмауэра Windows.

2. Воспользоваться программной оболочкой Powershell.

1. В главном меню открываем “Администрирование”, затем “Брандмауэр Windows в режиме повышенной безопасности”.

Альтернативный путь — Пуск -> Панель управления -> Система и безопасность -> Брандмауэр Windows -> Дополнительные параметры.

2. В новом окне, в левой части, выбираем Правила для входящих подключений, а в основной части ищем “Общий доступ к файлам и принтерам (эхо-запрос — входящий трафик ICMPv4)”. Кликаем правой кнопкой мыши и из контекстного меню выбираем “Включить правило”.

3. Проверяем результаты с другой машины.

Если вы не сторонник пользовательского интерфейса и/или он по какой-то причине не работает, то можно воспользоваться PowerShell.

1. Запускаем PowerShell

2. Поочередно вводим две команды

Set-NetFirewallRule -DisplayName “Общий доступ к файлам и принтерам (эхо-запрос — входящий трафик ICMPv4)” -enabled True

Важно! Имена существующих правил следует указывать как они вписаны в общий список и на том же языке. В английской версии правило называется “File and Printer Sharing (Echo Request – ICMPv4-In)”

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

Если указанные методы решения проблем не помогли, то рекомендуем:

-проверить используется ли Firewall стороннего производителя и проверить его настройки;

-проверить разрешено ли хождение ICMP-трафика через шлюз;

Аналогичную проверку нужно сделать и на удаленной машине.

Разрешаем ping в Windows Server 2008/2012

Ping — утилита командной строки для проверки соединений в сетях TCP/IP. Она является одним из основных средств диагностики сети и входит в состав всех современных сетевых операционных систем. Принцип ее работы заключается в том, что она отправляет запросы (ICMP Echo-Request) протокола ICMP указаному узлу и фиксирует поступающие ответы (ICMP Echo-Reply).

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

В серверных ОС начиная с Windows Server 2008 входящие эхо-запросы по умолчанию запрещены и блокируются брандмауэром Windows. Сделано это скорее всего с целью предотвратить сетевые атаки типа ICMP Flooding (затопление атакуемого узла пакетами ICMP), которые могут вызвать отказ в обслуживании (Denial of Service, DoS). Безопасность конечно важна, однако в результате при попытке проверить доступность сервера мы получаем ошибку.

Для разрешения входящих эхо-запросов необходимо активировать соответствующее правило брандмауэра Windows. Вот несколько вариантов того, как это сделать.

Оснастка Windows Firewall with Adwanced Security

Самый простой способ разрешить ping — воспользоваться оснасткой «Windows Firewall with Adwanced Security». Для ее запуска нажимаем клавиши Win+R и вводим команду wf.msc.

Заходим в раздел входящих правил (Inbound Rules). Здесь нас интересует предопределенное правило для IPV4 — ″File and Printer Sharing (Echo Request — ICMPv4-In)″. Обратите внимание, что в таблице присутствуют два правила с одинаковым названием. На самом деле это одно и то же правило, просто настроенное для разных профилей — одно для доменного профиля, второе для общего и частного.

Активируем правило, отметив галочкой чекбокс Enabled и проверяем, чтобы в поле Action был выбран пункт ″Allow the connection″.

Переходим на вкладку Advanced и выбираем профили, для которых это правило будет действовать. Сохраняем правило и жмем OK. Теперь сервер можно пинговать.

При необходимости в дополнительных мерах безопасности произведем еще несколько настроек, которые защитят сервер от атак и позволят вам спокойно пользоваться Ping-ом.

Переходим на вкладку Scope и в поле Remote IP address указываем, с каких адресов разрешено принимать входящие запросы. Здесь можно указать один адрес, диапазон адресов либо целиком подсеть.

На вкладке Local Principals указываем локальных пользователей или группы, которым разрешается пинговать данный сервер. Как вариант, можно дать разрешение только группе локальных администраторов.

Групповые политики

В доменной среде разрешить Ping можно централизованно, через групповые политики. Открываем в редакторе групповых политик соответствующую GPO и переходим в раздел Computer Configuration–Policies–Windows Settings–Windows Firewall with Adwanced Security. Раскрываем дерево поддразделов и переходим на вкладку Inbound Rule. Кликаем правой клавишей мыши и в контекстном меню выбираем New Rule.

Выбираем Predefined (предопределенные правила) и находим в списке группу правил «File and Printer Sharing».

Находим правило ICMPv4-In и убираем выделение с остальных.

Выбираем для правила действие Allow the connection (разрешить подключениe) и жмем Finish, сохраняя правило.

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

Утилита Netsh

Кроме графических средств для управления правилами можно воспользоваться утилитой командной строки netsh. В качестве примера активируем правило ICMPv4-In для всех профилей брандмауэра и ограничим удаленные IP подсетью 192.168.1.0/24:

netsh adwfirewall firewall set rule name= ″File and Printer Sharing (Echo Request — ICMPv4-In)″ new enable= yes action= allow profile= any remoteip= 192.168.1.0/24

Если вы используете Windows Server 2008 (не R2), то команда будет выглядеть немного по другому. Для включения правила:

netsh firewall set icmpsetting 8

И для отключения:

netsh firewall set icmpsetting 8 disable

PowerShell

Также разрешить эхо-запросы можно с помощью PowerShell. Правда воспользоваться этим способом можно только в Windows Server 2012, в остальных ОС отсутствует соответствующий PowerShell модуль. Для активации правила воспользуемся следующей командой:

Set-NetFirewallRule -Name FPS-ICMP-ERQ-In -Enabled True -Profile Any -Action Allow

Вроде бы все. Хотя нет, вспомнил еще один интересный момент. Для нормальной работы службы каталогов Active Directory необходимо, чтобы брандмауэр пропускал ICMP пакеты от клиентских компьютеров к контроллеру домена. Это нужно для получения клиентами сведений групповой политики. Поэтому на контроллерах домена есть отдельное правило брандмауэра, разрешающее входящий ping — ″Active Directory Domain Controller — Echo Request (ICMPv4-In)″. Это правило активно по умолчанию.

Запрет / разрешение ответа на ping в Windows Server 2012 и 2016

Параметры Брандмауэра

Самый простой способ запретить или разрешить ping — воспользоваться оснасткой
«Брандмауэр Windows в режиме повышенной безопасности».

Для ее запуска нажимаем клавиши Win+R и вводим команду wf.msc.

Заходим в раздел входящих правил («Правила для входящих подключений»).
Здесь нас интересует предопределенное правило для IPV4 — ″Общий доступ к файлам и принтерам (эхо-запрос — входящий трафик ICMPv4)″.

Обратите внимание, что в таблице присутствуют три правила с одинаковым названием.
На самом деле это одно и то же правило, просто настроенное для разных профилей — одно для доменного профиля, второе для общего и частного.

Отключить/Включить правило

Для того, чтобы выключить/включить правило — выберите его и нажмите на правой панели «Отключить правило»/«Включить правило».

С отключенным правилом Ваш сервер не отвечает на запросы утилиты ping и наоборот, с включенным — отвечает.

Что делать, если сервер недоступен по сети

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

Проверка пинга

Запустить ping с вашего ПК до IP-адреса вашего сервера можно, например, через CMD : командная строка Windows ( Пуск — Все программы — Стандартные — Командная строка )

Если пинг проходит корректно, то вы увидите статистику переданных пакетов и время ответа, как на скриншоте:

В противном случае появится сообщение об ошибке, что говорит о сетевой недоступности, либо о проблемах с соединением:

Далее нужно зайти на сам сервер и проверить пинг с сервера до внешних ресурсов, перейдите в панель VMmanager и найдите в верхнем меню значок VNC .

Если вы используете VMmanager 6, то нажмите на кнопку VNC во вкладке Виртуальные машины .

В окне VNC необходимо авторизоваться и запустить ping до любого адреса, например 8.8.8.8 . Если сеть работает, то вы увидите количество переданных пакетов и время, за которое они достигли конечного адреса. Если нет, то придут сообщения вида network unreacheble, connection timeout, либо команда будет просто «висеть» без вывода.

Так как ping не проходит, это говорит о том, что не работает сеть. Поэтому переходим к следующему шагу и идём проверять, в чём может быть проблема.

Проверка сетевых настроек сервера

Первым делом проверим корректность сетевого конфига. Если вы приобрели новый сервер и установили свою операционную систему из образа, могли ошибиться с настройками сети. Но даже для действующего сервера не будет лишним убедиться в том, что настройки в порядке. Узнать, какие сетевые настройки следует использовать для вашей операционной системы, можно в статье «Сетевые настройки в кластерах с технологией VPU».

Диагностика проблем сети с помощью утилиты ip

Диагностировать проблему нам поможет утилита ip — она покажет имя, статус сетевого интерфейса и IP-адреса, которые ему назначены. Утилита установлена во всех современных linux-дистрибутивах.

На сервере с корректными настройками вывод будет таким:

В этом случае, нас интересует блок с названием нашего сетевого интерфейса — в этом случае eth0 (на разных ОС может называться по-разному, например, ens3, eno1).

Здесь прописан наш IP-адрес, маска и шлюз, что можно увидеть в строке:

На наших серверах используется технология VPU , поэтому в качестве сетевого шлюза на серверах используется адрес 10.0.0.1 , а маска подсети /32

Также следует обратить внимание на статус интерфейса. Если его статус DOWN, а не UP, то стоит попробовать запустить интерфейс вручную командой if up eth0 , где вместо eth0 укажите имя вашей сетевой карты. Ранее мы рассмотрели, где можно его найти.

На этом примере видно, что интерфейс не «поднимается» из-за синтаксических ошибок в конфигурационном файле сетевых настроек /etc/network/interfaces .

Также стоит проверить статус службы Network командой systemctl status networking . Если она не запущена, то стоит её запустить командой systemctl start networking . Если служба не запустилась, то, возможно, имеется ошибка в конфигурации, о чём будет сообщено в выводе команды запуска. Вам нужно обратить внимание на строку, которая начинается с Active . Обычно статус запуска службы выделен цветом: красным в случае ошибки и зелёным, если запуск был успешен — как на скриншотах ниже:

Далее проверяем маршруты. Даже если сетевой интерфейс работает и IP указан верно, без двух маршрутов сеть работать не будет.

Должен быть прописан путь до 10.0.0.1 и он же установлен по умолчанию (дефолтным), как здесь:

Если сеть не заработала, проверяем пинг до шлюза 10.0.0.1 — если он проходит, возможно, проблемы на стороне хостинг-провайдера. Напишите нам в поддержку, разберёмся.

Проверка фаервола

Возможен вариант, что сеть настроена корректно, но трафик блокируется фаерволом внутри самого VDS.

Чтобы это проверить, первым делом смотрим на политики по умолчанию.
Для этого вводим iptables-save и смотрим на первые несколько строк вывода.

В начале мы увидим политику по умолчанию для соединений (цепочек) INPUT , OUTPUT , FORWARD — то есть правила для всех входящих, исходящих и маршрутизируемых соединений. Они имеют статус DROP либо ACCEPT .

Когда все соединения с сервера заблокированы, они имеют статус DROP , и вывод выглядит так:

Чтобы исключить влияние фаервола, просматриваем текущие правила с помощью iptables-save и сохраняем их в отдельный файл командой:

Меняем все политики по умолчанию на ACCEPT и сбрасываем все текущие правила командами:

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

Проверка влияния ПО

Возможен вариант, что установленные на сервере программы (особенно связанные с изменением маршрутизации на сервере, например, OpenVPN, Docker, PPTP) «ломают» работу сети. Чтобы исключить влияние установленного на сервер ПО, можно запустить сервер в режиме восстановления и проверить сеть.

Для этого в панели VMmanager останавливаем VDS и подключаем ISO-образ sysrescueCD через меню Диски :

В VMmanager 6 ISO-образ sysrescueCD подключается в Меню сервера по кнопке Режим восстановления на главной странице панели.

После загрузки образа подключаемся по VNC и выполняем команды (в VM6 еще потребуется сначала выбрать образ восстановления в VNC)

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

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

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

Для диагностики подойдет утилита mtr . Она совмещает в себе трассировку и пинг, что наглядно показывает, есть ли проблемы с потерей пакетов и на каких узлах (хопах) они проявляются.

Запускаем на сервере mtr до вашего IP, с которого пробуете подключаться, и с сервера — в обратном направлении до вашего адреса :

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

В случае, если на пути имеются потери, вместо 0.0% на хопах (промежуточных узлах) в столбце Loss будет указан процент потерянных пакетов от соответствующего узла. На примере ниже видно, что потери начинаются на одном из узлов и дальше сохраняются на последующих хопах:

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

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