Назад | Перейти на главную страницу

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

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

Я подключился по SSH к loadbalancer с помощью putty и pinged google

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

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

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

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

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

Это могло быть что угодно. Во-первых, на странице руководства по 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).

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