Sevastopol.info

rand писал(а): ↑

05 сен, 2026, 1:54

[SOLVED]

Спойлер!

Дмитрий SevStar, добрый вечер.

Сегодня столкнулся с довольно специфической проблемой на домашнем подключении и хотел бы уточнить, не менялось ли что-то на сети севстара — DPI, BRAS/BNG, фильтрация или иное промежуточное оборудование.

Симптом следующий: обычные HTTPS-соединения с современным TLS 1.3 периодически/стабильно зависают сразу после отправки ClientHello. При этом TCP-соединение на 443 устанавливается нормально.

Провёл A/B-тест с одного и того же устройства, на один и тот же сервер, через один и тот же маршрут:

* TLS 1.3 с настройками по умолчанию OpenSSL 3.5.5 — timeout сразу после ClientHello;
* тот же TLS 1.3, но с принудительным X25519 вместо стандартного набора групп — работает нормально;
* TLS 1.2 — работает нормально;
* обычный HTTP — работает нормально.

Современный OpenSSL 3.5 по умолчанию использует гибридный post-quantum key exchange X25519MLKEM768, из-за чего TLS ClientHello заметно увеличивается в размере и может разбиваться на несколько TCP-сегментов.

Дополнительно проверял на собственном VPS. Пакетный захват показывает, что TCP handshake проходит, но при проблемном варианте соединение зависает именно на этапе TLS. При TLS 1.2 тот же путь полностью работает, включая передачу крупных TCP-сегментов.

Поэтому есть подозрение не на блокировку конкретного сайта, IP или SNI, а на несовместимость какого-то промежуточного оборудования с современным TLS 1.3 ClientHello / X25519MLKEM768.

Ранее на этом же подключении всё работало, конфигурация домашнего оборудования в последнее время не менялась.

Не хотелось бы сразу предполагать намеренную фильтрацию — это вполне может быть побочным эффектом обновления DPI или сетевого оборудования.

Можете, пожалуйста, проверить:

1. не обновлялось ли в последнее время DPI/CGNAT/BNG или другое оборудование на моём направлении;
2. нет ли известных проблем с TLS 1.3 ClientHello, содержащим X25519MLKEM768;
3. не применяется ли какая-либо фильтрация или инспекция TLS ClientHello, которая может приводить к silent drop соединения.

В результате дома есть интернет без интернета, поскольку большинство серверов по умолчанию включили post-quantum TLS по-дефолту.

UPD: оставил заявку #2566069 в ТП.
UPD2: сегодня весь день даже древний TLS 1.2 то блэкхолится , то ходит с маленьким PQ Hello. Сходил к соседу по подъезду, он висит со мной на общедомовом коммутаторе, у него картина такая же. Ни один https сайт не открывается!

UPD3: короче у меня патч-панели патчкорд НЕПЛОТНО СИДЕЛ, КАРЛ! Но как я до этого дошёл? Можно снимать драму на нетфликсе.

Симптомы при диагностике получились очень обманчивые. Сначала я наблюдал примерно следующее:

* IP-связность частично работала, на полшишечки
* TCP хендшейк на 443 устанавливался(!)
* TLS ClientHello уходил, после чего соединение висло
* TLS 1.3 с PQ keyshare падал особенно стабильно
* в разные моменты TLS 1.3 с X25519 и TLS 1.2 могли работать или переставали работать наглухо
* обычный HTTP местами продолжал жить, но это не точно

Для проверки тот же телефон с curl 8.14.1 и OpenSSL 3.5.8 был протестирован через:

* Собсно мой домашний вайфай
* соседский роутер
* сотовую сеть

Через соседское подключение и МТС всё работало нормально, а через моё — нет. ХОТЯ было несколько ситуаций когда у соседа наблюдались почти идентичные симптомы, думаю здесь бабка пошептала

Решающим оказался tcpdump и статистика на йWAN порту роутера.

В захвате было видно крайне странное поведение TCP: сервер принимал запрос и продвигал sequence number, ACK/FIN иногда доходили, но сам ответный TCP payload на WAN-интерфейсе тупо отсутствовал.

После этого дернуло меня посмотреть счётчики эзернета:

RX packets: ~548 000
RX errors: ~863 000
RX CRC errors: ~863 000
RX dropped: ~155 000
TX errors: 0

То есть ошибок CRC на приёме было даже больше, чем успешно принятых пакетов!11

Дополнительно WAN при включённом autonegotiation согласовался всего на:

10 Mbps
Full Duplex

И тут зашевелилась мысль открыть шкаф и пошевелить кабель в кейстоуне.

Мораль сей басни получилась довольно показательная: повреждённый эзенрет-линк вовсе не обязательно выглядит как _линк_упал. Carrier может оставаться UP, TCP SYN/SYN-ACK могут проходить, маленькие служебные пакеты тоже, а данные будут теряться настолько выборочно, что проблема начинает выглядеть как DPI, MTU или сломанный TLS.

Так что при подобных мистических сетевых симптомах стоит достаточно рано смотреть:

ip -s -s link show

и в первую очередь RX errors / CRC / dropped, а также реально согласованную скорость порта.

СПАСИБО ЗА ВАШЕ ВНИМАНИЕ К ЭТОМУ ВОПРОСУ!

RedCat писал(а):

Так что на севстар по дефолту все за NATом.

kovilenalena писал(а): ↑

09 сен, 2026, 17:12

RedCat писал(а):

Так что на севстар по дефолту все за NATом.

Не по дефолту, зависит наверное от тарифа, некоторым счастливчикам продолжают выдавать белый, но динамический айпи.