Кто-нибудь может сказать мне, как получить сценарий резервного копирования DB с удаленного сервера в MySQL с помощью утилиты командной строки? Я использую следующую команду, но не работаю:…

Как запретить атакующему IP с Fail2Ban вручную с помощью командной строки?

Есть ли какой-нибудь способ пинговать конкретный адрес IP с помощью C? Если бы я хотел пинговать www. google.com с определенным количеством пингов или, если уж на то пошло, с локальным адресом, мне…

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

Этот вопрос возник сегодня на работе, и я не смог его решить. MySQL сервер 5.1.67 Как пользователь mysql root я создал DB, пользователя и предоставил все привилегии с удаленного IP mysql>…

Я попробовал использовать Ping.pingecho(10.102.52.42, 30) для достижимости удаленного хоста. Этот оператор возвращает null, даже если я могу пинговать IP вручную. Есть ли эффективный способ…

Как установить соединение с сокетом с помощью командной строки Windows? Например, мой сокет IP и номер порта 192. 168.1.180:9760 Я просто хочу отправить команды на этот IP из командной строки.

Есть ли вообще возможность пинговать веб-домен из другого места в командной строке ? Я нашел несколько сайтов, которые предоставляют такого рода услуги, но мне было интересно, могу ли я сделать это…

Мне нужно запустить распределенный тест с некоторым параметром командной строки, а также мне нужно передать свой сервер IP с -Djava.rmi.server.hostname=IP, так как я запускаю его из командной…

Борьба за миллисекунды.

Для многих задач задержки между клиентом и сервером критически важны, например в онлайн играх, видео/голосовых конференциях, IP телефонии, VPN и т.д. Если сервер будет слишком удален от клиента на уровне IP-сети, то задержки (в народе «пинг», «лаг») будут мешать работе.

Географическая близость сервера не всегда равна близости на уровне IP маршрутизации. Так, например, сервер в другой стране может быть «ближе» к вам, чем сервер в вашем городе. Все из-за особенностей маршрутизации и построения сетей.

Как выбрать сервер максимально близкий ко всем потенциальным клиентам? Что такое связность IP-сетей? Как направить клиента на ближайший сервер? Разберемся в статье.

Измеряем задержки

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

ICMP — обычный ping

Будем использовать юниксовую утилиту ping, она позволяет вручную установить интервалы между посылками пакетов, чего не умеет версия ping для windows. Это важно, потому что, если паузы между пакетами долгие, можно просто не увидеть, что происходит между ними.

Размер пакета (опция -s) — по умолчанию утилита ping посылает пакеты размером 64 байта. С такими маленькими пакетами могут быть не заметны явления, проявляющиеся с большими пакетами, поэтому мы будет устанавливать размер пакета 1300 байт.

Интервал между пакетами (опция -i) — время между посылками данных. По умолчанию пакеты посылаются раз в секунду, это очень долго, реальные программы шлют сотни и тысячи пакетов в секунду, поэтому установим интервал 0.1 секунду. Меньше просто не разрешает программа.

В итоге команда выглядит так:

ping -s 1300 -i 0.1 yandex.ru

Такая конструкция позволяет увидеть более реалистичную картину задержек.

Пинг по UDP и TCP

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

.

Утилита nping от разработчиков знаменитого сканера nmap умеет генерировать любые пакеты. Ее можно использовать в том числе для измерения задержек.
Так как UDP и TCP работают на определенных, нам нужно «пинговать» конкретный порт. Попробуем пропинговать TCP 80, то есть порт веб-сервера:

$ sudo nping --tcp -p 80 --delay 0.1 -c 0 microsoft.com

Starting Nping 0.7.80 ( https://nmap.org/nping ) at 2020-04-30 13:07 MSK
SENT (0.0078s) TCP 10.0.0.1:63236 > 13.77.161.179:80 S ttl=64 id=49156 iplen=40  seq=3401731188 win=1480
SENT (0.1099s) TCP 10.0.0.1:63236 > 13.77.161.179:80 S ttl=64 id=49156 iplen=40  seq=3401731188 win=1480
RCVD (0.2068s) TCP 13.77.161.179:80 > 10.0.0.1:63236 SA ttl=43 id=0 iplen=44  seq=1480267007 win=64240 <mss 1440>
SENT (0.2107s) TCP 10.0.0.1:63236 > 13.77.161.179:80 S ttl=64 id=49156 iplen=40  seq=3401731188 win=1480
RCVD (0.3046s) TCP 13.77.161.179:80 > 10.0.0.1:63236 SA ttl=43 id=0 iplen=44  seq=1480267007 win=64240 <mss 1440>
SENT (0.3122s) TCP 10.0.0.1:63236 > 13.77.161.179:80 S ttl=64 id=49156 iplen=40  seq=3401731188 win=1480
RCVD (0.4247s) TCP 13.77.161.179:80 > 10.0.0.1:63236 SA ttl=42 id=0 iplen=44  seq=2876862274 win=64240 <mss 1398>

Max rtt: 112.572ms | Min rtt: 93.866ms | Avg rtt: 101.093ms
Raw packets sent: 4 (160B) | Rcvd: 3 (132B) | Lost: 1 (25.00%)
Nping done: 1 IP address pinged in 0.43 seconds
 
 

По умолчанию nping посылает 4 пакета и останавливается. Опция

включает бесконечную посылку пакетов, чтобы остановить программу, нужно нажать Ctrl+C. В конце будет показана статистика. Видим, что среднее значение rtt (round-trip time) равно 101мс.

MTR — traceroute на стероидах

Программа

(англ. My Traceroute) — продвинутая утилита для трассировки маршрутов до удаленного хоста. В отличии от обычной системной утилиты traceroute (в windows

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

Рассмотрим случай, когда сервер доступен по 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-дистрибутивах.

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

root@support:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 52:54:00:c8:e6:45 brd ff:ff:ff:ff:ff:ff
    inet 149.154.66.7 peer 10.0.0.1/32 brd 149.154.66.7 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 2a01:230:2::d98/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:fec8:e645/64 scope link
       valid_lft forever preferred_lft forever

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

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

inet 149.154.66.7 peer 10.0.0.1/32 brd 149.154.66.7 scope global eth0

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

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

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

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

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

root@support:~# ip r
default via 10.0.0.1 dev eth0 onlink
10.0.0.1 dev eth0 proto kernel scope link src 149.154.66.7

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

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

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

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

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

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

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

iptables-save > rules.tmp

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

iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
iptables -F

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

iptables-restore < rules.tmp

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

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

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

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

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

/etc/init.d/NetworkManager stop

ifconfig eth0 IP-адрес сервера netmask 255.255.255.255
route add 10.0.0.1 eth0
route add default gw 10.0.0.1

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

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

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

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

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

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

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

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

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

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

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

VipNET-координатор HW100 реализует защищенную связь в сетях обработки персональных данных. АРМ СГО выходит на сервер СГО по защищенной сети, по защищенной сети он также выходит и на сервер Е-Услуг. Если у Вас на АРМ возникают проблемы с доступом к указанным подсистемам попробуйте выполнить следующие действия:

Самый простой и легкий способ

Проще всего перезагрузить VipNET-координатор и коммутатор D-Link. В большинстве случаев, это решит проблему.

1. Локализуйте проблему

Необходимо выяснить на каком участке соединения возникают проблемы: от АРМ до координатора, от АРМ до сервера, или от АРМ до Е-Услуг.

Если сбой возник сразу на всех участках — вполне возможно, что проблема в 5-портовом коммутаторе D-Link, через который АРМ СГО подключена к VipNET-координатору. Попробуйте перезагрузить коммутатор. Также стоит проверить сетевые кабеля, идущие от коммутатора D-Link к VipNET-координатору и от коммутатора D-Link к АРМ СГО.

Как проверить сетевой кабель

Важное замечание: соединять для проверки 2 компьютера между собой тестируемым сетевым кабелем не стоит — работать не будет. Почему? Погуглите на тему стандартов RJ-45 (стандарты А и В).

Помимо этого, проблема может быть и в самим VipNET-координатором. Запустите пинг координатора с АРМ СГО.

2. Проверьте подключение к Интернету

Если координатор с АРМ пингуется, а на Е-Услуги выйти не удается, вполне возможно, что пропало подключение к сети Интернет. Проверьте доступность интернета на других компьютерах (не входящих в защищенную сеть).

Если подключение к сети Интернет есть, проверьте состояние индикатора порта LAN-0 на VipNET-координаторе. Он должен гореть зеленым светом. Если это не так — перезагрузите координатор.

У VipNET-координатора есть IP-адрес, по которому его можно пропинговать из локальной сети организации ( с любого другого компьютера школьной сети). Можно, также, подключиться к координатору с другого компьютера напрямую через сетевой кабель. В любом случае, попробуйте с любого другого компьютера выполнить команду ping на IP-адрес VipNET-координатора.

Как узнать IP-адрес VipNET-координатора

Локальный IP-адрес VipNET-координатора должен быть наклеен на его корпусе.

3. Проверьте сетевые кабеля

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

Центр управления сетями и общим доступом

Изменение параметров адаптера

Сетевые подключения

Свойства сетевого подключения

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

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

Обрыв соединения с сервером. Трассировка и пинг

«Ааа, помогите, все пропало!» – если ваш внутренний голос реагирует на обрыв соединения с сервером примерно так, этот материал точно для вас. 🙂 Безусловно, со своей стороны мы каждый день делаем все возможное, чтобы ничто не мешало вашей работе в облаке, но случись форс-мажор – будем разбираться. А чтобы быстрее сориентироваться в ситуации и понять, на чьей стороне ошибка, вот вам задача-минимум – во время обрыва первым делом выполните трассировку маршрута и пинг промежуточных узлов. Как все это сделать, сейчас расскажем.

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

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

1. Запустите команду cmd: Win+R > пропишите cmd > ОК.

2. В открывшейся командной строке введите tracert Х.Х.Х.Х (где Х.Х.Х.Х – это IP-адрес сервера или домен) и нажмите Enter.

В примере мы сделали трассировку для google.com.

tracert google.com

Получилось так:

1 2 1 ms 1 ms 1 ms 193.151.89.254
3 5 ms 4 5 1 ms 6 1 ms 7 1 ms 3 ms 1 ms bearline-ic-324086-ffm-b4.c.telia.net [62.115.153.215]
8 1 ms 1 ms 1 ms 108.170.251.129
9 13 ms 13 ms 15 ms 66.249.94.135
10 13 ms 13 ms 13 ms fra15s12-in-f46.1e100.net [216.58.208.46]

Как видим, наши пакеты преодолели десять (их может быть как меньше, так и больше) узлов, и преодолели их успешно. В противном случае, если бы пакеты «споткнулись» на одном из узлов, на нем (и последующих за ним узлах) мы бы увидели:

* * * Превышен интервал ожидания для запроса.

Но даже в таком случае пока не время для выводов – эта запись может означать как потерю пакетов, так и то, что узел сети просто закрыт настройками безопасности. Иногда провайдеры специально настраивают узлы так, чтобы они не отвечали на трассировочные пакеты, дабы снизить нагрузку. Чтобы точно узнать, действительно ли происходит обрыв, и, если да, то где именно, нужно пропинговать каждый из узлов. При трассировке мы получили IP каждого из них, а значит, можем перейти к пингу.

Пинг промежуточных узлов

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

В ОС Windows по умолчанию передается только четыре пакета, чего недостаточно, если проблема проявляется кратковременно. Поэтому нужно снять это ограничение параметром -t (чтобы потом остановить обмен пакетами, нажать CTRL+C).

Теперь по порядку.

1. Запустите команду cmd: Win+R > пропишите cmd > ОК.

2. В открывшейся командной строке введите ping -t Х.Х.Х.Х (где Х.Х.Х.Х – это адрес одного из промежуточных узлов, которые мы узнали при трассировке) и нажмите Enter.

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

Полезно!
Если вам нужно постоянно отслеживать качество соединения, для Windows можно воспользоваться удобной программой PingPlotter.

Итак, пингуем – в десяти отдельных окнах командной строки вводим команды с IP-адресами узлов, которые мы выявили при трассировке. В нашем случае будут такие команды:

ping -t 10.1.1.1
ping -t 193.151.89.254
ping -t 85.195.75.129
ping -t 213.248.79.29
ping -t 62.115.139.50
ping -t 62.115.120.8
ping -t 62.115.153.215
ping -t 108.170.251.129
ping -t 66.249.94.135
ping -t 216.58.208.46

Если в каком-нибудь из окон вы с первых же секунд видите «Превышен интервал ожидания», не спешите кричать: «Попался!». Если следующие узлы пингуются нормально, значит, этот просто закрыт настройками. В нашем случае, например, предпоследний узел (66.249.94.135) сразу же говорит, что интервал превышен, но с пингом десятого узла никаких проблем нет.

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

На чьей стороне ошибка?

Итак, обрыв повторился. Но на этот раз запущенный пинг промежуточных узлов поможет «обличить» виновника. Тут все просто – с какого узла вам начало выдавать «Превышен интервал ожидания», тот и слабое звено.

Кто виноват – ясно, теперь нужно понять, что делать в конкретных ситуациях.

1. Последний узел. Если последний узел сначала пинговался нормально (некоторые Windows-машины вообще не отвечают на пинг, это задается в настройках брандмауэра)…

…а после обрыва начал показывать «Превышен интервал ожидания», обрыв происходит на вашем сервере.

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

2. Любые узлы, кроме последнего. В этом случае обращайтесь одновременно в техподдержку и облачного, и интернет-провайдера. При этом обязательно укажите, как изначально выглядела трассировка маршрута, и составьте перечень узлов с указанием, на каких из них пинг во время обрыва прервался, а на каких нет. Будьте внимательны, это важная информация, не ошибитесь.

3. Все узлы одновременно. Если все окна с пингом начали показывать «Превышен интервал ожидания», проблема в вашем компьютере или сети, к которой он подключен.

Бонус!

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

Для ОС семейства Windows такую оптимизацию проводит утилита Winmtr. Она не нуждается в установке и готова к использованию сразу после распаковки из архива.

Скачать утилиту можно здесь.

Распаковали, запустили, что дальше?

В поле Host укажите конечный сервер, с которым будет проверяться соединение, и нажмите Start:

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

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

Раз мы проверяем соединение с сервером, нас интересуют столбцы Sent (отправлено пакетов) и Recv (получено пакетов). Если значения в этих столбцах не совпадают, значит, качество связи с узлом ухудшилось. Что делать? Обратиться в соответствующую техподдержку.

Столбец Loss поможет просмотреть динамику потерь в процентном соотношении.

Также утилита позволяет копировать текст в удобных форматах (.txt и .html) в буфер обмена (Copy to clipboard) или в отдельный файл (Export).

Двойной щелчок по промежуточному узлу позволит получить дополнительную информацию о нем.

Важно знать!

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

1. Interval (sec) – время обновления данных в секундах.
2. Max host in LRU list – максимальное количество хостов (или IP-адресов, если не активна опция Resolve names) до конечной точки.
3. Ping size (bytes) – размер ICMP-пакета.
4. Resolve names – возможность преобразовать IP-адрес в имя хоста.

А что же линуксоиды?

Для ОС семейства Linux утилита называется просто MTR. Если ее нет в вашей операционной системе, установить ее можно одним из следующих способов:

Debian/Ubuntu/Mint:

$ apt-get install mtr

CentOS/RedHat/Fedora:

$ yum install mtr

У MTR такой же функционал, как у Winmtr, а также схожий графический интерфейс. Запустить утилиту можно командой:

mtr X.X.X.X

где X.X.X.X – это IP-адрес конечного сервера или имя хоста.

В данном случае интересуют следующие столбцы:

• Loss % – процент потерянных пакетов между компьютером-отправителем и промежуточными узлами.
• SNT – общее количество отправленных пакетов.

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

Отдельно отметим возможность запуска утилиты в текстовом (консольном) режиме. Для этого достаточно добавить опцию -t или —curses:

mtr --curses tucha.ua

Рассмотрим еще несколько важных опций MTR, которые могут быть крайне полезны в процессе диагностики сети.

-r или --report

Запускает режим отчета, в котором MTR обработает заданное количество циклов (определенных опцией -c), а затем отобразит статистику и автоматически завершит работу. Этот режим полезен для сбора статистики о качестве сети.

-c COUNT или --report-cycles COUNT

Позволяет задать количество циклов, после которых MTR завершит работу.

-p BYTES или --psize BYTES

Устанавливает размер пакетов в байтах.

-i SECONDS или --interval SECONDS

Задает интервал между отправляемыми пакетами.

-n или --no-dns

Разрешает не использовать DNS, отображает IP-адреса узлов.

-a X.X.X.X или --address X.X.X.X

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

Итого

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

Вот, собственно, и все, кто виноват – выяснили, что делать – тоже. 🙂 Надеемся, материал был вам полезен, а если у вас остались дополнительные околооблачные вопросы, обращайтесь к нам за грамотной консультацией 24/7.

Не удается найти страницу | Autodesk Knowledge Network

(* {{l10n_strings.REQUIRED_FIELD}})

{{l10n_strings.CREATE_NEW_COLLECTION}}*

{{l10n_strings.ADD_COLLECTION_DESCRIPTION}}

  # ping server01
# пинг 192.168.2.200  

  # ping localhost
# ping 127.0.0.1  

  # пинг 0  

  # ping -a server01  

  # пинг -c 5 192.168.2.200  

  # пинг -c 1 server01  

  # ping -v server01
# ping -c 1 -q server01  

  # пинг -b -c 3 -i 20 192.168.2.255  

  # ping -s 100 server01  

  # пинг -t 10 server01  

  # gping server01
# gping --help  

  ping (*** имя вашего сервера ***) -4  

  Ответ от 192.168.1.1: байты = 32, время <1 мс TTL = 64
Ответ от 192.168.1.1: байты = 32, время <1 мс TTL = 64
Ответ от 192.168.1.1: байты = 32, время <1 мс TTL = 64
Ответ от 192.168.1.1: байты = 32, время <1 мс TTL = 64

Статистика пинга для 192.168.1.1:
  Пакетов: отправлено = 4, принято = 4, потеряно = 0 (потеря 0%),
Приблизительное время в оба конца в миллисекундах:
  Минимум = 63 мс, максимум = 63 мс, средний = 63 мс  

  Пинг 192.168.1.222 с 32 байтами данных:
Истекло время запроса.
Истекло время запроса.
Истекло время запроса.
Истекло время запроса.Статистика пинга для 192.168.1.222:
Пакетов: отправлено = 4, принято = 0, потеряно = 4 (100% потеря),  

  Пинг 192.168.1.222 с 32 байтами данных:
Узел назначения недоступен.
Узел назначения недоступен.
Узел назначения недоступен.
Узел назначения недоступен.

Статистика пинга для 192.168.1.222:
Пакетов: отправлено = 4, принято = 0, потеряно = 4 (100% потеря),