Мы используем 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 вы получите в ответ.