Ростелеком СПб — не проходит TCP/8888 до Synology, TCP/443 до того же IP работает

[Иван П]

Добрый день.

Нужна помощь в локализации проблемы. Я не сетевой специалист, поэтому буду благодарен, если подскажете, какую дополнительную диагностику снять.

Исходные данные

СПб, домашний GPON Ростелеком.
NAS — Synology DS220+, DSM 7.4.1.
Не работает внешний доступ через Synology QuickConnect/Relay.

QuickConnect на NAS включён, Relay включён. Интернет с NAS работает, DNS работает.

В ходе диагностики с самого NAS получили:

nslookup global.quickconnect.to

возвращает:

18.159.250.241
63.187.179.21

Проверка HTTPS с NAS:

curl -I --connect-timeout 10 https://account.synology.com

проходит нормально.

 

Проверял Relay:

curl -v --connect-timeout 10 http://18.159.250.241:8888/

результат — connection timeout.

curl -v --connect-timeout 10 http://63.187.179.21:8888/

также connection timeout.

При этом с того же NAS до того же 18.159.250.241, но на TCP/443:

curl -vk --connect-timeout 10 https://18.159.250.241/

соединение устанавливается, TLS проходит, получаем HTTP/2 200.

То есть получается:

18.159.250.241:443   — OK
18.159.250.241:8888  — timeout
63.187.179.21:8888   — timeout

Дополнительно:

— firewall DSM проверен — активен профиль без каких-либо правил, блокировки 8888 там нет;
— исходящих IP-фильтров на абонентском роутере нет;
— обычный доступ NAS в Интернет работает;
— при проверке через альтернативный маршрут/VPN TCP/8888 до 18.159.250.241 как минимум один раз успешно устанавливался.

В Ростелеком было направлено техническое обращение с просьбой проверить маршрутизацию/фильтрацию до указанных IP:8888. Получен ответ, что ограничений со стороны Ростелекома нет и следует обращаться к владельцу ресурса. Результатов проверки конкретных IP/портов в ответе не привели.

Собственно вопросы:

1. На что это больше похоже — проблема на стороне Synology, маршрутизации/пирингов или фильтрация TCP/8888 где-то по пути?

2. Какую диагностику имеет смысл дополнительно снять с NAS/подключения Ростелекома, чтобы определить, где именно теряется соединение?

3. Можно ли каким-либо тестом убедительно отделить проблему сети Ростелекома от проблемы принимающей стороны?

Если нужны traceroute, дополнительные curl, адрес моего внешнего IP или другие результаты — сниму.

Заранее спасибо.

[tcup]

17 minutes ago, Иван П said:

То есть получается:

18.159.250.241:443   — OK
18.159.250.241:8888  — timeout
63.187.179.21:8888   — timeout

У меня через ТТК так же. Только телнетом проверял

Edited September 7 by tcup

[jffulcrum]

Ха, уже две недели воюем с провайдерами про порты 9000 и 8443. Где-то Большой Брат включил фильтр

[straus]

Получается ТС угадал все буквы Р К Н Т С П У, но не смог сказать слово.

[naves]

Из Европы порт 8888 тоже закрыт. Откуда он вообще взялся?

 

nslookup global.quickconnect.to

Non-authoritative answer:
Name:	global.quickconnect.to
Address: 63.188.89.222
Name:	global.quickconnect.to
Address: 18.196.51.166


curl -v --connect-timeout 10 63.188.89.222:8888
*   Trying 63.188.89.222:8888...
* Connection timed out after 10001 milliseconds
* Closing connection 0
curl: (28) Connection timed out after 10001 milliseconds

curl -v --connect-timeout 10 18.196.51.166:8888
*   Trying 18.196.51.166:8888...
* Connection timed out after 10001 milliseconds
* Closing connection 0
curl: (28) Connection timed out after 10001 milliseconds

 

[straus]

Хо-хо.

Вообще 8888 это ещё один порт http. Может на том конце просто отстрелили нешифрованые соединения (что и правильно)...

[naves]

2 hours ago, Иван П said:

3. Можно ли каким-либо тестом убедительно отделить проблему сети Ростелекома от проблемы принимающей стороны?

https://en.wikipedia.org/wiki/Layer_four_traceroute

 

трейс на определенный порт TCP

sudo traceroute -T -p 8888 global.quickconnect.to

 

 

[Иван П]

Спасибо. Снял TCP traceroute непосредственно с Synology.

Сейчас global.quickconnect.to резолвится в 63.188.89.222.

На TCP/8888:

1  192.168.2.1
2  94.142.15.1
3-30  * * *

На TCP/443 до того же адреса:

1  192.168.2.1
2  94.142.15.1
3-9  * * *
10  63.188.89.222  ~40 ms

То есть TCP traceroute на 443 достигает конечного узла, на 8888 — нет.

Правильно ли понимаю, что по этим данным всё ещё нельзя определить, фильтруется 8888 где-то по пути или просто не принимается конечной стороной? Что лучше проверить следующим шагом?

 

[Иван П]

как отличить ТСПУ/DPI от DROP на стороне AWS/Synology?

[jffulcrum]

1 час назад, Иван П сказал:

как отличить ТСПУ/DPI от DROP на стороне AWS/Synology?

Снимите сниффером трафик на клиенте что прилетает, и что НЕ прилетает.

[naves]

Второй раз задаю вопрос, кто вам сказал, что там вообще что-либо должно быть на 8888 порту?

вот трейс из Амстердама, 8.8.8.8 точно так же не работает

 

traceroute -T -p 8888 global.quickconnect.to 
traceroute to global.quickconnect.to (18.196.51.166), 30 hops max, 60 byte packets
 1  blablablabla  0.185 ms  0.203 ms  0.183 ms
 2  nsx-t.am4.ams.gblnet.net (109.239.132.90)  1.610 ms  1.702 ms  1.769 ms
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *^C

traceroute -T -p 8888 global.quickconnect.to 
traceroute to global.quickconnect.to (63.188.89.222), 30 hops max, 60 byte packets
 1  blablabla  0.191 ms  0.177 ms  0.159 ms
 2  nsx-t.am4.ams.gblnet.net (109.239.132.90)  1.046 ms  1.094 ms  1.147 ms
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *^C



traceroute -T -p 443 global.quickconnect.to 
traceroute to global.quickconnect.to (63.188.89.222), 30 hops max, 60 byte packets
 1  blablablabla  0.192 ms  0.183 ms  0.167 ms
 2  nsx-t.am4.ams.gblnet.net (109.239.132.90)  0.908 ms  1.019 ms  0.988 ms
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  ec2-63-188-89-222.eu-central-1.compute.amazonaws.com (63.188.89.222)  13.946 ms  13.899 ms *

 

[straus]

Вопрос: если есть белый адрес - не проще ли настроить проброс порта и не зависеть ни от кого? 40 секунд на настройку своего роутера - не слишком большая цена.

 

P.S. В описании Synology QuickConnect упоминаются порты 5000, 5001, 6690 и ни слова про 8888.

[Иван П]

Спасибо за советы. Похоже, с 8888 я действительно пошёл не туда.

Перепроверил, откуда вообще взял этот порт. Он есть в официальной справке Synology по QuickConnect, но справка старая, ещё для DSM 6. В актуальной документации DSM 7.4 и свежем перечне портов 8888 уже не вижу.

Плюс Naves из Амстердама получил на 8888 тот же timeout, что и я через Ростелеком. Так что версию, что именно Ростелеком режет 8888, пока откладываю.

Исходная проблема при этом осталась: QuickConnect/Relay снаружи не работает.

По адресу тоже уточню: статический IP отдельно не подключал. На WAN терминала был 95.55.92.127. Насколько понимаю, это публичный, но динамический адрес. Если не так — поправьте.

Правильно понимаю, что теперь логичнее снять трафик с самого NAS в момент подключения QuickConnect и посмотреть, куда он реально пытается ходить?

[straus]

В 08.09.2026 в 09:28, Иван П сказал:

По адресу тоже уточню: статический IP отдельно не подключал. На WAN терминала был 95.55.92.127. Насколько понимаю, это публичный, но динамический адрес.

Да, полноценный белый адрес. Он может выдаваться по DHCP (динамически), но при этом всегда один и тот-же, и меняться раз в 3-5 лет или не меняться вообще. Тогда это для пользователя будет аналогично статическому адресу. Нужно выяснить этот момент, может все эти телодвижения и не нужны.

 

При динамическом часто сменяемом IP есть ещё вариант с DDNS (бесплатным или платным), но это не лучший вариант.

 

В 08.09.2026 в 09:28, Иван П сказал:

Правильно понимаю, что теперь логичнее снять трафик с самого NAS в момент подключения QuickConnect и посмотреть, куда он реально пытается ходить?

Да там и трафик снимать не надо. Если в роутере есть страница с текущими соединениями - там всё будет видно, и адрес и порт. Причём устройство может подключаться по имени сайта (запрашивая его из DNS) или по уже забитому в него IP-адресу, но для пользователя это пофиг.

Кстати, в самом устройстве в настройках или помощи тоже могут быть явно указаны адреса и порты QuickConnect.

 

Да, и ещё: хост, к которому подключается NAS, и хост, к которому подключается внешний пользователь для доступа к NAS, вполне могут быть не просто разными, а даже находящимися в разных странах.

 

В 08.09.2026 в 09:28, Иван П сказал:

Исходная проблема при этом осталась: QuickConnect/Relay снаружи не работает.

В текущих условиях надо стараться минимально использовать внешние сервисы - QuickConnect или иностранный DDNS использовать только как наихудший вариант.

Edited September 8 by straus

[Иван П]

Посмотрел, что удалось найти на самом NAS.

synorelayd держит соединение на 443:

192.168.2.13:59648 -> 159.100.4.146:443 ESTABLISHED synorelayd

При попытке зайти с телефона через мобильную сеть на fortressip.quickconnect.to получаю ту же ошибку «Unable to connect». В этот момент в synorelayd.log добавляются две строки:

Tunnel ready, add trust proxy
Tunnel ready, add trust proxy

Не знаю, насколько эта информация вообще полезна для диагностики.

Подскажите, пожалуйста, куда дальше правильнее смотреть? Если нужны какие-то конкретные логи/тесты — сниму.

[Иван П]

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

Посмотрел Synology Account — DS220+ привязан нормально, QuickConnect ID FORTRESSIP зарегистрирован, DDNS phanshtein.synology.me в статусе «Нормальный», внешний IP отображается 95.55.92.127.

На NAS synorelayd держит внешнее соединение по TCP/443. При попытке подключения с телефона через мобильную сеть в synorelayd.log появляются строки:

Tunnel ready, add trust proxy
Tunnel ready, add trust proxy

Параллельно снял короткий tcpdump по 443. Во время неудачной попытки NAS устанавливает несколько внешних TCP/443-соединений, handshake проходит, ответы приходят, есть двусторонний обмен данными и нормальные FIN/ACK.

Локально QuickConnect endpoint nginx тоже отвечает штатно:

curl -k -H "Host: fortressip.direct.quickconnect.to" \
"https://127.0.0.1:5001/webman/pingpong.cgi?quickconnect=1"

результат:

HTTP/2 200
{"success": true, "ezid": "..."}

В nginx есть отдельная конфигурация dsm.synorelayd.conf, то есть связка relay → nginx предусмотрена штатно.

Ещё посмотрел сокеты synorelayd: кроме внешнего TCP/443 у него есть несколько connected Unix STREAM/DGRAM sockets, причём безымянных. То есть внутренний обмен там, похоже, идёт не только через loopback TCP, и обычным tcpdump -i lo его можно вообще не увидеть.

На этом, пожалуй, в сеть глубже уже не лезу. По совокупности похоже, что наружный TCP/443 и локальный nginx работают, а проблема где-то внутри механизма QuickConnect/Relay.

Если у кого-то есть идея, какой штатный лог или тест DSM имеет смысл смотреть дальше — буду благодарен.

[naves]

А вы чего сделать-то хотите-то?

 

А то столько букв, а чего конкретно вы хотите получить непонятно.

[Иван П]

Добрый вечер. Цель — организовать нормальный внешний доступ к NAS через QuickConnect/Relay, в первую очередь к Synology Photos, без прямого открытия DSM наружу. Сейчас QuickConnect из внешней сети не работает, хотя сам NAS в Интернет выходит, DNS работает, а synorelayd держит ESTABLISHED на внешние :443. Хочу понять, где именно ломается цепочка: на NAS/DSM, в инфраструктуре Synology или где-то между ними.