LINUX.ORG.RU
ФорумAdmin

Нестабильный SSH-доступ к серверу: проблема только у одного провайдера

 , , , ,


0

0

Есть такая проблема - иногда не могу залогиниться по SSH на иностранный сервер - т.е. иногда он пингуется, и логинишься нормально, а иногда нет.
При этом эта проблема возникает только когда подключаешься через одного провайдера, т.е. когда коннектишься через через другого (мобильного или «домашнего» провайдера) - все ОК.

Поддержка хостера сервера (timeweb) ответила, что на их стороне проблем нет, но ничего не пояснила и послала к провайдеру.

Вот трейсы до сервера:

Это неудачный трейс со «сбойного» провайдера:

$ mtr -nr -c100 -TP22 __SERVER_IP__

  1.|-- 192.168.144.254            0.0%   300    0.4   0.4   0.3   1.5   0.1
  2.|-- 192.168.200.254            0.0%   300    0.5   0.5   0.4   1.3   0.1
  3.|-- 109.196.174.128            0.0%   300    0.8   0.8   0.6   7.5   0.4
  4.|-- 94.228.119.245             1.0%   300   23.9  23.9  23.5  34.2   0.6
  5.|-- 94.228.119.207             3.7%   300   56.8  56.8  56.4  59.2   0.3
  6.|-- ???                       100.0   300    0.0   0.0   0.0   0.0   0.0
  7.|-- ???                       100.0   300    0.0   0.0   0.0   0.0   0.0
  8.|-- 172.17.0.1                99.7%   300  6961. 6961. 6961. 6961.   0.0

Это успешный трейс через ВПН через «сбойного» провайдера:

$ mtr -nr -c100 -TP22 __SERVER_IP__
  1.|-- 185.132.127.20             0.0%   100   35.1  35.3  34.8  37.5   0.4
  2.|-- 185.132.127.2              0.0%   100   36.7  47.0  35.8 1053. 101.7
  3.|-- 184.104.204.229            3.0%   100   37.1 424.9  36.4 3078. 750.1
  4.|-- 184.105.80.177             0.0%   100   39.6  69.5  37.1 1067. 174.6
  5.|-- 94.228.119.245             0.0%   100   48.8  52.1  48.0  59.3   4.6
        178.18.230.238                   
        178.18.230.237                   
  6.|-- 94.228.119.245             0.0%   100   70.7 119.5  65.3 3103. 333.3
        94.228.119.207                   
  7.|-- 94.228.119.207            71.0%   100   92.5 374.9  87.7 7275. 1340.7
  8.|-- ???                       100.0   100    0.0   0.0   0.0   0.0   0.0
  9.|-- ???                       100.0   100    0.0   0.0   0.0   0.0   0.0
 10.|-- __SERVER_IP__            29.0%   100   66.4  67.8  65.7  76.5   2.0

Это успешный трейс через домашнего провайдера:

1?: [LOCALHOST]                      pmtu 1500
 1:  192.168.33.252                                        0.312ms 
 1:  192.168.33.252                                        0.166ms 
 2:  no reply
 3:  1.1.1.10                                              0.668ms pmtu 1492
 3:  212.48.195.69                                         3.817ms 
 4:  217.107.118.204                                       5.314ms 
 5:  no reply
 6:  80.239.128.74                                        39.352ms asymm  5 
 7:  62.115.140.214                                       38.709ms asymm  6 
 8:  62.115.143.29                                        58.485ms 
 9:  62.115.132.231                                       64.661ms asymm  7 
10:  62.115.173.27                                        67.269ms asymm  8 
11:  94.228.119.220                                       73.742ms asymm  9 
12:  no reply
13:  no reply
14:  no reply
15:  __SERVER_IP__                                       73.851ms reached

Вроде бы как проблема начинается после 94.228.119.207.

Если смотреть: https://www.ip2location.com/94.228.119.207 показывает AS9123 JSC Timeweb <- это как раз хостер

Можете подсказать, в чем тут может быть проблема?

Поможет ли смена белого адреса сервера на другой?


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

Pinkbyte ★★★★★
()

У меня тоже проблемы с timeweb были. Ответили, что у них всё норм и что вероятно виноват «регулятор». Дальнейшие расспросы ни к чему не привели.

LinuxUser ★★★
()

Тебе заголовок темы бредогенератор сочинял или ты их настолько начитался что сам стал подражать? 🤦 А может и текст сообщения оно редактировало?

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

AS9123 JSC Timeweb <- это как раз хостер

Хостер российский, сервер иностранный, верно?

Это успешный трейс через домашнего провайдера:

3: 1.1.1.10

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

Это неудачный трейс со «сбойного» провайдера:

Ты мог бы попросить timeweb посмотреть сниффером твои пакеты на 94.228.119.207 во время трассировки. Но вероятно они не захотят это делать.

И вообще лучше делать traceroute -I -n а не mtr, у него более удобный вывод.

firkax ★★★★★
()
Ответ на: комментарий от firkax

Тебе заголовок темы бредогенератор сочинял или ты их настолько начитался что сам стал подражать? 🤦 А может и текст сообщения оно редактировало?

Загололовок - да. А мессагу сам писал… вообще хорошо иногда - опечатки фиксит, запятые расставляет.

Хостер российский, сервер иностранный, верно?

Да

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

Нет. У меня 2 роутера 192.168.33.252 и за ним 1.1.1.10 <- ростелекомовский роутер, куда он дальше гонит ХЗ

crider
() автор топика

Ок - были подозрения на блокировку, хотел подтвердить т.к. странно, что 1 и 2 трейсы идут через один 94.228.119.207 - в одном случае трейс не доходит, а в другом - нет.

Получается, что он на основании адреса источника блочит.

crider
() автор топика
Ответ на: комментарий от crider

1.1.1.10 это локальный адрес? Он же не для локалок, вполне реальный в интернете такой есть, используется клаудфларом.

Ну да ладно.

firkax ★★★★★
()
Ответ на: комментарий от crider

Получается, что он на основании адреса источника блочит.

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

firkax ★★★★★
()

Самый простой вариант: проверить работу tcp через «сбойного» провайдера с помощью iperf3. Если не-ssh tcp будет работать нормально, то РКН подтверждён. Если будет большое количество ретрансмитов и скукоживание окна, то РКН не исключён, но проверить ptmu и прохождение icmp стоит в первую очередь.

Следом сниффер на клиенте и на сервере: tcpdump -s 65535 -w ssh-$(hostname).pcap и потом сравнивать в Wireshark что дошло, что потерялось, что скукожилось.

3: 1.1.1.10 0.668ms pmtu 1492

Я много лет назад у оператора, ставшего потом частью РТ, на vrf с интернетом делал точка-точка в 1.1.1.0/30. В мыслях не было, что он когда-то будет маршрутизироваться. Хорошо у дураков мысли сходятся!

anonymous
()

Попробуй выставить порт какой-нить нестандартный. Некоторым говорят помогает.

vtVitus ★★★★★
()

Поддержка хостера сервера (timeweb) ответила, что на их стороне проблем нет, но ничего не пояснила и послала к провайдеру.

Судя по whois 94.228.119.207 принадлежит timeweb, а с учетом того, что в первом случае заруливается на 172.17.0.1, а во втором нет, имхо мяч на их стороне. Я бы с такими выкладками имел бы мозг им.

anc ★★★★★
()

Была проблема с VPS от Таймвеба же, спорадически отваливался доступ через проводной МТС.

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

Достучался до МТС, они попроверяли и развели руками - они сами ничего не ломали, а на РКН управы нет.

На другом провайдере доступ без проблем.

На том VPS пара рабочих сайтов, никаких VPN на нем отродясь не было.

И он вообще В ПИТЕРЕ, блин.

Adamos ★★★
()

Были в конторе такие проблемы. Установил на конечном пункте Traceroute . Сделал трассировку по портам. Выхлоп (где затык на каком IP) Послал провайдеру отчет трейса. В ответ никакой вони все починили.

anonymous
()
  • Markdown
Пустая строка (два раза Enter) начинает новый абзац. Знак '>' в начале абзаца выделяет абзац курсивом цитирования.
Внимание: прочитайте описание разметки Markdown.
Используйте Ctrl-Enter для размещения комментария