Jump to content

Задача про RTT и расположение серверов


Recommended Posts

Posted

Всем привет.

Есть две организации, назовём их А и Б. У каждой взял по виртуальному серверу.

Провайдер А утверждает, что их инфраструктура в Москве. Провайдер Б - в Стокгольме.
При этом:

RTT A->Б: 0.8-1.0 мс,
RTT Б->A: 16-17 мс.

Проверяю простым пингом, MTR показывает примерно одинаковый маршрут.

 

Понятно, что за 1 мс пакет не успеет слетать из Москвы в Стокгольм. Непонятно, как объяснить такой результат. Может, провайдер Б обманывает, и его сервер тоже находится в Москве? Но как это доказать? Или же провайдер А как-то вмешивается в трафик, меняет там метки времени и это приводит к таким нереалистичным задержкам? Хочется разобраться.

 

Буду рад подсказкам, куда ещё можно копнуть, что проверить.

Posted

mtr А->Б:

 Host                                Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 82.146.32.1                       0.0%    12    0.2   0.2   0.2   0.4   0.1
 2. 172.25.11.10                      0.0%    12    0.3   0.4   0.3   0.5   0.1
 3. 192.168.3.58                      0.0%    12    0.5   0.8   0.3   3.4   1.0
 4. (waiting for reply)
 5. 172.17.22.108                     0.0%    12    0.5   0.5   0.4   0.6   0.1
 6. 100.105.107.25                   33.3%    12    1.1   1.0   0.9   1.2   0.1
 7. 178.178.110.201                   0.0%    11    1.3   2.5   1.1  11.7   3.2
 8. Б.Б.Б.Б                           0.0%    11    0.9   0.9   0.8   0.9   0.0

 

mtr Б->А:

 1. 10.0.0.1                          0.0%     8    0.2   0.2   0.1   0.2   0.0
 2. 194.26.229.33                     0.0%     8   15.3  16.1  15.3  19.7   1.5
 3. 178.176.150.40                    0.0%     8   15.8  16.1  15.7  16.6   0.3
 4. 178.178.110.29                    0.0%     8   15.7  16.8  15.7  18.4   1.0
 5. 100.105.107.26                    0.0%     8   22.9  17.8  16.1  22.9   2.4
 6. 172.17.22.109                     0.0%     8   16.9  20.6  16.6  44.2   9.6
 7. (waiting for reply)
 8. (waiting for reply)
 9. (waiting for reply)
10. А.А.А.А                           0.0%     7   16.2  16.5  16.1  17.7   0.5

 

Posted

Можно ли этот результат трассировки с LG московского маршрутизатора Мегафона рассматривать как железобетонное доказательство того, что Б точно не в Стокгольме?

image.thumb.png.f75a0934b06f94dbaa594179e644260a.png

Posted
2 часа назад, motorhunter сказал:

RTT A->Б: 0.8-1.0 мс,
RTT Б->A: 16-17 мс.

Проверяю простым пингом, MTR показывает примерно одинаковый маршрут.

Это странно. ping сам по себе генерирует симметричный трафик. Отличие только в ICMP type (8/0) Если Вы пингуете Б с А и получаете RTT в 1 мс, то и пингуя А с Б вы должны тоже получить 1 мс.

Для VPS-ок заказаны внешние IPv4-адреса? Можете убедиться, что исходящие соединения в мир идут с назначенным IP-адресом, а не с каким-то левым?

Posted
Цитата

Для VPS-ок заказаны внешние IPv4-адреса?

Да.

 

Цитата

Можете убедиться, что исходящие соединения в мир идут с назначенным IP-адресом, а не с каким-то левым?

Попробовал сделать так:

 

1. На сервере А запустил tcpdump -i ens3 icmp

С сервера Б запустил ping A

На А вижу входящие ICMP-пакеты с адреса Б и ответы на них, всё хорошо.

 

2. Обратный тест: на сервере Б запускаю tcpdump -i ens3 icmp

С сервера А запускаю ping Б

На Б при этом не вижу ни одного ICMP-пакета, но серверу А кто-то отвечает с RTT 0.8-1 мс!

Posted

@motorhunter О боже, Вам сколько лет? Возьмите nic.ru и посмотрите на ком все адреса из ваших маршрутов - ни одного иностранного, что вам там втирают  про Стокгольм - я не знаю, может Вы из Питера, и у вашего продавца услуг какой-то туннель туда проброшен? Но чудес в 2 мс не бывает. Впрочем и 16 тоже не очень понятно.

Сам трасерт УЖЕ заставляет подумать, что вы и где купили - туннель на туннеле и серые адреса?

 

https://www.nic.ru/whois/?searchWord=194.26.229.33

https://aeza.net/ru/data-center

 

Стокгольм!!!! Бля-ха муха! ТОЧНО СТОКГОЛЬМ! Вы там не у цыган золотишко то брали?

Posted
22 минуты назад, motorhunter сказал:

На Б при этом не вижу ни одного ICMP-пакета, но серверу А кто-то отвечает с RTT 0.8-1 мс!

На эту тему поинтересуйтесь у своего хостера. Конкретики более чем достаточно.

 

Значит по факту вы не можете инициировать IP-трафик с А на Б? Правильно я понимаю? Или такое веселье только с ICMP?

Posted
Цитата

Стокгольм!!!! Бля-ха муха! ТОЧНО СТОКГОЛЬМ! Вы там не у цыган золотишко то брали?

Да, сервер Б в "aeza.net", но если бы Вы посмотрели в раздел "Услуги", то они продают VPS не только в Москве.

При этом IP самого сервера везде, где я проверял, определяется как стокгольмский и блокировки РКН на нём не работают (в своё время использовал его как VPN).

Вопрос в другом - как можно убедительно доказать, что он не в Стокгольме, если это действительно не так?

 

Почему вообще я этим вопросом задаюсь - на сервере А установлен Cacti, который среди прочего пингует сервер Б. И с недавнего времени график RTT А->Б выглядит так:

image.thumb.png.1f096fd200d9941388d46e186091e89e.png

 

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

 

Цитата

Или такое веселье только с ICMP?

Похоже, что только с ICMP, ибо SSH, например, прекрасно работает в обе стороны.

Posted
8 минут назад, motorhunter сказал:

Похоже, что только с ICMP, ибо SSH, например, прекрасно работает в обе стороны.

Как дела с задержками, если запустить на VPS-ках:

hping3 -S -p номер_ssh_порта IP-адрес

?

Posted

Ну так может, если это "виртуальный" сервер, то у него на пинг отвечает локально исполняемый поток, а запросы к ресурсам пользователей уходят в ДЦ Стокгольма. Вам для теста по времени ответа  нужен другой вариант проверок - например поднимите между серверами туннель и пропингуйтесь в нём. Или попробуйте что-то типа tcpping или как предложили hping3.

 

И кстати ради интереса попробуйте пингануть ресурс откуда-то из США или Европы. Интересно какой трасерт будет.

Posted

Белые IP непосредственно на интерфейсах, да.

 

Несколько трассировок сервера Б с разных мест (использовал LG разных операторов, т.к. больше особо не с чего). Но мне они ничего конкретного о местоположении сервера, к сожалению, не говорят.

 

Screenshot 2024-10-05 232325.png

Screenshot 2024-10-05 232439.png

Screenshot 2024-10-05 232515.png

Posted
Цитата

Ну так может, если это "виртуальный" сервер, то у него на пинг отвечает локально исполняемый поток, а запросы к ресурсам пользователей уходят в ДЦ Стокгольма.

Пока что это выглядит наиболее вероятным ответом, если отбросить мысль, что сам сервер всё-таки в Мск. Спасибо. Я даже не знал о таких особенностях виртуальных серверов.

Posted
4 часа назад, motorhunter сказал:
1. 82.146.32.1                       0.0%    12    0.2   0.2   0.2   0.4   0.1
 2. 172.25.11.10                      0.0%    12    0.3   0.4   0.3   0.5   0.1
 3. 192.168.3.58                      0.0%    12    0.5   0.8   0.3   3.4   1.0
 4. (waiting for reply)
 5. 172.17.22.108                     0.0%    12    0.5   0.5   0.4   0.6   0.1
 6. 100.105.107.25                   33.3%    12    1.1   1.0   0.9   1.2   0.1
 7. 178.178.110.201                   0.0%    11    1.3   2.5   1.1  11.7   3.2
 8. Б.Б.Б.Б                           0.0%    11    0.9   0.9   0.8   0.9   0.0

Это ненормальный трафик. Куча серых адресов, потом 100.105.107.25 - это диапазон CGNAT, то есть ваш трафик натится во что-то, потом адрес мегафона  178.178.110.201  - это их ЦОД в Нижнем Новгороде. Скорее всего, провайдер А действительно мутит, и ICMP трафик заворачивает в какую-то ловушку вроде IDS. Либо это делает ТСПУ на сети оператора, и ваш трафик попадает на анализ в ЦМУ ССОП. Раз трафик вроде SSH до места долетает, значит фильтр конкретно на ICMP. Очень вероятно, что ЦОД в Швеции хостит всякие свободные VPN или точки выхода TOR, являющиеся объектом пристального внимания. Думато, что IPSEC туда из РФ не поднимется.

Posted
Я даже не знал о таких особенностях виртуальных серверов. 

Это не особенность, это бред полнейший от кого-то, кто про них только читал что-то, и то давно.

Posted
6 часов назад, motorhunter сказал:

На Б при этом не вижу ни одного ICMP-пакета, но серверу А кто-то отвечает с RTT 0.8-1 мс!

полагаю, это "надежная собственная DDoS-защита"

Posted

Обнаружил, что сервер Б "отвечает" на пинг, даже будучи выключенным (через shutdown now или из консоли оператора). Задал соответствующий вопрос в поддержку, получил ответ, что на ICMP отвечает сетевое оборудование, а не сам сервер. На вопрос, почему RTT из Москвы составляет 1 мс, отвечать отказались, ссылаясь на NDA.

  • 3 weeks later...
Posted
В 05.10.2024 в 23:48, jffulcrum сказал:

Это ненормальный трафик. Куча серых адресов, потом 100.105.107.25 - это диапазон CGNAT, то есть ваш трафик натится во что-то, потом адрес мегафона  178.178.110.201  - это их ЦОД в Нижнем Новгороде. Скорее всего, провайдер А действительно мутит, и ICMP трафик заворачивает в какую-то ловушку вроде IDS. Либо это делает ТСПУ на сети оператора, и ваш трафик попадает на анализ в ЦМУ ССОП. Раз трафик вроде SSH до места долетает, значит фильтр конкретно на ICMP. Очень вероятно, что ЦОД в Швеции хостит всякие свободные VPN или точки выхода TOR, являющиеся объектом пристального внимания. Думато, что IPSEC туда из РФ не поднимется.

100.64.0.0/10 - используется операторами для P2P стыков, это не NAT...
Posted
3 часа назад, Savchenko сказал:
100.64.0.0/10 - используется операторами для P2P стыков, это не NAT...

Вы не правы, почитайте что такое CGNAT, https://en.wikipedia.org/wiki/Reserved_IP_addresses   https://en.wikipedia.org/wiki/Carrier-grade_NAT

З.Ы.

Кстати на форуме выложено высокопроизводительное решение для реализации CGNAT под линухом (Adavnced NAT - ANAT).

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...
На сайте используются файлы cookie и сервисы аналитики для корректной работы форума и улучшения качества обслуживания. Продолжая использовать сайт, вы соглашаетесь с использованием файлов cookie и с Политикой конфиденциальности.