Недавно часть наших клиентов не могла подключиться к серверам Монеты. Мы проверили межсетевые экраны, собрали трассировки с обеих сторон, но причина оказалась за пределами нашей инфраструктуры. При этом сайты самих клиентов тоже стали недоступны, а уведомления о платежах на Pay URL перестали доходить. Диагностика привела нас к участку сети, где работает ТСПУ.
На связи Евгений, инженер отдела сопровождения разработки и эксплуатации ПО (DevOps-инженер) в Монете. В статье разберу, как проверить такую гипотезу и не спутать её с другими сетевыми проблемами, какие данные собрать для обращения и что делать, если заявка в ЛК ВТС уже получила статус «Частично принята», а доступ так и не восстановился. Покажу весь путь на реальном кейсе: от curl, traceroute и nping до переписки с ЦМУ ССОП и ДЦОА — без смены хостинга и IP-адреса.
Дисклеймер: в статье разбирается сценарий для информационных ресурсов юридических лиц. Все IP-адреса и трассировки изменены из соображений конфиденциальности. Описанные методы предназначены только для диагностики доступности собственных ресурсов и выявления ошибочной фильтрации. Статья не описывает способы обхода ограничений доступа, установленных в соответствии с законодательством РФ.
1. Диагностируем проблему: действительно ли это ТСПУ
Сначала нужно проверить, действительно ли проблема связана с фильтрацией на ТСПУ. Для базовой диагностики подойдут mtr, traceroute и nping.
Самое простое, что можно сделать, — это выполнить curl:
~# curl -4v --connect-to ::55.55.55.55 https://domain.ru --max-time 5 * Connecting to hostname: 55.55.55.55 * Trying 55.55.55.55:443... * Connected to (nil) (55.55.55.55) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * CAfile: /etc/ssl/certs/ca-certificates.crt * CApath: /etc/ssl/certs * TLSv1.0 (OUT), TLS header, Certificate Status (22): * TLSv1.3 (OUT), TLS handshake, Client hello (1): * Operation timed out after 5001 milliseconds with 0 bytes received * Closing connection 0 curl: (28) Operation timed out after 5001 milliseconds with 0 bytes received
curl показывает тайм-аут, но не позволяет понять, на каком участке сети трафик перестаёт проходить. SYN-пакеты проходят в том числе и через traceroute:
~# traceroute -T -p 443 55.55.55.55 traceroute to 55.55.55.55 (55.55.55.55), 30 hops max, 52 byte packets 1 192.168.1.1 (192.168.1.1) 0.066 ms 0.885 ms 0.687 ms 2 10.52.4.1 (10.52.4.1) 1.066 ms 0.885 ms 2.687 ms 3 172.29.31.15 (172.29.31.15) 40.471 ms 40.605 ms * 4 212.133.1.50 (212.133.1.50) 63.285 ms 63.113 ms 62.942 ms 5 * * * 6 * * * 7 * * * 8 55.55.55.55 (55.55.55.55) 68.463 ms 66.463 ms 67.463 ms
Например, сделаем трассировку TCP-пакета с флагами PSH+ACK и с длиной в 500 байт (без TCP-рукопожатия):
~# nping --tcp --flags PSH,ACK --data-length 500 -p 443 55.55.55.55 --tr -c 15 Starting Nping 0.7.98 ( https://nmap.org/nping ) at 2026-10-06 15:21 MSK SENT (0.0408s) TCP 88.88.88.88:18342 > 55.55.55.55:443 PA ttl=1 id=12542 iplen=540 seq=2280967134 win=1480 RCVD (0.0423s) ICMP [192.168.1.1 > 88.88.88.88 TTL=0 during transit (type=11/code=0) ] IP [ttl=64 id=15012 iplen=568 ] SENT (1.0417s) TCP 88.88.88.88:18342 > 55.55.55.55:443 PA ttl=2 id=15337 iplen=540 seq=2280967134 win=1480 RCVD (1.0432s) ICMP [10.52.4.1 > 88.88.88.88 TTL=0 during transit (type=11/code=0) ] IP [ttl=63 id=21398 iplen=568 ] SENT (2.0440s) TCP 88.88.88.88:18342 > 55.55.55.55:443 PA ttl=3 id=12542 iplen=540 seq=2280967134 win=1480 SENT (3.0443s) TCP 88.88.88.88:18342 > 55.55.55.55:443 PA ttl=4 id=12542 iplen=540 seq=2280967134 win=1480 SENT (4.0452s) TCP 88.88.88.88:18342 > 55.55.55.55:443 PA ttl=5 id=12542 iplen=540 seq=2280967134 win=1480 SENT (5.0473s) TCP 88.88.88.88:18342 > 55.55.55.55:443 PA ttl=6 id=12542 iplen=540 seq=2280967134 win=1480 SENT (6.0492s) TCP 88.88.88.88:18342 > 55.55.55.55:443 PA ttl=7 id=12542 iplen=540 seq=2280967134 win=1480 SENT (7.0503s) TCP 88.88.88.88:18342 > 55.55.55.55:443 PA ttl=8 id=12542 iplen=540 seq=2280967134 win=1480 SENT (8.0533s) TCP 88.88.88.88:18342 > 55.55.55.55:443 PA ttl=9 id=12542 iplen=540 seq=2280967134 win=1480 SENT (9.0577s) TCP 88.88.88.88:18342 > 55.55.55.55:443 PA ttl=10 id=12542 iplen=540 seq=2280967134 win=1480 SENT (10.0583s) TCP 88.88.88.88:18342 > 55.55.55.55:443 PA ttl=11 id=12542 iplen=540 seq=2280967134 win=1480 SENT (11.0592s) TCP 88.88.88.88:18342 > 55.55.55.55:443 PA ttl=12 id=12542 iplen=540 seq=2280967134 win=1480 SENT (12.0606s) TCP 88.88.88.88:18342 > 55.55.55.55:443 PA ttl=13 id=12542 iplen=540 seq=2280967134 win=1480 SENT (13.0623s) TCP 88.88.88.88:18342 > 55.55.55.55:443 PA ttl=14 id=12542 iplen=540 seq=2280967134 win=1480 SENT (14.0632s) TCP 88.88.88.88:18342 > 55.55.55.55:443 PA ttl=15 id=12542 iplen=540 seq=2280967134 win=1480 Max rtt: 1.420ms | Min rtt: 1.409ms | Avg rtt: 1.414ms Raw packets sent: 15 (8.310KB) | Rcvd: 2 (1.136KB) | Lost: 13 (86.67%) Nping done: 1 IP address pinged in 15.09 seconds
В нашем примере ответы приходят от маршрутизатора и BRAS оператора, а дальше трассировка перестаёт получать ICMP-ответы. Само по себе это ещё не доказывает фильтрацию ТСПУ, но помогает локализовать участок, который нужно проверять дальше.
Если есть подозрение, что фильтрация срабатывает на конкретное содержимое пакета, снимем дамп в Wireshark и скопируем TCP payload в шестнадцатеричном виде.
Вставляем payload (TLS Client Hello) в nping:
~# nping --tcp --flags PSH,ACK --data "1603....1e03b" -p 443 55.55.55.55 --tr -c 15 Starting Nping 0.7.98 ( https://nmap.org/nping ) at 2026-10-06 15:21 MSK SENT (0.0408s) TCP 88.88.88.88:18342 > 55.55.55.55:443 PA ttl=1 id=12542 iplen=540 seq=2280967134 win=1480 RCVD (0.0423s) ICMP [192.168.1.1 > 88.88.88.88 TTL=0 during transit (type=11/code=0) ] IP [ttl=64 id=15012 iplen=568 ] SENT (1.0417s) TCP 88.88.88.88:18342 > 55.55.55.55:443 PA ttl=2 id=15337 iplen=540 seq=2280967134 win=1480 RCVD (1.0432s) ICMP [10.52.4.1 > 88.88.88.88 TTL=0 during transit (type=11/code=0) ] IP [ttl=63 id=21398 iplen=568 ] SENT (2.0440s) TCP 88.88.88.88:18342 > 55.55.55.55:443 PA ttl=3 id=12542 iplen=540 seq=2280967134 win=1480 SENT (3.0443s) TCP 88.88.88.88:18342 > 55.55.55.55:443 PA ttl=4 id=12542 iplen=540 seq=2280967134 win=1480 SENT (4.0452s) TCP 88.88.88.88:18342 > 55.55.55.55:443 PA ttl=5 id=12542 iplen=540 seq=2280967134 win=1480 SENT (5.0473s) TCP 88.88.88.88:18342 > 55.55.55.55:443 PA ttl=6 id=12542 iplen=540 seq=2280967134 win=1480 SENT (6.0492s) TCP 88.88.88.88:18342 > 55.55.55.55:443 PA ttl=7 id=12542 iplen=540 seq=2280967134 win=1480 SENT (7.0503s) TCP 88.88.88.88:18342 > 55.55.55.55:443 PA ttl=8 id=12542 iplen=540 seq=2280967134 win=1480 SENT (8.0533s) TCP 88.88.88.88:18342 > 55.55.55.55:443 PA ttl=9 id=12542 iplen=540 seq=2280967134 win=1480 SENT (9.0577s) TCP 88.88.88.88:18342 > 55.55.55.55:443 PA ttl=10 id=12542 iplen=540 seq=2280967134 win=1480 SENT (10.0583s) TCP 88.88.88.88:18342 > 55.55.55.55:443 PA ttl=11 id=12542 iplen=540 seq=2280967134 win=1480 SENT (11.0592s) TCP 88.88.88.88:18342 > 55.55.55.55:443 PA ttl=12 id=12542 iplen=540 seq=2280967134 win=1480 SENT (12.0606s) TCP 88.88.88.88:18342 > 55.55.55.55:443 PA ttl=13 id=12542 iplen=540 seq=2280967134 win=1480 SENT (13.0623s) TCP 88.88.88.88:18342 > 55.55.55.55:443 PA ttl=14 id=12542 iplen=540 seq=2280967134 win=1480 SENT (14.0632s) TCP 88.88.88.88:18342 > 55.55.55.55:443 PA ttl=15 id=12542 iplen=540 seq=2280967134 win=1480 Max rtt: 1.420ms | Min rtt: 1.409ms | Avg rtt: 1.414ms Raw packets sent: 15 (8.310KB) | Rcvd: 2 (1.136KB) | Lost: 13 (86.67%) Nping done: 1 IP address pinged in 15.09 seconds
Если нужно выполнить TCP-рукопожатие, hex payload можно отправить через netcat:
echo -n "1603....51e5" | xxd -r -p | ncat 55.55.55.55 443 -v --no-shutdown
После этого в Wireshark или tcpdump проверяем, есть ли ретрансмиссии.
Чтобы понять, где происходит обрыв уже после TCP-рукопожатия и не связана ли проблема, например, с DDoS-защитой, я написал отдельный скрипт, который позволяет сделать трассировку пакета после совершения TCP-рукопожатия в рамках существующего соединения:
~# sudo python3 tcp_tspu_traceroute.py --target 55.55.55.55 --dport 443 --low-ttl-syn 5 --low-ttl-ack 5 --normal-ttl 27 --payload-hex "1603....0000" [*] Target: 55.55.55.55:443 [*] Source port: random [*] TTL: SYN_low=5, ACK_low=5, normal=27 [*] Payload (hex): 1603010200010001fc0303cf6bb4ab83c7a52eeeb467a980f6... [*] RST packets from port 65503 are blocked (rule at the top of the chain). [*] Sending dummy SYN with TTL=5... [*] Sending working SYN with TTL=27... [+] Received SYN-ACK from 55.55.55.55 [*] Sending dummy ACK with TTL=5... [*] Sending working ACK with TTL=27... [+] Connection established (source port 65503) [*] Starting traceroute with PSH+ACK probes... 1: 192.168.1.1 (ICMP TTL Exceeded) 2: 10.52.4.1 (ICMP TTL Exceeded) 3: * * * 4: * * * 5: * * * 6: * * * 7: * * * 8: * * * 9: * * * 10: * * * 11: * * * 12: * * * 13: * * * 14: * * * 15: * * * 16: * * * 17: * * * 18: * * * 19: * * * 20: * * * 21: * * * 22: * * * 23: * * * 24: * * * 25: * * * 26: * * * 27: * * * 28: * * * 29: * * * 30: * * * [*] Closing connection (FIN)... [*] RST blocking for port 65503 removed.
Проверить доступность собственного ресурса нужно также с помощью сервиса globalping (или ему подобных: например, ping-admin.com, check-host.net), выбрав узлы, которые расположены на территории России и других стран. Это позволит исключить сбой маршрутизации или влияние операторского оборудования:
Полученные результаты могут свидетельствовать о фильтрации трафика на участке сети оператора, где используется ТСПУ.
2. Отправляем заявку через ЛК ВТС
Если диагностика указывает на ошибочную фильтрацию на ТСПУ, следующий шаг — заявка через ЛК ВТС. Для авторизации от имени организации она должна быть зарегистрирована на Госуслугах, а у пользователя должна быть соответствующая роль. Переходим в ЛК ВТС, где нас встречает главная страница.
Прохо́дите авторизацию от имени организации, заполняете необходимые данные (ИНН, наименование организации). Подробная инструкция по работе с личным кабинетом находится здесь.
Заполняем заявку в зависимости от того, что у нас недоступно.
Пример заявки:
IP-адрес источника: 0.0.0.0/0
Порт источника: 0-65535
IP-адрес назначения: 55.55.55.55/32
Порт назначения: 443
Используемый протокол: TCP
Описание технологических процессов: лендинг страница
Предполагаемый объём трафика, Мбит/с: 1
Обоснование получения доступа для ресурса: Доступ №1 55.55.55.55/32 используется для лендинг страницы по домену domain.ru. Под 0.0.0.0/0 подразумевается Российский сегмент подсетей.
Заявку или отклонят, или переведут в статус «Частично принята». Возможны следующие статусы заявок:
Узнать более подробную причину отказа возможно через supervising@noc.gov.ru
3. Статус заявки «Частично принята», но фильтрация всё равно присутствует
Такой сценарий вполне возможен: заявка получила статус «Частично принята», но сетевой доступ не восстановился. Тогда нужно обращаться в техническую поддержку ДЦОА по адресу support_asbi@dcoa.ru или support_asbi@noc.gov.ru. Здесь возникает отдельная сложность: для диагностики ДЦОА просит номер площадки ТСПУ, на которой воспроизводится проблема. У обычного заявителя этих данных, как правило, нет, поэтому его направляют к оператору связи.
А что если попробовать попросить оператора связи предоставить номер ТСПУ или направить обращение в ДЦОА?
Попытки решить вопрос через операторов связи не принесли результатов. Я также нашёл интересный пост на форуме, где один из системных администраторов сообщил, что на ТСПУ случайно заблокировали крымские подсети. Он рассказал, что попытался решить проблему через РКН, но регулятор перенаправил его в ДЦОА, а оттуда его перенаправили бы к провайдеру. Тогда круг замкнулся бы.
Эта ситуация создаёт большое препятствие при попытке решить проблему:
В итоге выяснилось, что номер площадки возможно получить напрямую через ЦМУ ССОП по адресу supervising@noc.gov.ru без участия провайдера:
Однако если у провайдера нет своего ТСПУ, то ЦМУ ССОП не сможет предоставить данный номер — и вас отправят второй раз к своему провайдеру.
После того как получили номер площадки, формируем письмо в ДЦОА:
Добрый день! Недоступен domain.ru по IP-адресу 55.55.55.55. Номер ТСПУ — №4XXX, республика A, город B, провайдер C (ASN XXXXX). Ранее в ЛК ВТС отправлялась заявка на исключение из фильтрации, и она находится в статусе «Частично принята» — №XXXXX, но доступ к IP-адресу ошибочно ограничивается. Активность до ресурса уже идёт, прошу начать диагностику: 88.88.88.88 <-> 55.55.55.55:443 (TCP, HTTPS) Результат DNS-резолвинга: ~# dig +short domain.ru 55.55.55.55 ~# dig +short domain.ru @77.88.8.8 55.55.55.55 Результат трассировки до 55.55.55.55 по ICMP-протоколу: ~# traceroute -I 55.55.55.55 traceroute to 55.55.55.55 (55.55.55.55), 30 hops max, 52 byte packets 1 192.168.1.1 (192.168.1.1) 0.066 ms 0.885 ms 0.687 ms 2 10.52.4.1 (10.52.4.1) 1.066 ms 0.885 ms 2.687 ms 3 172.29.31.15 (172.29.31.15) 40.471 ms 40.605 ms * 4 212.133.1.50 (212.133.1.50) 63.285 ms 63.113 ms 62.942 ms 5 * * * 6 * * * 7 * * * 8 55.55.55.55 (55.55.55.55) 68.463 ms 66.463 ms 67.463 ms Результат трассировки до 55.55.55.55 по TCP-протоколу: ~# traceroute -T -p 443 55.55.55.55 traceroute to 55.55.55.55 (55.55.55.55), 30 hops max, 52 byte packets 1 192.168.1.1 (192.168.1.1) 0.066 ms 0.885 ms 0.687 ms 2 10.52.4.1 (10.52.4.1) 1.066 ms 0.885 ms 2.687 ms 3 172.29.31.15 (172.29.31.15) 40.471 ms 40.605 ms * 4 212.133.1.50 (212.133.1.50) 63.285 ms 63.113 ms 62.942 ms 5 * * * 6 * * * 7 * * * 8 55.55.55.55 (55.55.55.55) 68.463 ms 66.463 ms 67.463 ms Результат выполнения команды curl: ~# curl -4v --connect-to ::55.55.55.55 https://domain.ru --max-time 5 * Connecting to hostname: 55.55.55.55 * Trying 55.55.55.55:443... * Connected to (nil) (55.55.55.55) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * CAfile: /etc/ssl/certs/ca-certificates.crt * CApath: /etc/ssl/certs * TLSv1.0 (OUT), TLS header, Certificate Status (22): * TLSv1.3 (OUT), TLS handshake, Client hello (1): * Operation timed out after 5001 milliseconds with 0 bytes received * Closing connection 0 curl: (28) Operation timed out after 5001 milliseconds with 0 bytes received
И тут самое важное: для ДЦОА необходима сетевая активность в момент диагностики, поэтому сразу запускаем цикл с IP-адреса 88.88.88.88:
while true; do curl -4v --connect-to ::55.55.55.55 https://domain.ru --max-time 5; sleep 1; done
Связку src ip <-> dst ip:dst port необходимо предоставлять в зависимости от архитектуры сети оператора связи. Если клиент находится за CG-NAT, может возникнуть весьма резонный вопрос: а где находится ТСПУ — до или после операторского CG-NAT? Какой src ip предоставлять: серый или белый? На такой случай лучше всего иметь белый статический IP-адрес.
В случае нашего клиента после обращения специалисты ДЦОА проверили площадку ТСПУ, на которой воспроизводилась проблема, и скорректировали правила фильтрации. Затем попросили проверить доступность сервера:
Проверяем через curl — веб-ресурс действительно снова доступен:
~# curl -4v --connect-to ::55.55.55.55 https://domain.ru -k * Connecting to hostname: 55.55.55.55 * Trying 55.55.55.55:443... * Connected to (nil) (55.55.55.55) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * TLSv1.0 (OUT), TLS header, Certificate Status (22): * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.2 (IN), TLS header, Certificate Status (22): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS header, Finished (20): * TLSv1.2 (IN), TLS header, Supplemental data (23): * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): * TLSv1.2 (IN), TLS header, Supplemental data (23): * TLSv1.3 (IN), TLS handshake, Certificate (11): * TLSv1.2 (IN), TLS header, Supplemental data (23): * TLSv1.3 (IN), TLS handshake, CERT verify (15): * TLSv1.2 (IN), TLS header, Supplemental data (23): * TLSv1.3 (IN), TLS handshake, Finished (20): * TLSv1.2 (OUT), TLS header, Finished (20): * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.2 (OUT), TLS header, Supplemental data (23): * TLSv1.3 (OUT), TLS handshake, Finished (20): * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 * ALPN, server accepted to use h2 * Server certificate: * subject: C=RU; ST=TEST; O=TEST * start date: Jan 1 14:51:20 2024 GMT * expire date: Feb 25 14:51:20 2038 GMT * issuer: C=RU; ST=TEST; O=TEST * SSL certificate verify result: self-signed certificate (18), continuing anyway. * Using HTTP2, server supports multiplexing * Connection state changed (HTTP/2 confirmed) * Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0 * TLSv1.2 (OUT), TLS header, Supplemental data (23): * TLSv1.2 (OUT), TLS header, Supplemental data (23): * TLSv1.2 (OUT), TLS header, Supplemental data (23): * Using Stream ID: 1 (easy handle 0x55b28ceca0) * TLSv1.2 (OUT), TLS header, Supplemental data (23): > GET / HTTP/2 > Host: domain.ru > user-agent: curl/7.81.0 > accept: */* > * TLSv1.2 (IN), TLS header, Supplemental data (23): * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * TLSv1.2 (IN), TLS header, Supplemental data (23): * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * old SSL session ID is stale, removing * TLSv1.2 (IN), TLS header, Supplemental data (23): * Connection state changed (MAX_CONCURRENT_STREAMS == 128)! * TLSv1.2 (OUT), TLS header, Supplemental data (23): * TLSv1.2 (IN), TLS header, Supplemental data (23): < HTTP/2 403 < server: nginx < date: Tue, 02 Oct 2026 13:11:16 GMT < content-type: text/html < content-length: 146 < <html> <head><title>403 Forbidden</title></head> <body> <center><h1>403 Forbidden</h1></center> <hr><center>nginx</center> </body> </html> * Connection #0 to host (nil) left intact
Прошлый опыт взаимодействия с ДЦОА в рамках нашего PI-блока показывает, что одной сессии диагностики бывает недостаточно. Процесс может затянуться, а исключение из фильтрации — получиться не с первого раза. И всё же этот путь гораздо быстрее, чем через горячую линию ГРЧЦ (hotline@grfc.ru).
Если вы сталкивались с ошибочной фильтрацией на ТСПУ или взаимодействовали с ДЦОА, расскажите в комментариях, как проходила диагностика и что в итоге помогло восстановить доступ.
An_Tosha
Вы каким-то сложным путём пошли.
Можно было сразу направить заявку оператору, и пусть он взаимодействует с ДЦОА.
Если у оператора нет своего ТСПУ, он по той же схеме обращается к своему аплинку, который тспушит данный канал.
ДЦОА - это вендор, структура, которая занимается установкой, обслуживанием и непосредственным управлением ТСПУ производства RDP.ru.
У них сидит круглосуточная дежурная смена.
Именно поэтому РКН и его подразделение ГРЧЦ шлют к ним.
Я ежедневно обрабатываю такие тикеты, процесс уже давно отлажен, есть шаблоны отправки.
От клиента обычно требуется src, dst и трассировка.
Трассировка, кстати, нужна и самому оператору, чтобы проверить, через какую/какие площадки проходит трафик. Да, да, он может проходить через несколько.
А дополнительные данные типа номера площадки мы прикладываем сами.
Обычно ДЦОА ещё просит создать активность - попытки подключения к ресурсу не реже 1 раза в 5 минут, чтобы они поймали сессию.
В особо тяжёлых случаях они могут попросить удалённый доступ - тестовую машину с RDP/Rudesktop, чтобы подключиться самим и воспроизвести проблему.
Так же одним из способов диагностики может быть временное исключение канала из фильтрации. ДЦОА это не очень любит, но по запросу делает.
Обычно в согласованное время, на промежуток от 1 до 2 часов.
Отвечают они сравнительно быстро. Некоторые тикеты можно решить за полдня за пару-тройку итераций.
Не знаю что такого секретного в номере площадки ТСПУ, что Уфанет отказался сообщить.
А Ростелеком и вовсе слукавил, что не может отправить заявку в ДЦОА. Могут и должны.
0ka
у меня только 1 инет провайдер принимает заявки по поводу блокировок на тспу - ситилинк, но только если рандом отправит к знающему агенту тех поддержки и только если проблемный сайт не открывается вообще (а если он с огромной задержкой всё таки открывается то сообщают что проблем нет), если на проблемном ip-адресе нет сайта то они проигнорируют всю вашу диагностику, сделают свою трассировку и не увидят проблемы. к счастью, номера ТСПУ апстримов мне всё же отправили, это мне удивительно повезло. напишите можно ли как-то к вам обратиться, очень сложно найти человека который может решать такие проблемы
An_Tosha
Ситилинк, который в Карелии?
Можете писать в личные сообщения.
angry_agent Автор
Взаимодействие с ДЦОА напрямую происходит гораздо быстрее, чем через оператора связи, посредник добавляет задержки.
Не все операторы связи готовы на "ура" пересылать проблему в ДЦОА. А если проблема воспроизводится например только на мобильном интернете у федерального оператора, то не юридического лица развернут в 99,9% случаев, но как показывает практика, юридическим тоже могут отказать. Тут русская рулетка в зависимости от провайдера.
An_Tosha
Про задержку согласен, дополнительные этапы могут увеличивать время решения.
У мобильных операторов действительно сложно пробиться через роботов до живого человека, который адекватно примет проблему.