Облачная платформаEvolution

Диагностика влияния ТСПУ на сетевые подключения

Эта статья полезна?

Некоторые проблемы с сетевыми подключениями могут быть вызваны работой ТСПУ — технических средств противодействия угрозам. Эти специализированные DPI-комплексы устанавливаются операторами связи в соответствии с требованиями Роскомнадзора для анализа и фильтрации сетевого трафика.

В отдельных случаях это может влиять на доступность сервисов, скорость передачи данных или работу отдельных сетевых протоколов. Если вы предполагаете, что причиной проблем является влияние ТСПУ, выполните диагностику и передайте ее результаты в службу поддержки.

При анализе трафика ТСПУ могут использовать различные параметры, например:

IP-адрес;
SNI (Server Name Indication);
метаданные протокола QUIC;
сигнатуры сетевых протоколов;
другие характеристики сетевого трафика.

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

На возможное влияние ТСПУ могут указывать следующие признаки:

не удается установить соединение по протоколам SSH, HTTP, HTTPS, VPN, а в некоторых случаях — RDP;
при этом ICMP-запросы (ping), а также проверки с помощью mtr и telnet выполняются успешно;
скорость передачи данных по отдельным протоколам значительно ниже ожидаемой;
проблема возникает постоянно или проявляется периодически.

Рассмотрим пример того, как влияние ТСПУ может проявиться:

Проверка установки TCP соединения до целевого порта с помощью команды:
```
$ nc -zv ‹DOMAIN› 443
Connection to ‹DOMAIN› 443 port [tcp/https] succeeded!
```
Полученный ответ означает, что TCP установлен.

Проверка прикладного уровня TLS/HTTPS:

$ curl -v https://‹DOMAIN›
* Host ‹DOMAIN›:443 was resolved.
* IPv6: (none)
* IPv4: ‹IP-АДРЕС›
* Trying ‹IP-АДРЕС›:443...
* Connected to ‹DOMAIN› (‹IP-АДРЕС›) port 443
* ALPN: curl offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
* CAfile: /etc/ssl/cert.pem
* CApath: none

Дальнейшие строки отсутствуют, команда «зависает».

Подобные ситуации чаще наблюдаются при использовании выделенного сервера с публичным общим IP-адресом. Реже они могут возникать при использовании адресов из выделенной публичной подсети.

Выполните диагностику

Для получения наиболее полной информации рекомендуется провести диагностику между двумя серверами, между которыми наблюдается проблема подключения. Один из серверов должен находиться в инфраструктуре Cloud.ru.

Используйте следующие обозначения:

целевой сервер (Destination) — сервер, к которому необходимо установить соединение;
исходный сервер (Source) — сервер, с которого выполняется попытка подключения.

Чтобы получить максимально полную картину, необходимо выполнить диагностику в следующей последовательности:

Собрать диагностические данные при передаче трафика от исходного сервера к целевому. Это позволит оценить работу сетевого соединения в прямом направлении.
Повторить диагностику для обратного направления — от целевого сервера к исходному. Проверка обоих направлений помогает выявить асимметричные проблемы маршрутизации или фильтрации трафика.
Передать полученные диагностические данные в службу поддержки. На основании результатов специалисты смогут определить наличие признаков влияния ТСПУ и предложить дальнейшие действия.
Если по результатам диагностики предполагается влияние ТСПУ, вы можете выполнить действия по результатам диагностики.

1. Выполнение диагностики от исходного сервера до целевого

В зависимости от протокола, с которым наблюдаются проблемы, выберите сценарий диагностики:

Подключитесь к исходному серверу. Если узел размещен в облачной среде, следуйте руководству по подключению к Linux Elastic Cloud Server.
Создайте текстовый файл, в который будете сохранять результаты диагностики.
Проверьте доступность целевого сервера:
1. Выполните команду. Эта проверка покажет, проходят ли ICMP-пакеты:
```
ping <destination_ip_address>
```
  Где <destination_ip_address> — IP-адрес целевого сервера.
2. Сохраните вывод в файл с результатами диагностики, cозданный на шаге 2.
Проверьте доступность сервиса на целевом сервере:
1. Выполните команду:
```
curl -v --ipv4 --tlsv1.2 -I <https://example.com>
```
  Где <https://example.com> — доменное имя сервиса.
2. Сохраните вывод в файл с результатами диагностики, cозданный на шаге 2.
Проверьте HTTPS-соединение по порту 443:
1. Установите утилиту telnet в соответствии с инструкцией Telnet Applications.
2. Проверьте соединение по порту 443:
```
telnet <destination_ip_address> 443
```
  Где <destination_ip_address> — IP-адрес целевого сервера.
3. Сохраните выводы в файл с результатами диагностики, cозданный на шаге 2.
Выполните трассировку маршрута до целевого сервера:
1. Выполните команду:
```
traceroute <destination_ip_address / домен>
```
  Где <destination_ip_address> — IP-адрес целевого сервера.
2. Выполните трассировку маршрута до целевого сервера по ключевому порту:
```
traceroute -T -p 443 <destination_ip_address / домен>
```
  Где <destination_ip_address> — IP-адрес целевого сервера.
3. Сохраните вывод в файл с результатами диагностики, cозданный на шаге 2.
Соберите дамп трафика:
1. Установите утилиту tcpdump согласно инструкции tcpdump.
2. Соберите дамп трафика с помощью команды:
```
tcpdump -s 1500 -c 5000 -w dump_<source_ip>_<destination_ip>.pcap host <destination_ip> and port <port>
```
  Где:
  - <destination_ip_address> — IP-адрес целевого сервера;
  - <source_ip_address> — IP-адрес исходного сервера.
  В результате будет создан отдельный файл с данными в формате .pcap:
3. Задайте имя для файла с дампом в формате:
```
dump_<source_ip_address>_<destination_ip_address>
```
  Где:
  - <destination_ip_address> — IP-адрес целевого сервера;
  - <source_ip_address> — IP-адрес исходного сервера.

2. Выполнение диагностики от целевого сервера до исходного

Подключитесь к исходному серверу. Если узел размещен в облачной среде, следуйте руководству по подключению к Linux Elastic Cloud Server.
Выполните трассировку маршрута до исходного сервера:
Выполните трассировку маршрута до исходного сервера:
traceroute   <destination_ip_address / домен>
Выполните трассировку маршрута до исходного сервера по ключевому порту:
traceroute -T -p 443 <destination_ip_address / домен>
Сохраните вывод в файл с результатами диагностики, cозданный на шаге 2.
Соберите дамп трафика до исходного сервера:
Установите утилиту tcpdump согласно инструкции tcpdump.
Соберите дамп трафика с помощью команды:
tcpdump -s 1500 -c 5000 -w dump_<source_ip>_<destination_ip>.pcap host <destination_ip> and port <port>
Где:

<destination_ip_address> — IP-адрес целевого сервера;

<source_ip_address> — IP-адрес исходного сервера.

В результате будет создан отдельный файл с данными в формате .pcap.
Задайте имя для файла с дампом в формате:
dump_<source_ip_address>_<destination_ip_address>
Где:

<destination_ip_address> — IP-адрес целевого сервера;

<source_ip_address> — IP-адрес исходного сервера.
Подключитесь к исходному серверу. Если узел размещен в облачной среде, следуйте руководству по подключение к Windows Elastic Cloud Server.

Запустите PowerShell от имени администратора.
Выполните трассировку маршрута до целевого сервера:
Выполните трассировку маршрута до целевого сервера:

Установите утилиту mtr согласно инструкции GitHub mtr.
Выполните трассировку:
mtr --address <destination_ip_address> -bwzrc 100 <source_ip_address>
Где:

<destination_ip_address> — IP-адрес целевого сервера;

<source_ip_address> — IP-адрес исходного сервера.
Сохраните вывод в файл с результатами диагностики, cозданный на шаге 2.
Соберите дамп сетевого трафика до исходного сервера. Задайте имя для файла с дампом в формате: dump_<destination_ip_address>_<source_ip_address>

Где:

<destination_ip_address> — IP-адрес целевого сервера;

<source_ip_address> — IP-адрес исходного сервера.

3. Отправка диагностических данных

Создайте обращение, в котором укажите следующие данные:
1. Максимально подробно опишите проблему, с которой вы столкнулись;
2. Укажите пару IP-адресов, между которыми наблюдаются проблемы подключения и для которых вы выполняли диагностику;
3. Если проблема наблюдается с подключением по HTTP/HTTPS — укажите, находится ли на указанных IP-адресах VPN-сервер;
4. Приложите файлы с результатами диагностики.
Дождитесь ответа сотрудника Cloud.ru. Мы проведем дополнительную диагностику со своей стороны и сообщим о результатах.
(Опционально) Если по результатам диагностики мы подтвердим подозрение на влияние ТСПУ, можно дополнительно запросить подтверждение у операторов связи о наличии ТСПУ на маршруте прохождения трафика. Cloud.ru может отправить текстовый запрос только тем операторам связи (аплинкам), которые приходят непосредственно в наши дата-центры. Вы можете самостоятельно обратиться к операторам со стороны сервера, который находится вне инфраструктуры Cloud.ru.
1. На исходном сервере запустите трафик в сторону целевого сервера. Не останавливайте трафик минимум 7 дней, это необходимо для диагностики со стороны оператора:
```
ping <destination_ip_address>
while true; do <protocol> -o ConnectTimeout=5 user@<destination_ip_address> exit; sleep 60; done:
   <destination_ip_address>
   <protocol>
```
  Где:
  - <destination_ip_address> — IP-адрес целевого сервера;
  - <protocol> — протокол, с которым наблюдаются проблемы: ssh для протокола SSH, curl для протоколов HTTP/HTTPS.
2. В обращении сообщите, что запустили трафик. Мы отправим письменный запрос оператору связи, который подключен непосредственно к инфраструктуре Cloud.ru и через канал которого проходит запущенный трафик.
3. Для оперативного решения вопроса самостоятельно обратитесь к оператору связи, к которому подключен сервер вне инфраструктуры Cloud.ru.

4. Выполнение действий по результатам диагностики

Cloud.ru не может влиять на работу ТСПУ и на настройки сетей операторов связи. Если по результатам диагностики подтверждено влияние ТСПУ, со своей стороны вы можете выполнить следующие действия:

Если вы юридическое лицо или ИП, вы можете обосновать исключение фильтрации ТСПУ для вашей подсети. Для этого подайте запрос в Роскомнадзор через личный кабинет владельца технологической сети.

Пример:

Кому: Оператору связи / РКН (ЦМУ ССОП)

От: ФИО, тел., e-mail, IP (если есть)

Домен / IP: _______________ / _______________

Дата начала проблемы: 05.05.2026

Суть: TCP-доступ к серверу есть, ответ сервера не доходит до клиента (обрыв на TLS / маршруте).

Прилагаю скриншоты, дамп трафика.

Что сделано:

   - Хостинг-провайдер подал заявку №19258 в ЦМУ ССОП на исключение из фильтрации (подтверждено, адрес внесен в исключения).

   - Запросы операторам МТС, Билайн — ответа нет.

Прошу: разобраться, установить причину, восстановить доступ.

Пользователь может ускорить принятие решения, направив это же письмо своему оператору и в РКН.

Вы также можете изменить IP-адрес на сервере в Cloud.ru: запросите другой публичный общий IP-адрес. Для этого создайте обращение.

Предыдущая статья

Сброс пароля на Linux с помощью LiveCD

Следующая статья

Обратиться в поддержку

Эта статья полезна?

Поддержка Юридические документы Политика конфиденциальности