Как найти сервер в trust

После авторизации в панели управления TrustServer-а администратору становится доступен различный функционал по его настройкам и настройкам пользователей и групп. Мы рассмотрим сначала панель настроек самого TrustServer-а.

Панель настроек TrustServer-а отображается во вкладке Settings, которая содержит в себе пять дополнительных вкладок:

• General — главные настройки TrustServer-а;
• Client — настройка генерации собственных дистрибутивов подписанных ЭЦП разработчика;
• Branding — настройка брендирования клиентских модулей;
• Helpdesk — настройка интеграции с собственными службами Helpdesk/Servicedesk;
• Updates — настройка обновлений TrustServer-а.

В данной статье мы рассмотрим вкладку главных настроек — General.

Информация о текущей лицензии

Информация о текущей лицензии отображается в полях «License status», «License content» и «License number».

В поле «License status» отображается информация о статусе лицензии. Если лицензия активирована, то вместо фразы «Not active» будет указано, что лицензия активна и указана дата истечения активированной лицензии.

В поле «License content», если лицензия активирована, отображается информация о количестве серверов на которое выдана лицензия и максимальном числе одновременно подключенных устройств к данному серверу.

В поле «License number» отображается открытая часть номера лицензионного ключа.

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

Настройка параметров авторизации в панели управления TrustServer-а

Настройка осуществляется в полях «TrustServer auth mode», «Redirect from http to https» и «TrustServer auth page name».

• TrustServer auth mode — данный параметр устанавливает режим авторизации в панели управлением сервером:
  • By local network only — авторизация разрешена только в локальной сети;
  • Both LAN and WAN — авторизация разрешена и в локальной сети, и в Интернет.
• Redirect from http to https — настройка редиректа страницы панели управления с http на https (требуется настройка SSL-сертификата). Если у вас есть выданные SSL-сертификаты, то для улучшения безопасности доступа к панели управления рекомендуется настроить запуск TrustServer-а с использованием SSL-сертификатов и установить принудительный редирект с http на https. Параметр может принимать несколько значений:
  • Disabled — переадресация отключена;
  • By WAN only — переадресация включена только для интернет подключений к серверу;
  • Both LAN and WAN — переадресация включена как для локальных, так и для интернет-подключений к серверу.
• TrustServer auth page name — имя страницы авторизации сервера. В данном параметре можно изменить стандартное имя страницы авторизации сервера «Admin» на свое (или сгенерировать случайное имя нажав кнопку “Random name”). Так можно дополнительно повысить безопасность доступа к панели управления сервером.

Настройка удаления карточек неактивных компьютеров

TrustServer позволяет настроить удаление карточек неактивных компьютеров, ранее авторизованных на сервере. Настройка осуществляется в поле с длинным названием «Automatic deletion of cards with default settings («Label» value not set) of inactive computers (offline for more than N-days)».

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

• Disabled — отключено (карточки неиспользуемых контактов не будут автоматически удаляться);
• Enabled — включено (карточки неиспользуемых контактов будут автоматически удаляться). При этом появляется поле, в котором необходимо указать количество дней, по истечении которых карточка компьютера будет удалена.

Следует отметить, что компьютер считается неактивным, если в его карточке не задано поле «Label», а также если в течении указанного числа дней он находился в состоянии офлайн, т.е. не был подключен к серверу.

Настройка централизованной записи сеансов связи

Настройка централизованной записи сеансов связи осуществляется в полях «Centralized recordings storage», «Storage mode», «Maximum storage time (days)» и «Maximum storage size (Mb)»:

• Centralized recordings storage — централизованное хранение записей сеансов связи, может принимать два значения:
  • Disabled — отключено (записи не будут централизованно вестись и сохраняться на сервере);
  • Enabled — включено (все записи будут централизованно вестись и сохраняться на сервере)

Если опция централизованной записи сеансов связи включена (т.е. параметр «Centralized recordings storage» находится в состоянии «Enabled»), то появляются следующие параметры настройки:

• Storage mode — режим сохранения записей, который можно выставить в следующих вариантах:
  • Desktop only — будут вестись только записи рабочего стола;
  • Desktop and Audio — будут вестись только записи рабочего стола и аудио-звонки;
  • Full (Desktop, Audio and Video) — будут вестись записи рабочего стола, а также аудио- и видео-звонки.
• Maximum storage time (days) — ограничение по времени хранения записей на сервере в днях, по истечении которого старые записи удаляются.
• Maximum storage size (Mb) — ограничение по общему размеру отведенному на хранение записей на сервере, в мегабайтах, при превышении которого старые записи перезаписываются.

Настройка параметров «по умолчанию» для клиентских модулей

В панели управления TrustServer-а можно задать следующие параметры «по умолчанию» для клиентских модулей:

• Default grant access mode — режим доступа по умолчанию, предоставляемого пользователем к своему компьютеру (при подключении по запросу к неавторизованным компьютерам, в т.ч. к клиентским модулям “TrustViewer”, в которых авторизация не предусмотрена). Параметр может принимать следующие значения:
  • Only desktop view (min rights) — разрешен только просмотр рабочего стола;
  • Joint control — разрешен и просмотр рабочего стола, и совместное управление;
  • Unlimited access — разрешен полный доступ к компьютеру, включая доступ к буферу обмена и файловой системе без подтверждения.
• PC info display mode — устанавливает режим отображения справочной информации о компьютере на главной форме клиентского модуля. Параметр может принимать следующие значения:
  • Disabled — отключено (справочная информация не будет показана);
  • Net name only — включено (будет показано только сетевое имя компьютера);
  • IP only — включено (будет показан только IP-адрес компьютера);
  • Net name & IP — включено (будут показаны и IP-адрес, и сетевое имя компьютера).
• The duration of the session ID — устанавливает ограничение времени действия идентификатора сессии в клиентском модуле в режиме простоя (в минутах).
• Default client’s important settings password — позволяет установить пароль по умолчанию для доступа к важным настройкам клиентского модуля (в настройках клиентского модуля, на вкладке “Безопасность”, должен быть снят флаг “Защитить важные настройки паролем”, а также должен быть установлен флаг “Разрешить удаленное изменение настроек программы”). Параметр может принимать следующие значения:
  • Disable — пароль по умолчанию не назначается TrustServer-ом;
  • Enable — пароль по умолчанию назначается TrustServer-ом, при этом справа от листбокса появляется поле для ввода пароля.
• Default client’s password for access without confirmation — позволяет установить пароль по умолчанию для доступа к компьютеру без подтверждения (в настройках клиентского модуля, на вкладке “Безопасность”, должен быть снят флаг “Пароль по умолчанию для доступа без подтверждения”, а также должен быть установлен флаг “Разрешить удаленное изменение настроек программы”). Параметр может принимать следующие значения:
  • Disable — пароль по умолчанию не назначается TrustServer-ом;
  • Enable — пароль по умолчанию назначается TrustServer-ом, при этом справа от листбокса появляется поле для ввода пароля.

Настройка автономного портативного клиентского модуля

В панели управления TrustServer-ом автоматически генерируется ссылка на автономный портативный клиентский модуль для оказания мгновенной технической поддержки удаленного пользователя. Этот автономный клиентский модуль автоматически настроен на TrustServer в котором сгенерирована ссылка и не требует обязательной установки в операционной системе удаленного пользователя. Удаленному пользователю достаточно скачать такой клиент, запустить и продиктовать оператору код авторизации. Ссылки на автономный клиентский модуль отображаются в следующих полях:

• Portable client URL (Pro-version) — автоматически генерируемая ссылка на автономный клиентский модуль TrustViewerPro в режиме мгновенной удаленной поддержки;
• Portable client URL (simple version) — автоматически генерируемая ссылка на портативную программу TrustViewer в режиме мгновенной удаленной поддержки.

Кроме того, в поле «Portable client name» можно задать собственное имя программы, которое будет отображаться при запуске портативного клиентского модуля в режиме мгновенной удаленной поддержки.

Приобретение/продление лицензии на TrustViewerPro

Приобрести или продлить лицензию на TrustViewerPro можно с помощью кнопки «Buy / renew a license» на вкладке настроек General. После нажатия на кнопку администратор будет перенаправлен на сайт вендора, осуществляющего продажи и техническую поддержку TrustViewerPro.

Обсудить на Дзене.

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

Привет.

Технология DNSSEC существует достаточно давно и реализована в Windows Server 2008 R2 и Windows 7. Не идеально, но реализована. В следующем поколении продуктов – Windows Server 2012 и Windows 8 – реализация DNSSEC уже является полноценно работоспособной.

Но пользуются ей (в основном из-за смутности преимуществ DNSSEC и пугающей своей неочевидностью настройки) – единицы.

За последний год (стартовый вариант статьи написан в 2010 году, поэтому к ряду оборотов типа “недавно” надо относиться с пониманием) я использовал эту технологию в двух проектах, и после устного общения с коллегами (которые в большинстве своём в администрировании Windows-систем далеко не первый год) выяснил, что DNSSEC вообще является мёртвой зоной – она вроде есть в плане технической реализации, но её вроде и нет. В enterprise-сетях её вообще не заметно, разве что только у части хостинг провайдеров.

Это нужно исправлять, так как в DNS достаточно много негатива, который или не лечится совсем, или лечится “костыльными” решениями.

Я предполагаю, что Вы знаете, как работает обычный DNS, плюс прочитали статью про обеспечение безопасности DNS на Windows Server. Если ещё не сделали это – сейчас самое время.

Все записи DNS, IP-адреса и прочие выбраны случайно и не имеют никакого отношения к реальности. Совпадения случайны. Цель придумывания этих значений – наглядность изложения и упрощение понимания технологии DNSSEC. Их (имена записей и IP-адреса) не надо добуквенно копировать к себе, а потом удивляться артефактам поведения системы DNS. Я предупредил.

DNSSEC в Windows Server

• Что делает DNSSEC
• Не рано ли внедрять DNSSEC / Нужен ли DNSSEC для внутрикорпоративной сети?
• Как работает DNSSEC
• DNSSEC и логика кэширования
• Терминология DNSSEC
  • Записи SIG и RRSIG
  • Записи NXT и NSEC
  • Запись NSEC3
  • Ключевые пары – ZSK и KSK
  • Записи DNSKEY, они же “Якори доверия”, они же trust anchors
  • Записи DS
  • Записи DLV – “подстраховка”
• Включаем DNSSEC: Создаём ключи
  • Создание ключей защиты ключей (KSK)
  • Создание ключевой пары для зоны (ZSK)
  • Резервное копирование ключей DNSSEC
• Включаем DNSSEC: Операции с DNS-зонами
  • Подписываем зону
  • Распространяем её trust anchor’ы
• Включаем DNSSEC: Подготавливаем DNS-сервера
• DNSSEC: Настройки со стороны клиентов (NRPT)
• Тестируем DNSSEC

Что делает DNSSEC

Ключевой задачей DNSSEC является построение доверенной инфраструктуры разрешения имён в Интернете. То есть и запросы и ответы сервера (как с данными, так и негативные) должны быть авторизованы.

Сразу уточним – конфиденциальность данных (т.е. шифрование оных) не является целью DNSSEC, но может реализовываться как дополнительная мера безопасности.

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

Не рано ли внедрять DNSSEC?

Не рано ли внедрять DNSSEC? Не поздно ли Microsoft добавила его в Windows Server 2008 R2?

Нет и нет.

Для полноценного функционирования DNSSEC необходимо, чтобы цепочка доверия начиналась с корневой зоны, т.е. “точки”. “Точку” подписали 28 июля 2010 года, а, к примеру, зону “com” – только 31 марта 2011 года. Поэтому и внедрять DNSSEC уже можно, и Microsoft добавил DNSSEC в продукт заранее (вспомните, что Windows Server 2008 R2 вышел 1 августа 2009 года). Плюс необходима поддержка со стороны client resolver – этот функционал поддерживается Windows 7 (правда, фигово).

Поэтому для использования DNSSEC в корпоративных сетях есть все основания даже если клиентский парк имеет в своём составе далеко не современную Windows 7.

Как работает DNSSEC

Техническая информация доступна на официальном сайте “безопасной точки” – www.root-dnssec.org, ключи и прочее доступны на www.iana.org/dnssec.

Фундаментальные механизмы DNSSEC описаны в RFC 4033, RFC 4034 и RFC 4035. Ранее DNSSEC был документирован в RFC 2535, но так как данный стандарт полностью перекрывается тремя вышеупомянутыми, то получается следующая ситуация: в Windows Server 2003 и 2008 DNSSEC вроде как есть, но только для secondary-зон и в соответствии с устаревшим RFC. Поэтому он вроде как есть, но частично и не совместим с правильной и актуальной реализацией в Windows Server 2008 R2 и Windows 7.

DNSSEC и логика кэширования

До

начала понимания DNSSEC нужно зафиксировать один важный момент. Состоит он в том, что эта технология изначально адаптировалась под то, чтобы не быть сильно нагружающей как каналы связи, так и конечные узлы в плане вычислительных возможностей.
Вот смотрите. Наша цель в плане DNSSEC – это подтверждение подлинности и неизменности DNS-данных. Многие считают, что DNSSEC – это “подписанные DNS-зоны”. Но по сути это:

• Подписанные зоны (целиком, чтобы подтвердить их неизменность и подлинность)
• Подписанные одиночные записи
• Подписанные негативные ответы об отсутствии записей
• Подтверждённое информирование клиента о причинах невозможности разрешения записи

Т.е. нам надо, чтобы ответ сервера вида “Запись X разрешилась в адрес Y”, равно как и “Запись X не существует” мог существовать как отдельный объект, кэшироваться, проверяться на подлинность и отсутствие модификаций. Вот всё это DNSSEC будет нам предоставлять.

Теперь время изучить специфичную терминологию.

Терминология DNSSEC

До подробного изучения этого раздела следующие читать не нужно.

Терминология DNSSEC: Новый тип записи – RRSIG (ранее SIG)

Тип записи RRSIG переводится как Resource Record Signature (подпись ресурсной записи) и является ключевым компонентом DNSSEC. Ранее был тип записи под названием SIG (почитать подробнее можно в RFC 2931), а RRSIG – это её обновлённый вариант, адресно “привязаный” к технологиям семейства DNSSEC. То есть, если у Вас есть DNSSEC – то надо возвращать RRSIG к каждой записи, если просто хотите подписать отдельную запись в зоне – SIG. Записи данных типов будут возвращаться в ответе со стороны сервера в качестве “дополнения” к основной части ответа, подтверждая её подлинность. Как выглядела SIG, и как сейчас выглядит RRSIG:


sig-host.atraining.ru. 1800   IN A   127.1.2.3
sig-host.atraining.ru. 1800   SIG   (
     A
     5
     3
     1800
     20110101123456
     20120101123456
     12345
     atraining.ru.
     abcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabc= )

Разберём её состав. Первой строчкой идёт та запись, которую подписываем. Видим, что это хостовая запись sig-host в домене atraining.ru., с TTL равным получасу (1800 секунд), класса IN и разрешается она в IPv4-адрес (потому что имеет тип A) равный 127.1.2.3.

В нашей же записи, которая SIG, и имеет то же значение TTL в 1800 секунд, поля будут следующими (я выписал их в столбик для наглядности, они могут и через пробел идти):

• Тип оригинальной записи – A (в данный момент, т.к. используется RRSIG, здесь пишут нуль, чтобы показать, что данная SIG-запись подпадает под стандарт RFC 2931).
• Идентификатор алгоритма подписи (некоторые из них: MD5 – 1, DH – 2, DSA – 3, RSA-SHA-1 – 5).
• Количество компонентов в подписываемом FQDN – в нашем случае их 3 (“sig-host” + “atraining” + “ru”).
• TTL подписываемой записи – 1800 секунд.
• Время начала действия (01.01.2011, с 12:34:56) и окончания (01.01.2011, по 12:34:56).
• Идентификатор ключа (т.н. key tag) зоны. Идея в том, что для подписи зоны может использоваться несколько ключевых пар, тогда надо как-то понимать, какая использовалась для подписи этой записи. Т.е. вот представьте, что идёт плановая смена ключей. Зону подписывали ключом с идентификатором 12345, а теперь новый с 23456. А в кэше у одного из серверов лежит ответ сервера с SIG-записью. Её надо проверить. А как, если ключей несколько? Перебором всех? Тогда не очень понятно будет, когда не расшифруется корректно – это запись изменилась или ключ неудачный попался.
• Последнее поле – которое atraining.ru.. Это поле показывает название зоны, в которой надо искать ключ подписи – запись типа KEY с вышеуказаным идентификатором ключа. Данная пара значений однозначно указывает на нужную запись.
• Ну и сама подпись – результат работы закрытого ключа из ключевой пары над всеми полями записи SIG, исключая это. 🙂

Откуда будут браться эти записи? Они будут создаваться в ходе процедуры подписывания зоны. Заметьте, процедура может проводиться не только DNS-сервером – в логике работы DNSSEC подписывающий и сервер разделены. Подписывающий может брать файл зоны, ключевую пару и создавать подписанные элементы, после чего отдавать результат DNS-серверу, который уже будет отвечать на запросы клиентов. Так как все записи RRSIG и прочие, про которые мы поговорим далее, уже будут созданы, наличие закрытого ключа зоны не является требованием для работы DNSSEC-сервера.

Терминология DNSSEC: Новый тип записи – NSEC

Давным-давно в DNS была запись-предтеча NSEC’а. Называлась она NXT и использовалась очень редко. Почему же? Давайте разберёмся.

Когда Вы запрашиваете у сервера разрешение имени – допустим, testhost.atraining.ru, то сервер может поступить двояко. В частности, может вернуть ответ, в котором будет содержаться информация о том, что Вы запрашивали (да и не только; вообще, сервер может вернуть в ответе и ту доп.информацию, которую сочтёт для Вас полезной), а может вернуть ответ, который будет показывать то, что записи, которую Вы хотите разрешить в адрес, нет.
Тут начинается самое интересное.
По идее, чтобы получить уведомление об отсутствии записи в зоне, как раз нужна запись вида NXT. Оригинальный механизм, предложеный в RFC 2065, выглядит так:

• Берём DNS-зону и представляем её в виде массива RR (resource record’ов).
• Сортируем эти записи, представляя их идентификаторы как строки беззнаковых октетов, считая прописные символы строчными (т.е. большие английские буквы – маленькими) (этот процесс ещё называется canonical ordering).
• Автоматически генерим записи вида NXT, которые будут содержать информацию “Какая запись идёт после записи X”. Для последней записи в зоне представляем, что зона “закольцована” и за последней записью идёт первая.

Когда мы всё это сделаем, то получится очень полезная штука – если клиент запросит разрешить некоторое имя, и мы его не найдём, мы вернём ему NXT-запись, которая закрывает “промежуток” между двумя записями, где должна была бы быть его запрашиваемая. Т.е. если в зоне есть записи aaa.atraining.ru, ccc.atraining.ru, ddd.atraining.ru, а клиент хочет bbb.atraining.ru, мы говорим – у нас есть точная информация, что такой записи нет, вот тебе NXT за aaa.atraining.ru, которая говорит, что после только ccc.atraining.ru. Если просит zzz.atraining.ru – вернём инфу, что после ddd.atraining.ru только aaa.atraining.ru.

Только вот это всё нудно и неинтересно показалось людям. И подавляющее большинство DNS-серверов (я не пишу “все”, хотя это, по сути, так и есть) сэкономят. Нафиг зону перебирать, сортировать, генерить записи, отвечать – можно ведь прислать пустой ответ. Мол, не нашёл ничего. Извини. Вот тебе ответ с нулём reply-записей.

И наконец-то теперь – суть проблемы.

Она в том, что пустой ответ нельзя подписать. Т.е. если зайдёт речь о кэшировании негативного ответа “нет такой записи”, то нельзя закэшировать безопасный ответ, потому что ответ пустой. Его, чтобы не “выпадать” из схемы DNSSEC, придётся тогда постоянно запрашивать.

Вот чтобы этого не было, NXT возродили в лице NSEC. Выглядит она как-то так:

aaa.atraining.ru. 14400 IN NSEC ccc.atraining.ru. (A RRSIG TXT NSEC DNSKEY)

Такая запись говорит, что после сортировки вида canonical ordering между хостами aaa и ccc ничего нет. Её уже можно закэшить, и она содержит чёткую информацию об отсутствии записи, а не умолчание, которое предположительно обозначает отсутствие оной.
Более того, у NSEC есть дополнительный плюс. Допустим, у Вас отправляется запрос на получение A-записи для хоста ipv6.atraining.ru. А у этого хоста есть только AAAA-запись. Ну вот решили так – мол, будет только новая и технологичная. Что сделает обычный DNS-сервер, без DNSSEC? Он опять пришлёт пустой ответ – извини, не нашёл ничего. А сервер с DNSSEC пришлёт ответ, как на примере выше, и запрашивающий хост сможет подчерпнуть очень ценную информацию о том, что именно его типа записи нет. Вроде мелочь, но вдумайтесь и увидите, что это крайне полезная штука. Одно дело – молчание со стороны сервера, другое – подписанный ответ, по которому можно четко понять, что причина отказа – отсутствие запрашиваемого типа записи и наличие другого.

Терминология DNSSEC: Новый тип записи – NSEC3

Если Вы поняли, зачем нужна NXT, и почему появилась NSEC, то готовы к тому, чтобы понять, что механизм возврата записей NSEC небезопасен.

Причина проста – NSEC, добавляя безопасности в ряде вопросов, даёт, по сути, возможность выгрузки зоны (т.н. атака zonewalk). Т.е. атакующий может запрашивать записи по алфавиту, получая указатель на следующую, добавляя к имени следующей букву и спрашивая далее, что, учитывая что зона закольцована, даст ему за конечное число попыток полное содержимое зоны, включая информацию об именах и типах записей в ней. Это негативно. Поэтому по стандарту RFC 5155 DNS-сервер, поддерживающий DNSSEC, может вместо NSEC вернуть более безопасную NSEC3. Чем же она безопаснее?

Отличий несколько:

• Вместо имени следующей записи возвращается значение хэша.
• Хэш считается не просто от имени записи, а от имени + опционально от добавленных случайных бит (“salt”), что эффективно предотвращает словарные атаки (всё ж имён узлов не так много разных, поэтому словарные атаки на хэш имени хоста были бы крайне эффективны).
• Хэш считается не один раз, а несколько, что увеличивает вычислительную сложность задачи по подбору.

В результате NSEC3 достаточно эффективно закрывает данную проблему безопасности (выгрузку зоны путём последовательных запросов). Атакующий просто не получит имя следующего хоста. Есть и негатив – NSEC3 вычислительно сложнее и имеет ряд ограничений криптографического характера.

Вообще, чтобы лучше представлялась картинка, вот пример – допустим, в HTTPS похожей ситуации просто нет. Там если запрашиваемая страница не найдена, Вам придёт 404й ответ, который тоже страница. И он находится внутри защищённой сессии, поэтому вопрос с его подлинностью не поднимается. Но промежуточные сервера закэшировать его не смогут, т.к. они видят не отдельный HTTP-ответ, а непрерывную защищённую сессию. В DNS ситуация иная – надо, чтобы можно было “придержать” в кэше конкретный ответ сервера X, что на конкретное время запроса в зоне Y нет записи Z. Защищается объект, а не сессия.

Откуда берутся записи NSEC/NSEC3? Их надо создавать руками? Нет.

Эти записи делаются со стороны того механизма, который подписывает зону. Алгоритм примерно таков:

• Вы зафиксировали состав DNS-зоны (т.е. запретили в ней обновления и добавили все нужные записи).
• Вы запускаете процесс подписывания зоны.
• Этот процесс выстраивает записи в нужном порядке и сразу же создаёт NSEC/NSEC3 записи (в зависимости от того, какой вариант Вы выберете). Это делается, чтобы снизить нагрузку – т.е. ту же NSEC3 генерить каждый раз нет смысла – понятно, что будет этих записей ровно столько, сколько всего записей в зоне, поэтому имеет смысл сделать их заранее, а потом выдавать нужную, поняв в какую “дырку” попадает клиентский запрос о несуществующей записи в зоне.

Понятное дело, что зона должна быть статической.

Терминология DNSSEC: ZSK и KSK

ZSK = Zone Signing Key. Ключ, используемый для подписи зоны.

KSK = Key Signing Key. Ключ, используемый для подписи ключей, которыми подписана зона.

Для работы DNSSEC Вам нужна как минимум одна пара ZSK и одна пара KSK. Идея в том, что KSK подтверждает подлинность ZSK и служит относительно долго, а ZSK участвуют в штатной ротации ключей (операцию ещё называют key rollover), чем увеличивают степень защиты всего механизма. Заметим, что основная причина разделения этих ключей – разный lifetime (одни должны чаще подвергаться ротации) и разная защита на уровне хранения (т.е. ключи KSK можно и нужно хранить безопаснее, т.к. они реже требуются для выполнения операций). Математически эти ключевые пары не обязаны быть разными.

Терминология DNSSEC: Trust anchors (запись DNSKEY)

Под термином “Trust anchors” понимается комплект ключевой информации, который позволит всем, а не только авторитативным DNS-серверам за данную зону, проверять подлинность данных из данной зоны. То есть эти записи будут нужны всем промежуточным серверам, которые будут кэшировать ответы (те же NSEC/NSEC3 и RRSIG), чтобы ответы можно было проверять по всему пути их следования, и не распространять далее заведомо ложную (потерявшую целостность) информацию.

В реализации, которую мы рассматриваем (Windows Server 2008 R2), trust anchors создаются в момент подписывания зоны автоматически, в виде отдельного файла с именем вида keyset-FQDN_зоны. Эти файлы (а точнее, информацию из них) надо будет распространить на все сервера, которым нужно будет участвовать в процессе безопасного кэширования данных подписанной зоны. Эта операция, в случае подписи одиночной зоны, не связаной с глобальной DNSSEC-иерархией, будет проводиться вручную. В случае, если зона хранится в Active Directory, ситуация улучшится – достаточно будет добавить trust anchor для нужной зоны на один сервер и указать, что надо распространить этот trust anchor на весь лес.

Терминология DNSSEC : Записи DS

Пом

имо всех уже перечисленых выше плюсов, у DNSSEC есть ещё один – безопасное делегирование. Суть в том, что в родительской зоне есть запись, подтверждающая факт существования делегирования, и делающая это безопасно. Это как раз запись типа DS. Существуя в составе родительской зоны (у которой тоже проверяема целостность), она даёт возможность проверить DNSKEY. Как же будет устроена эта запись? Давайте разберёмся на примере пары записей.

 dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz
     fwJr1AYtsmx3TGkJaNXVbfi/
     2pHm822aJ5iI9BMzNXxeYCmZ
     DRD99WYwYqUSdjMmmAphXdvx
     egXd/M5+X7OrzKBaMbCVdFLU
     Uh6DhweJBjEVv5f2wwjM9Xzc
     nOf+EPbtG9DMBmADjFDc2w/r
     ljwvFw==
     ) ; key id = 60485

 dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A
     98631FAD1A292118 )

Верхняя запись будет в зоне example.com., запись типа DS – в .com. Поля будут обозначать:

• 86400 – TTL записи.
• 60485 – Идентификатор ключа, по которому будет определяться соответствие записей DNSKEY и DS.
• 5 – Идентификатор алгоритма подписи (5 – это RSA/SHA-1).
• 1 – Идентификатор алгоритма дайджеста (1 – это SHA-1).

Терминология DNSSEC : Записи DLV – “подстраховка”

DLV (это от DNSSEC Look-aside Validation) – расширение протокола DNSSEC. Задача его достаточно проста. DNSSEC требует, чтобы подлинность запроса была проверяема по всей цепочке – то есть, необходимо, чтобы при запросе можно было проверить и целостность запроса, и корректность подписи зоны, и корректность делегирования зоны (т.е. есть ли наша зона в родительской), а после – проверить целостность родительской и так до “точки”. По сути, то же самое, что в PKI, когда мы говорим про т.н. certificate chain – когда надо проверить каждый сертификат на целостность/содержимое/отзыв, а после – родительский и так до доверенного корневого.

Вот такая схема имеет свою проблему. Она, по сути, приводит к тому, что внедрение DNSSEC зависит от его внедрения на “точке”, после – на национальных зонах, и так далее. Просто подписать конкретную зону без доверенного делегирования со стороны родительской не получится – т.е. подписать получится, только вот проверку она проходить не будет.

В результате придуман выход. Он прост. Если система при проверке не находит запись в родительской зоне, то она не сразу говорит “Всё плохо”, а проверяет, не зарегистрирована ли специальная DNSSEC DLV-запись в служебном пространстве имён с FQDN = dlv.isc.org.

То есть, вот решил я подписать зону dnssec.atraining.net.. А в родительской зоне – atraining.net. – я по какой-то причине сделать DNSSEC-делегирование не могу. Благодаря механизму DLV в таком сценарии становится возможным реализация “полноценного” DNSSEC. Мне лишь надо зарегистрировать имя dnssec.atraining.net.dlv.isc.org., которое разрешалось бы в что-то вида:

dnssec.atraining.net.dlv.isc.org. TTL_записи IN DLV идентификатор_ключа код_алгоритма_проверки_целостности код_алгоритма_генерации_дайджеста (D5D722703D848E85D85E8A8442AF47512B385418)

Где идентификатор_ключа – это число, которое совпадает с key id у DNSKEY, коды алгоритмов – такие же, как у DNSKEY и RRSIG.

Благодаря этой схеме централизованного хранения “страховых” DLV-записей Вам не надо вручную скачивать и распространять по клиентам ключи DNSSEC-зон, которые не обладают DNSSEC-родителями. Хотя вот DNSKEY от dlv.isc.org. Вам всё ж скачать и поставить придётся. Я бы предложил сделать это на уровне всего домена Active Directory, т.е. добавить этот trust anchor централизованно – это сразу же откроет возможность использовать этот механизм у всех DNSSEC-enabled серверов. Скачать ключ можно по адресу https://ftp.isc.org/www/dlv/dlv.isc.org.key.

Структура DLV, в общем-то, такая же, как у DS, что логично, поэтому детально мной здесь не расписывалась.

Начинаем развёртывать DNSSEC: генерация ключевых пар

Для начала Вам нужно создать ключевые пары – ZSK и KSK.

В случае с Windows Server 2008 R2 технически это будет делаться утилитой dnscmd.exe, а храниться результирующие ключевые пары будут в локальном хранилище сертификатов компьютера, в контейнере MS-DNSSEC, в виде самоподписаных сертификатов. Я не углубляюсь в детали функционирования хранилища сертификатов, предполагая, что тема DNSSEC и так достаточно обширна, а про сертификаты можно и отдельно поговорить будет.

Генерация ZSK

Выполняем команду:

dnscmd.exe /OfflineSign /GenKey /Alg rsasha1 /Length длина /Zone имя_зоны /SSCert /FriendlyName AtrainingRuZSK /ValidFrom может_использоваться_начиная_с_этой_даты_и_времени /ValidTo и_по_эту_дату_и_время

(понятное дело, от администратора. причина проста – нам надо этой командой не только создать ключевую пару, что может сделать и не-админ, а ещё и, возможно, сделать новый контейнер в локальном хранилище сертификатов и записать туда новый сертификат. это уже требует нужный уровень полномочий.)

Разбираемся, что мы указываем в виде ключей (большинство, замечу, фиксированные).

• /OfflineSign и /GenKey– обязательный ключ, чтобы dnscmd понял, какую операцию будем делать (создание новой клювой пары).
• /Alg – используемый алгоритм. В реализации Windows Server 2008 R2 – только RSA+SHA-1, поэтому данный ключ, по сути, константа.
• /Length – длина ключа. Для ZSK можно выбрать 1024 или 2048 бит. Допустимый технически диапазон – от 512 до 4096. Длина ключа не сильно повлияет на загрузку промежуточных узлов, а лишь на время генерации ключевой пары.
• /Zone – имя подписываемой зоны. Имя – это FQDN. Он “с точкой”. Люди, пишущие FQDN без точки, должны прервать чтение статьи прямо сейчас и пойти удавиться.
• /SSCert – говорим, что результат генерации надо хранить в виде самоподписанного сертификата в дефолтном DNSSEC’овском контейнере.
• /FriendlyName – то, что поможет нам отличать получившийся сертификат от других. Ни на что с точки зрения функционала не влияет, просто description у сертификата.
• /ValidFrom и /ValidTo – Диапазон, в пределах которого ключ считается действительным для использования. Данная пара параметров является необязательной. Если всё ж решите задать – помните, что задаётся в формате ГГГГММДДЧЧММСС (год-месяц-день-час-минута-секунда). Если не указано, то все равно создаётся по следующей логике: время начала использования берётся текущее минус 1 час, время завершения использования – начало+5 лет.

Генерация KSK

Выполняем похожую команду:

dnscmd.exe /OfflineSign /GenKey /Alg rsasha1 /Flags KSK /Length длина /Zone имя_зоны /SSCert /FriendlyName AtrainingRuKSK /ValidFrom может_использоваться_начиная_с_этой_даты_и_времени /ValidTo и_по_эту_дату_и_время

Отличия – другая рекомендованная длина (от 2048 до 4096 бит), дополнительный ключ /Flags KSK, показывающий в битовом поле “назначения ключевой пары”, что это KSK, ну и другое FriendlyName, чтобы не запутаться, т.к. ZSK и KSK хранятся в одном контейнере.

Теперь сразу же делаем нелюбимую всеми администраторами (до первого прецедента с показательным расстрелом виновных) процедуру – резервное копирование.

Резервное копирование ключей DNSSEC

Вам необходимо открыть оснастку управления сертификатами, зайти в хранилище локального компьютера, найти там контейнер MS-DNSSEC и там, в /Certificates, найти по FriendlyName свежесозданные самоподписанные сертификаты. Их необходимо выгрузить вместе с закрытыми ключами, защитить надёжными паролями и хорошо спрятать.

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

Включаем DNSSEC: Операции с DNS-зонами

Подписываем зону

У нас будет два варианта, отличающихся друг от друга – подпись зоны, хранящейся в текстовом файле, и подпись зоны, хранящейся в Active Directory.

С точки зрения DNSSEC, это несущественно, потому что DNSSEC никак не регламентирует хранение зоны, у него другая задача. Однако с точки зрения администратора, выполняющего эту задачу, различия есть.

Не забудьте, что вне зависимости от метода хранения зоны, у DNSSEC-зоны не должны использоваться динамические обновления. Под это подпадают как динамические обновления с точки зрения хостов (добавление/обновление записей), так и результаты работы механизмов aging/scavenging. Их тоже надо выключить на DNSSEC-зонах.

Приступим. Команда

dnscmd.exe /OfflineSign /SignZone /Input исходный_файл_зоны /Output результирующий_файл_зоны /Zone FQDN_зоны /SignKey /ValidFrom время_начала_действия_подписи /ValidTo время_окончания_действия_подписи /Cert /FriendlyName Имя KSK-сертификата /signkey /cert /friendlyname Имя ZSK-сертификата

сделает нам подписанную зону, плюс ещё 2 файла – dsset-FQDN_зоны и keyset-FQDN_зоны, где FQDN_зоны – тот же, который идёт в команде после ключа /Zone.

Порядок указания KSK- и ZSK-сертификатов не критичен; утилита по битовым флагам догадается, кто KSK.

Исходный файл зоны по умолчанию лежит в %WINDIR%System32DNS.

Флаги /ValidFrom и /ValidTo, как обычно, опциональны.

Теперь наша зона готова. Можно удалить её неподписанную копию и загрузить подписанную (т.е. просто заменить файл). Сервер поймёт и теперь будет возвращать клиентам дополнительные типы записей (если клиенты намекнут ему до этого, что они умеют читать такие типы записей). Но если клиент – это другой DNS-сервер, то как же он будет проверять, правду ли ему прислали или нет? Чтобы он мог это делать, ему нужны криптографические ключи, которые помогут понять, целостна ли RRSIG/NSEC/NSEC3 или нет.

Распространяем trust anchor’ы нашей подписанной зоны

Эти ценные записи типа DNSKEY будут находиться в файле, который автоматически создался при предыдущем шаге (подписи зоны) и начинается с keyset-. Их необходимо добавить на другие сервера. Есть два способа – через графический интерфейс и через dnscmd.exe. Через графический интерфейс достаточно просто: зайдите в Properties у сервера, выберите вкладку Trust Anchors, нажмите Add... для добавления информации о новой “чужой” подписанной зоне, информацию из которой этот сервер должен научиться проверять, и введите два параметра – FQDN зоны и её открытый ключ (находится в файле путём открытия его Блокнотом). Так как речь о реализации в Windows Server 2008 R2, которая кроме RSA/SHA-1 других вариантов не знает, особо настраивать в New Trust Anchor, кроме вышеупомянутых двух полей, нечего.

Вариант с командной строкой подразумевает ввод команды:

dnscmd.exe /TrustAnchorAdd FQDN_зоны DNSKEY флаги_из_файла 3 5 открытый_ключ_из_файла

Флаги из файла – это то, число, которое после параметра DNSKEY в keyset-файле, открытый ключ – аналогично. Файл маленький, не перепутаете.

Включаем DNSSEC: Подготавливаем DNS-сервера

Этот шаг будет нам необходим, когда мы захотим защитить канал связи между серверами и клиентами. Вспомните, что DNSSEC не шифрует передаваемые данные, следовательно, сохраняются риски для конфиденциальности запросов и ответов. Плюс, в текущей реализации клиентских ОС Microsoft отсутствует ряд полноценного функционала DNSSEC (NSEC3-записи), что добавляет проблем. Предлагаемый вариант решения – IPSec – обычно связан с достаточно тщательной и не самой простой настройкой. Поэтому нам надо и заранее подготовиться к тому, чтобы DNS-клиенты могли безопасно подключаться к серверам, и сделать это максимально централизованно и просто. Хороший вариант решения – выдать всем DNSSEC-серверам специальные цифровые сертификаты, подтверждающие их (серверов) подлинность и целевое назначение. Это можно будет сделать централизовано, через групповые политики, и это ничему не помешает. Тогда для защиты подключений клиентов (притом уже полноценной, с шифрованием запросов/ответов), надо будет лишь включить данный функционал с клиентской стороны.

Т.е. мы разбиваем комплексную задачу “защита ‘последней мили’ – от DNS-сервера до клиента” на части, которые могут быть сделаны отдельно и не помешают другим задачам.

Для начала создайте в домене группу с названием, например, DNSSEC Servers. В эту группу мы будем добавлять учётные записи DNS-серверов, на которых будет развёрнут DNSSEC. Это будет удобным способом ограничить запрос специального DNSSEC-сертификата только нужными серверами.

Теперь откройте редактор шаблонов сертификатов, хранящихся в лесу Active Directory и сделайте следующее:

• Возьмите шаблон с названием RAS and IAS Server и сделайте его копию (Вам предложат выбор типа шаблона – V2 (2003 Enterprise) или V3 (2008 Enterprise), выберите V2). Это сократит объём работы. Назвать шаблон можно как-то наглядно – DNSSEC Server, например.
• Откройте сертификат и убедитесь, что в нём стоит опция Publish certificate in Active Directory (на вкладке General). Также у сертификата должен быть разрешен экспорт закрытого ключа (это называется Allow private key to be exported).
• Теперь надо будет добавить нужные применения сертификата. Это делается во вкладке Extensions. Необходимо, чтобы у нашего шаблона были следующие применения:
  • Client Authentication
  • Domain Name System (DNS) Server Trust
  • IP security IKE intermediate
  • Server Authentication

  Если не нашли Domain Name System (DNS) Server Trust, то сделайте New Application Policy с нужным именем (Domain Name System (DNS) Server Trust) и OID = 1.3.6.1.4.1.311.64.1.1.

• Теперь про назначение ключа. В Key Usage у нашего сертификата должно быть следующее – в плане подписи Digital signature and Signature is proof or origin (nonrepudiation), а в плане шифрования – Allow key exchange only with key encryption (key encipherment), Allow encryption of user data и пункт, делающий поддержку этих назначений обязательным – Make this extension critical. То есть данный шаблон будет создавать сертификаты, которые будут подтверждать целостность и аутентичность, а ключевая информация сможет использоваться как для шифрования других ключей в ходе обмена ключами, так и для защиты передаваемых данных. Заметьте, что архивировать этот тип сертификатов не получится.
• Теперь зайдите на вкладку Security и поменяйте группу тех, кому можно получать сертификат, на созданную в начале операции DNSSEC Servers. В плане разрешений Вы должны указать права Enroll и Autoenroll.

Шаблон создан. Осталось выбрать CA, которые будут иметь право его выдавать, и добавить его на них, а после – зайти в групповую политику и поставить автоматический запрос сертификата. Если забыли, где это – это примерно в Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Public Key Policies -> 'Certificate Services Client – Auto-Enrollment'. Поставьте автоматический запрос, обновление и удаление отозваных сертификатов.

В общем-то, это всё – теперь Вам будет достаточно добавить учётную запись сервера, на котором развёрнут DNS-сервер, в группу DNSSEC Servers, и он сам впрок запросит для себя сертификат, который сделает после возможным защиту подключения к нему со стороны клиента.

DNSSEC: Настройки со стороны клиентов (NRPT)

Вынес в отдельную статью про настройку NRPT.

А дальше?

А дальше – во второй части статьи. Там мы уже поговорим про IPSec и делегирование дочерних зон. А то сразу слишком много получится.

Знакомая многим ситуация: компьютер включен, доступ в Интернет есть, но не открывается какой-то определенный сайт или сервер в сети. Например: не доступен игровой сервер или игра сильно тормозит при подключении к нему. Что делать? Ответ прост – проверка на пинг и трассировка! Другими словами можно проверить доступность сетевых ресурсов с помощью диагностических методов, самые распространённые из которых — утилиты Ping, Tracert/Traceroute и MTR/WinMTR. Давайте рассмотрим подробно каждую из данных утилит.

Сетевая утилита Ping — это самый простой способ проверить доступность любого сетевого ресурса. При условии, что у этого ресурса открыты «пинги» из вне, то есть разрешено использование протокола ICMP.

Как это работает? Команда Ping отправляет небольшие пакеты с данными на сервер, который надо проверить. В ОС Windows по умолчанию посылается серия из 4-х таких пакетов. В ОС Linux пакеты посылаются непрерывно, пока пользователь не прервёт операцию. Спустя некоторое время от сервера приходит ответ — в виде тех же пакетов, какие и были отправлены. Если число отправленных и полученных пакетов совпадает — это значит сервер «живой» и никаких проблем с его доступностью не наблюдается.

Как пропинговать сайт или сервер в Windows?

Ping – это консольная утилита, которая запускается с помощью командной строки. Она присутствует во всех версиях ОС Windows. Я буду показывать её работу на примере Windows 11.

Нажимаем правой кнопкой мыши на кнопку «Пуск» чтобы открылось дополнительное меню. Там надо выбрать вариант «Терминал»( в Windows 10 это «Командная строка»):

В командной строке введите команду ping, потом через пробел введите IP-адрес или доменное имя сайта(название), доступность которого надо проверить. Для примера запустим пинг на сайт ya.ru вот такой командой:

ping ya.ru

Пример:

Смотрим результат: отправлено было 4 пакета размером по 32 байта. Время прохождения каждого пакета составило в среднем 22 мс. Все отправленные пакеты дошли до сервера и вернулись обратно.

По умолчанию команда Ping в ОС Windows отправляет всего 4 пакета данных.

Чтобы отправить больше пакетов, можно задать их количество с помощью параметра –n. Пример для отправки 10 тестовых пакетов:

ping –n 10 yandex.ru

Результат будет таким:

Как вариант, можно использовать команда ping с параметром «-t», чтобы пинговать сервер бесконечно, до принудительного прекращения задачи, как в Linux. Команда будет выглядеть так:

ping ya.ru -t

Пример выполнения команды пинг:

Чтобы остановить бесконечный пинг сервера или хоста по IP-адресу — воспользуйтесь комбинацией клавиш Ctrl + C.

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

Как проверить пинг до сервера в Linux?

В операционных системах семейства Linux (в том числе и на FreeBSD, MacOS и Android) проверка пинга до сервера или хоста по IP-адресу тоже осуществляется с помощью команды ping. Она вызывается из командной консоли (терминала).

Запускаем терминал. На некоторых ОС Линкус значок терминала есть прямо на рабочем столе, а на каких-то надо открывать меню и запускать его оттуда. В KDE, например, через раздел меню Администрирование > Терминал.
В терминале вводим команду ping, адрес проверяемого ресурса и нажимаем клавишу «Enter».

В отличие от систем семейства Windows, по умолчанию проверка пинга в Linux идет непрерывно, пока пользователь не прервёт этот процесс с помощью комбинаций клавиш Ctrl + C.

В Linux так же можно задавать нужные параметры с помощью аргументов, но они могут отличаться от аргументов в ОС Windows, которые я показывал выше. Например в Линуксе количество тестовых пакетов задаётся через агрумент «-c», а не через «-n». Для того, чтобы увидеть все доступные агрументы команды Пинг — введите вот такую команду:

ping -h

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

Трассировка маршрута в сети: команды tracert и traceroute

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

Трассировка маршрута в Windows 11

В операционной системе Windows 11, а так же практически всех предыдущих версиях – Windows 10 и старше — трассировка маршрута до сетевого ресурса выполняется с помощью интегрированной в командную оболочку утилиты tracert.

Чтобы ей воспользоваться, снова открываем командную строку и пишем команду:

tracert ya.ru

Так мы запустим трассировку от нашего ПК до сервера Яндекс. Пример:

Теперь смотрим в полученный результат трассировки  — он показывает весь маршрут, через который прошел запрос до сайта.

Каждая строка в трассировке — это промежуточный узел ( как правило, маршрутизатор). Эти узлы принято называть прыжками или «хопами».

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

Теперь сделаем ещё одну трассировку — google.com. И вот тут в результатах у нас появится очень интересный момент:

А именно строчка со «звёздочками». Что они означают? Многие новички этого пугаются и считают что это сетевая проблема. Это не совсем так! «Звёздочки» говорят о том, что на данном хопе ответ от сервера не получен. Проблема ли это? В этом случае — нет. Это технический узел и на пользовательские запросы он не отвечает.

Проблема была бы в том случае, если после какого-то из хопов все последующие хопы заканчивались бы звёздочками, а сама трассировка закончилась бы ничем. Вот в этом случае надо искать причину. Чаще всего она на том узле, который ответил последним. Но это не точно)))!

Как сделать трассировку в Linux

В операционных система семейства Linux тоже можно сделать трассировку. Правда там команда несколько отличается: это уже не tracert — трассировку выполняет утилита traceroute. Запускается она точно так же, как и пинг — из консоли.

В некоторых дистрибутивах утилита traceroute по умолчанию не установлена. Потому надо её установить. В Ubuntu b Debian это делается командой:
$ sudo apt install traceroute
В RHEL и CentOS — командой:
$ yum install traceroute -y

В остальном, использование данной утилиты ничем особо не отличается от того, как мы это делали в Windows 11. Для примера сделаем трассировку до Яндекса. Команда:

traceroute yandex.ru

Результат выполнения:

Как можно заметить, результат трассировки маршрута выдаётся так же по хопам. Если какой-то узел не ответил — помечается «звёздочками».

Использование утилит MTR и WinMTR для диагностики сети

Хочу рассказать о ещё одной очень полезной для диагностики сетевых проблем утилите – MTR(My traceroute). Она доступна во всех дистрибутивах Linux и сочетает в себе функционал двух перечисленных выше команд: Ping и Traceroute. Как Traceroute она выводит полную трассировку маршрута, который проходят сетевые пакеты до нужного узла. Кроме этого, в режиме реального времени, ведётся пинг до каждого из промежуточных узлов для определения время отклика информации о потерях пакетов на каждом шаге.
Запускается утилита MTR всё так же из терминала командой mtr. Пример:

mtr ya.ru

Результат получился такой:

Отправка тестовых пакетов будет идти бесконечно. Чтобы остановить диагностику — нажмите комбинацию клавиш Ctrl+C.

В моём примере результат показывает, что несмотря на наличие технического узла, который не отзывается, конечный сервер доступен, а все отправленные пакеты (см. колонку Snt) проходят до конечного узла. При этом процент потерь пакетов (см. колонку Loss) равен нулю. Всё отлично!

Используя аргумент -r при вводе команды MTR, Вы  получите результат диагностики виде отчета. Информация будет выведена в консоль Linux.

Трассировка WinMTR в Windows 11

В операционных системах Windows нет такого удобного встроенного инструмента, как программа MTR. К счастью, существует специальная утилита WinMTR, выпущенная добрыми людьми. Скачать можно с официального сайта WinMTR — ссылка. Она работает в Portable-режиме, то есть дополнительная установка на ПК не требуется и программа доступна к использованию сразу же после скачивания.
Запускаем WinMTR, в открывшемся окне в строке «Host» вводим адрес проверяемого ресурса:

Нажимаем кнопку «Start» и запускаем диагностику. Спустя пару минут смотрим результат.

Что удобно, в этой утилите можно полученные результаты не только скопировать в буфер обмена, но и сразу экспортировать в текстовом или HTML-формате, чтобы потом отправить, например, в техподдержку провайдера.