Изменения TTL во время непрерывного пинга

Мы используем Viasat и подключаем модем непосредственно к балансировщику нагрузки на базе Linux.

Я подключился по SSH к балансировщику нагрузки с помощью putty и pinged google.

Когда я отправил ping-запрос на google, результат был следующим:

- PING 8.8.8.8 (8.8.8.8) from x.x.x.x : 64(92) bytes of data.

- 72 bytes from 8.8.8.8: icmp_seq=1 ttl=123 time=4.02 ms
- 72 bytes from 8.8.8.8: icmp_seq=2 ttl=123 time=8.40 ms
- 72 bytes from 8.8.8.8: icmp_seq=3 ttl=123 time=11.1 ms
- 72 bytes from 8.8.8.8: icmp_seq=4 ttl=123 time=16.2 ms
- 72 bytes from 8.8.8.8: icmp_seq=5 ttl=123 time=7.37 ms
- 72 bytes from 8.8.8.8: icmp_seq=6 ttl=123 time=10.0 ms
- 72 bytes from 8.8.8.8: icmp_seq=7 ttl=123 time=12.9 ms
- 72 bytes from 8.8.8.8: icmp_seq=8 ttl=123 time=7.04 ms
- 72 bytes from 8.8.8.8: icmp_seq=9 ttl=123 time=11.4 ms
- 72 bytes from 8.8.8.8: icmp_seq=10 ttl=123 time=10.5 ms
- 72 bytes from 8.8.8.8: icmp_seq=11 ttl=123 time=7.30 ms
- 72 bytes from 8.8.8.8: icmp_seq=12 ttl=123 time=4.42 ms
- 72 bytes from 8.8.8.8: icmp_seq=13 ttl=123 time=12.9 ms
- 72 bytes from 8.8.8.8: icmp_seq=14 ttl=55 time=573 ms
- 72 bytes from 8.8.8.8: icmp_seq=15 ttl=123 time=9.64 ms
- 72 bytes from 8.8.8.8: icmp_seq=16 ttl=123 time=12.0 ms
- 72 bytes from 8.8.8.8: icmp_seq=17 ttl=123 time=6.09 ms
- 72 bytes from 8.8.8.8: icmp_seq=18 ttl=123 time=9.14 ms
- 72 bytes from 8.8.8.8: icmp_seq=19 ttl=55 time=567 ms
- 72 bytes from 8.8.8.8: icmp_seq=20 ttl=55 time=556 ms
- 72 bytes from 8.8.8.8: icmp_seq=21 ttl=55 time=567 ms
- 72 bytes from 8.8.8.8: icmp_seq=22 ttl=123 time=7.83 ms
- 72 bytes from 8.8.8.8: icmp_seq=23 ttl=55 time=557 ms
- 72 bytes from 8.8.8.8: icmp_seq=24 ttl=55 time=555 ms
- 72 bytes from 8.8.8.8: icmp_seq=25 ttl=55 time=564 ms
- 72 bytes from 8.8.8.8: icmp_seq=26 ttl=55 time=565 ms
- 72 bytes from 8.8.8.8: icmp_seq=27 ttl=55 time=562 ms
- 72 bytes from 8.8.8.8: icmp_seq=28 ttl=123 time=10.0 ms
- 72 bytes from 8.8.8.8: icmp_seq=29 ttl=123 time=13.0 ms
- 72 bytes from 8.8.8.8: icmp_seq=30 ttl=123 time=12.5 ms
- 72 bytes from 8.8.8.8: icmp_seq=31 ttl=123 time=5.36 ms
- 72 bytes from 8.8.8.8: icmp_seq=32 ttl=123 time=8.44 ms
- 72 bytes from 8.8.8.8: icmp_seq=33 ttl=123 time=10.8 ms
- ^C
- --- 8.8.8.8 ping statistics ---
- 33 packets transmitted, 33 received, 0% packet loss, time 47026ms
- rtt min/avg/max/mdev = 4.020/160.648/573.236/246.800 ms

These entries:
72 bytes from 8.8.8.8: icmp_seq=19 ttl=55 time=567 ms

с такой задержкой были единственные, похожие на задержку спутников, а остальные хорошо, конечно, не сидели. задержка и TTL изменится с 123 на 55!

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

То же самое, когда мы трассируем интерфейс, следующий переход (шлюз) - это просто * * *

Любой, у кого есть опыт работы с соединениями Viasat или имеет какое-либо представление о том, что происходит, пожалуйста, помогите.

0
задан 28 January 2019 в 16:39
3 ответа

Я полагаю, что ваш ответ будет исходить из некоторой формы traceroute . Но, как обсуждалось в комментариях, у вас есть один путь, который явно не проходит через спутник. В некоторых системах эта утилита называется tracert или tracerout . tracepath предлагает аналогичные функции.

Обратите внимание, что вам может потребоваться запустить traceroute несколько раз, чтобы он действительно обнаружил неожиданный путь. Также обратите внимание, что брандмауэры могут и часто снижают эффективность traceroute. Хотя ясно, что icmp не блокируется полностью, устройства безопасности довольно часто настраиваются так, чтобы не генерировать сообщения icmp «пункт назначения недоступен», от которых traceroute зависит в режиме работы по умолчанию. То, что traceroute отвечает * * * для одного TTL, не означает, что у следующего не будет ответов. Ваш ping-тест подтвердил, что google.com хотя бы ответит.

Другой вариант - ping -R . Однако, когда я сам играл с этой опцией, похоже, что Google не поддерживает такое использование, поэтому вам нужно будет найти другую цель, которая будет. Этот параметр работает за счет включения параметра заголовка, который запрашивает у маршрутизаторов все записи о том, кто они есть в пакете, когда они передают его цели, а затем передают ответ обратно источнику.Я нечасто использовал эту опцию, но предполагаю, что устройства безопасности также могут испортить ее вывод - либо просто не упомянув об их существовании, либо отбросив запрос в пол.

1
ответ дан 4 December 2019 в 15:46

Я обнаружил, что 8.8.8.8 балансируется по умолчанию. Мне бы пришлось использовать 4.2.2.2, чтобы пинги выходили только из WAN2. Спасибо всем за ваши ответы, и я надеюсь, что мы все напряглись, пытаясь понять это. Итак, мы все выиграли, верно? хех ...

0
ответ дан 4 December 2019 в 15:46

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

При нормальной работе ping печатает значение TTL из пакета, который он получает. Когда удаленная система получает пакет ping, она может сделать один из трех вещей с полем TTL в своем ответе:

  • Не изменять его; это то, что делали системы Berkeley Unix до Выпуск 4.3BSD Tahoe. В этом случае значение TTL в полученном пакете будет 255 минус количество маршрутизаторов в пути приема-передачи.

  • Установите значение 255; это то, что делают современные системы Berkeley Unix.В этом если значение TTL в полученном пакете будет 255 минус число маршрутизаторов на пути от удаленной системы к хосту проверки связи.

  • Установите другое значение. Некоторые машины используют одно и то же значение для ICMP пакеты, которые они используют для пакетов TCP, например 30 или 60. Другие могут использовать совершенно дикие значения.

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

Итак, мое первое предложение заключается в том, что ваш трафик может быть сбалансирован нагрузкой на целевой хост, который использует TTL (например) 60 (вариант 3 выше)

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

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

Обратите внимание, что когда вы видите длинную серию "* *" * "ответы в traceroute являются признаком того, что устройство между вами и вашим пунктом назначения делает что-то неожиданное с TTL, по крайней мере, для ICMP-сообщений" пункт назначения недоступен ", используемых traceroute (которые обрабатываются немного иначе, чем пакеты" эхо-запроса "

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

0
ответ дан 4 December 2019 в 15:46

Теги

Похожие вопросы