Фиолетовый TimeWeb (про то как бьюсь чтобы заработал VPS)
Один день, несколько часов переписки с поддержкой Timeweb Cloud по тикету 12404403, доступа к оплаченному серверу нет до сих пор. Коротко о том, что именно беспокоит.
Диагноз поставили, не посмотрев на адрес
Сервер оборвал SSH-соединение **до обмена ключами** — то есть пароль в этот момент даже не передаётся, проверить учётные данные невозможно.
Собрал полный пакет диагностики, который у меня попросили. `mtr` на 300 пакетов показал 21% потерь на самом сервере, причём до девятого узла маршрут стерильный — потери начинаются на входе в их сеть, на узле `94.228.119.220`. `ping` независимо подтвердил: 24% потерь.
Ответ:
> Часть пользователей сталкивается с недоступностью **при использовании сетей российских операторов связи**. При этом наши собственные сети и серверы работают штатно. Вероятная причина — изменения в настройках ТСПУ. > > Признаки актуальны при условии, что вы **не используете средства обхода блокировок — это нарушает правила платформы**.
Я подключаюсь из Казахстана. Адрес был указан в тикете отдельной строкой и виден в приложенном файле. Заодно меня предупредили о нарушении правил платформы — в ответ на `mtr`.
Смена IP как решение сетевой проблемы
Порекомендовали сменить адрес. Сменил. Новый не отвечает вообще — ни ping, ни один порт.
``` до 5.129.232.56 → … → 94.228.119.220 → * → 5.129.232.56 ✅ доходит до 72.56.90.144 → … → 94.228.119.220 → * → * → * ✗ обрывается ```
Маршрут общий, узел общий. Если бы дело было в фильтрации на транзите, не работали бы оба адреса.
Пароль не меняется у них, а виноват почему-то я
Жму сброс пароля в панели. Приходит письмо: **«нам не удалось этого сделать»**. Повторяю — тот же результат.
В тикете читаю:
> Прикреплённый вами ранее пароль не подходит, получить доступ к серверу для диагностики нет возможности.
Их механизм сброса не срабатывает, о чём их же система шлёт письма. Подаётся это как то, что пароль у меня какой-то не такой.
Аварийный доступ тоже не работает
> Дополнительно проверил информацию — вижу, что веб-консоль сервера также работает некорректно.
Это заметила сама поддержка. То есть сломан и штатный путь, и запасной, которым чинят сервер, когда SSH недоступен.
Мелочи, которые складываются в картину
Диалог в чате переводили между операторами четыре раза. Один раз закрыли, не решив проблему: «Закрываю ваш диалог, если появятся вопросы, пишите».
Дважды ответили «не могу проверить параметры сервера: доступ к данным аккаунта не подтянулся» — поддержка не видит сервер клиента.
И отдельно:
> Ссылку получил. Подскажите, пожалуйста, что нужно проверить или сделать с этими данными?
Меня попросили передать root-пароль от сервера — и спросили, что с ним делать.
Что беспокоит на самом деле
Не авария. Аварии бывают у всех.
Беспокоит, что клиент, приложивший `mtr` с указанием конкретного узла и проверивший всё с двух площадок в разных странах, получает в ответ шаблон про российских операторов и предупреждение о нарушении правил.
Что сетевую проблему предлагают решить сменой адреса за тем же маршрутом.
Что когда ломается штатный доступ, аварийный тоже не работает — и это обнаруживает поддержка, но проблема остаётся.
За день я сменил конфигурацию, несколько раз сбросил пароль, поменял IP, собрал диагностику с двух независимых площадок. Всё, о чём просили.
Не сделано только одно — доступ к серверу, за который я плачу.