TCP соединение устанавливается, но SSH/TLS handshake не начинается

[Delovoy]

Код: [Выделить]

Столкнулся с очень странной сетевой проблемой на VPS.

СИМПТОМЫ
SSH и TLS ломаются именно на стадии handshake, при этом само TCP-соединение устанавливается нормально.


SSH ПРИМЕР

sshd запущен и слушает нестандартный порт:

ss -lntp | grep :PORT
LISTEN 0 128 0.0.0.0:PORT users:(("sshd",...))


TCP connect проходит успешно:

nc -v VPS_IP PORT
Connection succeeded


Но SSH handshake не начинается — удалённый баннер от сервера не приходит:

ssh -4 -p PORT user@VPS_IP -vvv
Connection established.
Local version string SSH-2.0-OpenSSH
(no remote banner received)


TLS/HTTPS АНАЛОГИЧНО

На 443 TCP соединение устанавливается, но TLS handshake зависает/таймаутится.


ЧТО УЖЕ ПРОВЕРЕНО

MTU / PMTUD в порядке

DF ping с payload 1472 проходит без потерь:

ping -M do -s 1472 1.1.1.1
0% packet loss


IPv6 исключён:

ssh -4 ...


Firewall отключён

UFW/iptables пустые, локальной фильтрации нет.


SSH локально на VPS работает:

ssh -p PORT user@127.0.0.1
(соединение доходит до password prompt)

То есть sshd исправен и баннер отдаёт локально.


Tcpdump во время внешнего подключения

На интерфейсе eth0 видно, что сервер отправляет данные, но идут ретрансляции PSH:

Flags [P.], length XX
(repeated retransmissions)

То есть серверный баннер/данные уходят, но клиент их не получает или не подтверждает ACK.


ПОДОЗРЕНИЕ

Похоже на проблему сетевого уровня:

- upstream filtering
- DDoS mitigation
- DPI (режут SSH/TLS payload после TCP handshake)
- асимметричная потеря пакетов

Причём одинаково не работает и с домашнего, и с мобильного интернета (страна одна).


ВОПРОС

Кто сталкивался с ситуацией, когда TCP connect проходит,
но протоколы (SSH/TLS) не могут завершить handshake?

Какие ещё тесты можно сделать, чтобы точно доказать фильтрацию/mitigation
и понять, где именно ломается доставка данных?

Буду благодарен за любые идеи и опыт.
[/code
]
Отфарматирую чутиь позже


[bezbo]

Страна? ОС? Хостер?

[Delovoy]

Страна? ОС? Хостер?

RU, Ubuntu, Hosthatch

Код: [Выделить]

UPDATE (дополнительные наблюдения)

Продолжаю диагностику. Теперь удалось собрать железные доказательства, что проблема не в sshd/файрволе, а именно в доставке данных после TCP-handshake.

1) SSH клиент с моей стороны

Подключение устанавливается, но удалённый баннер не приходит:

ssh -4 -p PORT user@VPS_IP -vvv

debug1: Connecting to VPS_IP port PORT
debug1: Connection established.
debug1: Local version string SSH-2.0-OpenSSH_9.x
(после этого удалённый баннер не появляется, соединение висит)


2) На VPS sshd работает и слушает порт

systemctl status ssh
active (running)

ss -lntp | grep ssh
LISTEN 0 128 0.0.0.0:PORT ...


3) Tcpdump на VPS во время внешней попытки подключения

Запустил захват:

tcpdump -ni eth0 port PORT

Видно нормальный TCP 3-way handshake:

HOME_IP:53144 -> VPS_IP:PORT Flags [S]
VPS_IP:PORT -> HOME_IP:53144 Flags [S.]
HOME_IP:53144 -> VPS_IP:PORT Flags [.]

После этого сервер отправляет SSH banner (PSH length ~40),
но идут постоянные ретрансляции:

VPS_IP:PORT -> HOME_IP:53144 Flags [P.], length 40: SSH: SSH-2.0-OpenSSH...
VPS_IP:PORT -> HOME_IP:53144 Flags [P.], length 40: (retransmission)
VPS_IP:PORT -> HOME_IP:53144 Flags [P.], length 40: (retransmission)
...

То есть сервер реально отправляет баннер, но клиент его не получает
или не подтверждает ACK.


4) Локально на VPS ssh работает нормально

ssh -p PORT user@127.0.0.1
(доходит до password prompt)

Firewall на VPS отключён, правила iptables пустые.


Вывод

Похоже, что TCP соединение устанавливается,
но данные протокола (SSH/TLS payload) теряются/фильтруются после handshake.

Возможные причины:

- upstream filtering / DPI
- DDoS mitigation
- асимметричная потеря пакетов
- блокировка по маршруту/региону

Если у кого-то есть идеи, какие дополнительные тесты сделать
(например, через другие сети/Cloud Shell),
буду благодарен.


Дополнительный важный факт

Код: [Выделить]


Из Google Cloud Shell (другой регион/маршрут) SSH к этому же VPS работает нормально сразу.

Вывод:
Проблема почти наверняка на уровне маршрута/фильтрации между моей страной и конкретным IP VPS:
[i]
upstream filtering
DPI
route-specific blackhole
возможно санкционные/региональные ограничения[/i]

Сейчас написал в поддержку хостинга с просьбой:

сменить IPv4 или перенести VPS на другую подсеть/нод
Решение: смена IP у хостера. Старый IP был “поломан” по маршруту (TCP connect OK, payload не проходил). После выдачи нового IP всё сразу ожило.

Всем спс.