Перейти к основному содержимому

Диагностика влияния ТСПУ

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

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

Что такое ТСПУ

ТСПУ, или технические средства противодействия угрозам — DPI-комплексы, которые устанавливаются по требованию локального регулятора на узлах связи для фильтрации проходящего трафика. ТСПУ могут блокировать или замедлять трафик на основании различных критериев: IP-адресов, SNI (Server Name Indication), QUIC-метаданных, подписи протоколов и других.

Устанавливать ТСПУ в своих сетях обязаны крупные операторы мобильной, широкополосной и спутниковой связи, а также владельцы точек обмена трафиком. Через ТСПУ должен проходить весь пользовательский трафик. Оборудованием ТСПУ управляет Центр мониторинга и управления сетью связи общего пользования, операторы связи не имеют доступа к нему.

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

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

Признаки влияния ТСПУ

ТСПУ может вызывать проблемы с подключением по протоколам SSH, HTTP/HTTPS, VPN, иногда RDP. При этом сервер отвечает на ICMP-запросы и проверки через утилиты mtr, telnet выполняются успешно. В редких случаях может наблюдаться проблема со скоростью сети при подключении по указанным протоколам. Проблема с подключением и скоростью может иметь как постоянный, так и плавающий характер.

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

Провести диагностику влияния ТСПУ

Чтобы получить полные диагностические данные, нужно провести диагностику для двух серверов, между которыми наблюдается проблема при подключении. Один из серверов должен находиться в инфраструктуре Servercore:

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

Диагностику нужно провести в двух направлениях — от исходного сервера до целевого и от целевого сервера до исходного. Если вы не можете подключиться к одному из серверов, проведите диагностику только со второго.

  1. Проведите диагностику от исходного сервера до целевого.
  2. Проведите диагностику от целевого сервера до исходного.
  3. Отправьте нам результаты диагностики.
  4. Если по результатам диагностики предполагается влияние ТСПУ, вы можете выполнить действия по результатам диагностики.

1. Провести диагностику от исходного сервера до целевого

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

  1. Подключитесь к исходному серверу. Если сервер находится в инфраструктуре Servercore, используйте инструкцию Подключиться к серверу.

  2. Создайте текстовый файл, в который будете сохранять результаты диагностики.

  3. Проверьте доступность целевого сервера:

    3.1. Проверьте доступность целевого сервера. Проверка покажет, проходят ли ICMP-пакеты:

    ping <destination_ip_address>

    Укажите <destination_ip_address> — IP-адрес целевого сервера.

    3.2. Сохраните вывод в файл с результатами диагностики, который вы создали на шаге 2.

  4. Проверьте подключение по SSH:

    4.1. Подключитесь к целевому серверу по SSH с подробным выводом информации о подключении:

    ssh -v root@<destination_ip_address>

    Укажите <destination_ip_address> — IP-адрес целевого сервера.

    4.2. Сохраните вывод в файл с результатами диагностики, который вы создали на шаге 2.

  5. Просканируйте порты целевого сервера:

    5.1. Установите утилиту nmap, подробнее в статье Linux Distributions документации nmap.

    5.2. Выполните сканирование портов без предварительной проверки доступности сервера:

    nmap -Pn <destination_ip_address>

    Укажите <destination_ip_address> — IP-адрес целевого сервера.

    5.3. Сохраните вывод в файл с результатами диагностики, который вы создали на шаге 2.

  6. Проверьте TCP-соединение по порту 22:

    6.1. Установите утилиту telnet, подробнее в статье Telnet Applications документации telnet.

    6.2. Подключитесь к целевому серверу по TCP:

    telnet <destination_ip_address> 22

    Укажите <destination_ip_address> — IP-адрес целевого сервера.

    6.3. Сохраните вывод в файл с результатами диагностики, который вы создали на шаге 2.

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

    7.1. Установите утилиту mtr. Подробнее на GitHub mtr.

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

    mtr --address <destination_ip_address> -bwzrc 100 <source_ip_address>

    Укажите:

    • <destination_ip_address> — IP-адрес целевого сервера;
    • <source_ip_address> — IP-адрес исходного сервера.

    7.3. Сохраните вывод в файл с результатами диагностики, который вы создали на шаге 2.

  8. Соберите дамп трафика до целевого сервера:

    8.1. Установите утилиту tcpdump, подробнее в документации tcpdump.

    8.2. Соберите дамп трафика. Команда создаст файл в формате .pcap:

    tcpdump --count 1000 -w dump_<source_ip_address>_<destination_ip_address>.pcap host <destination_ip_address>

    Укажите:

    • <source_ip_address> — IP-адрес исходного сервера;
    • <destination_ip_address> — IP-адрес целевого сервера.

2. Провести диагностику от целевого сервера до исходного

  1. Подключитесь к целевому серверу. Если сервер находится в инфраструктуре Servercore, используйте инструкцию Подключиться к серверу.

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

    2.1. Установите утилиту mtr, подробнее на GitHub mtr.

    2.2. Выполните трассировку:

    mtr --address <source_ip_address> -bwzrc 100 <destination_ip_address>

    Укажите:

    • <source_ip_address> — IP-адрес исходного сервера;
    • <destination_ip_address> — IP-адрес целевого сервера.

    2.3. Сохраните вывод в файл с результатами диагностики, который вы создали на этапе 1.

  3. Соберите дамп трафика до исходного сервера:

    3.1. Установите утилиту tcpdump, подробнее в документации tcpdump.

    3.2. Соберите дамп трафика. Команда создаст отдельный файл с данными в формате .pcap:

    tcpdump --count 1000 -w dump_<destination_ip_address>_<source_ip_address>.pcap host <source_ip_address>

    Укажите:

    • <destination_ip_address> — IP-адрес целевого сервера;
    • <source_ip_address> — IP-адрес исходного сервера.

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

  1. Создайте тикет, в тикете укажите следующие данные:

    • максимально подробно опишите проблему, с которой вы столкнулись;

    • укажите пару IP-адресов, между которыми наблюдаются проблемы подключения и для которых вы выполняли диагностику;

    • если проблема наблюдается с подключением по HTTP/HTTPS — укажите, находится ли на указанных IP-адресах VPN-сервер;

    • приложите файлы с результатами диагностики.

  2. Дождитесь ответа сотрудника Servercore. Мы проведем дополнительную диагностику со своей стороны и сообщим о результатах.

  3. Опционально: если по результатам диагностики мы подтвердим подозрение на влияние ТСПУ, можно дополнительно запросить подтверждение у операторов связи о наличии ТСПУ на маршруте прохождения трафика. Servercore может отправить текстовый запрос только тем операторам связи (аплинкам), которые приходят непосредственно в наши дата-центры. Вы можете самостоятельно обратиться к операторам со стороны сервера, который находится вне инфраструктуры Servercore.

    3.1. На исходном сервере запустите трафик в сторону целевого сервера. Не останавливайте трафик минимум 7 дней, это необходимо для диагностики со стороны оператора:

    ping <destination_ip_address>
    while true; do <protocol> -o ConnectTimeout=5 user@<destination_ip_address> exit; sleep 60; done

    Укажите:

    • <destination_ip_address> — IP-адрес целевого сервера;
    • <protocol> — протокол, с которым наблюдаются проблемы: ssh для протокола SSH, curl для протоколов HTTP/HTTPS.

    3.2. В тикете сообщите, что запустили трафик. Мы отправим письменный запрос оператору связи, который подключен непосредственно к инфраструктуре Servercore и через канал которого проходит запущенный трафик.

    3.3. Опционально: самостоятельно обратитесь к оператору связи, к которому подключен сервер вне инфраструктуры Servercore.

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

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