Проверка доступности услуги через MTR.

MTR — утилита для проверка доступности сервера или сайта, показывающая маршрут пакетов до услуги и потери на промежуточных узлах.
MTR - это простой инструмент диагностики сети (услуги, сервера, сайта) из командной строки или оболочки (WinMTR). Он объединяет в себе функциональность программ traceroute и ping. Подобным образом, как traceroute, команда mtr выводит информацию о маршруте, показывает список узлов, маршрутизаторов через которые проходит пакет. Тем не менее, mtr показывает больше информации, чем traceroute: она определяет путь к удаленному серверу, выводит процента отклика и потерь, а также времени отклика всех сетевых переходов в маршруте между Вашей локальной системой и удаленными серверами. Когда ее стоит применять? Когда есть подозрения на потери пакетов. По MTR можно увидеть, есть ли потери пакетов, проверить на каком IP-узле потери пакетов, после чего можно найти и определить регионального или магистрального провайдера, через которого возникла такая ситуация.

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

Проверка на ОС Windows.
Если есть ситуации с RDP-подключением типа: тормоза, фризы, лаги, зависание и периодическое выкидывание с сервера, обрыв или плохое RDP-соединение, нужно выполнять провекр через WinMTR, т.к. возможно есть потери пакетов на маршруте от Вас к серверу. WinMTR выводит информацию о маршруте, показывает список маршрутизаторов через которые проходит пакет. Запустите на Вашем компьютере утилиту WinMTR для Windows.
Скачать: https://sourceforge.net/projects/winmtr/
Где в программе, для проверки укажите IP-адрес Вашего сервера или доменное имя (только название сайта без www или https). После того, как будет отправлено хотя-бы 1000 пакетов, сорхраните результат нажав Export Text. Предоставьте, пожалуйста техподдержке в тикет-системе результат проверки к серверу для анализа ситуации. Или можете самостоятельно проанализировать согласно рекомендациям ниже.

Проверка на ОС Linux.
Если у Вас используется Linux, тогда выполните команду:
mtr --report -n -c 1000 IP
Где IP - Ваш IP или доменное имя.
После выполнения сохраните скриншот с итогами выполнения команды, и приложите в тикет-запросе в техподдержку, для анализа нами.
Или попробуйте проанализировать самостоятельно.

Объяснение значений и результатов WinMTR

Hostname - доменное имя или IP-адрес узла
Nr - порядковый номер узла в маршруте
Loss % - процент потерянных запросов-ответов от данного узла
Sent - отправлено запросов данному узлу
Recv - получено ответов от него
Best - наименьшее (наилучшее) время задержки
Avrg - среднее время задержки
Worst - наибольшее (наихудшее) время задержки
Last - время задержки последнего полученного пакета

Нам важен параметр - Loss, процент потерянных пакетов от узла. WinMTR использует тот же протокол ICMP, что и утилиты ping, tracert, pathping. Причинами для беспокойства могут быть потери когда Loss = 5 и более %.

Анализ и результаты.

Вариант 1. Потери пакетов 30-50% на промежуточных узлах.
Например, по результатам видно, что были потери в диапазоне ІР 217.161.68.33-217.161.68.34. Тогда согласно выполненной проверке через MTR, есть потери пакетов только на некоторых указанных узлах у магистрального интернет-провайдера, это Vodafone Group PLC. Но на самой самой услуге (сервер или сайт) потерь пакетов нет. Полагаем, что ситуация связана с перегруженными каналами некоторых провайдеров Европы - Vodafone Group PLC и др. Полагаем, интернет-провайдерам известна данная ситуация, но мы не располагаем информацией, когда они решат данный вопрос. Возможно на протяжении от нескольких часов или дней ситуация изменится. Возможно у данного провайдера проводятся технически плановые или внеплановые работы по изменению маршрутизации или установке нового оборудования. Т.к. это третья сторона, мы не можем повлиять на их работу. В данной ситуации мы можем посоветовать Вам попробовать воспользоваться VPN или другим устройством для подключения (компьютер, ноутбук, телефон) который использует другого провайдера, для которого маршрут пакетов к Вашему серверу может отличаться от Вашего нынешнего.

Вариант 3. Потери пакетов на конечных узлах.
При выслких потерях на нескольких конечных узлах и на сервере (сайте), возможными причинами есть высокая загруженность сервера, нехватка ресурсов сервера, или DDoS на сайт/сервер с целью его положить. В таком случае нужно выполнять проверки на самом сервере. Можете выполнять проверки самостоятельно или обратится в нашу техподдержку за помощью.

Вариант 3. Потери пакетов на одном или нескольких узлах.
Если выполнении проверок потеря пакетов на столбце Loss, только на одном узле есть потери (например 95%-100%), то вероятно, данный провайдер решил защитить свой маршрутизатор от DDoS атаки и настроил его таким образом, чтобы он не отвечал на большую часть ICMP запросов. Если бы было действительно 95% потерь, то эти потери отразились бы на последующих прыжках и в столбце Loss, после него, мы бы видели не 0%, а значение с разбросом от 85% до 95%, тогда это были бы действительно потери. Но при паралельной проверке доступности сайта/сервера с других стран, они доступны.

В таком случае, полагаем, что ситуация связана с блокировкой сайта магистральным или региональным интернет-провайдером, по жалобе например РКН. Т.к. это третья сторона, мы не можем повлиять на их работу. Если Вашего домена нет в базе РКН, Вы можете самостотельно обратитится к ним для исправления стурации. В данной ситуации мы также можем посоветовать Вам попробовать воспользоваться VPN или другим устройством для подключения (компьютер, ноутбук, телефон) который использует другого провайдера, для которого маршрут к Вашему серверу может отличаться от Вашего нынешнего. Также возможно перенести сайт на другой домен (доменное имя), или попробовать перенести сайт на субдомен (если он не заблокирован на уровне регистратора домена).

Выводы.
Трассировка WinMTR отображает только устройства сетевого уровня, то есть это могут быть: серверы, роутеры/маршрутизаторы, L3 коммутаторы, на интерфейсах которых прописаны IP-адреса и сервера. Устройств канального и физического уровня модели OSI 7 в трассировки нет, так как им для работы не нужны IP-адреса, хотя именно эти устройства, а также некачественные линии связи, обычно являются причинами потерь в канале связи.