Нет доступа по домену KeenDNS в Edge/Chrome 124

[dimon27254]

Пару дней назад на компьютере обновился Google Chrome до версии 124, после чего появились проблемы с доступом к веб-интерфейсу некоторых из имеющихся Кинетиков. 

По IP адресу через HTTP все работает нормально, но по доменному имени KeenDNS через HTTPS браузер выдает  ошибку ERR_CONNECTION_RESET (соединение сброшено).

Проявляется это на Кинетиках, у которых используется "прямой доступ" KeenDNS, и порт управления по HTTPS сменен на отличный от 443. На части Кинетиков установлена KeeneticOS 4.1.4, на другой 4.2 Alpha 5.

Аналогичная ситуация и в Edge 124. Проверял на нескольких ПК, подключенных через разных интернет-провайдеров, в том числе через "чувствительное ключевое слово из трех букв".

Доступ восстанавливается, если или:
1) установить режим работы KeenDNS "через облако";
2) вернуть порт управления Кинетиком по HTTPS на 443 (UPD: все-таки, это не помогает, т.к. при создании темы проверял только на "локальном" Кинетике);
3) понизить версию браузера до 123;
4) отключить в политиках браузера постквантовый алгоритм согласования ключей для TLS (Kyber, включен по умолчанию начиная с версии 124).

Не совсем понимаю, в чем проблема. То-ли какой-то баг в браузерах, или же веб-сервер Кинетика не совсем корректно обрабатывает запросы.

@Le ecureuil @sergeyk @hellonow

[Илья Картавенко]

1 час назад, dimon27254 сказал:

Пару дней назад на компьютере обновился Google Chrome до версии 124, после чего появились проблемы с доступом к веб-интерфейсу некоторых из имеющихся Кинетиков. 

По IP адресу через HTTP все работает нормально, но по доменному имени KeenDNS через HTTPS браузер выдает  ошибку ERR_CONNECTION_RESET (соединение сброшено).

Проявляется это на Кинетиках, у которых используется "прямой доступ" KeenDNS, и порт управления по HTTPS сменен на отличный от 443. На части Кинетиков установлена KeeneticOS 4.1.4, на другой 4.2 Alpha 5.

Аналогичная ситуация и в Edge 124. Проверял на нескольких ПК, подключенных через разных интернет-провайдеров, в том числе через "чувствительное ключевое слово из трех букв".

Доступ восстанавливается, если или:
1) установить режим работы KeenDNS "через облако";
2) вернуть порт управления Кинетиком по HTTPS на 443;
3) понизить версию браузера до 123;
4) отключить в политиках браузера постквантовый алгоритм согласования ключей для TLS (включен по умолчанию начиная с версии 124).

Не совсем понимаю, в чем проблема. То-ли какой-то баг в браузерах, или же веб-сервер Кинетика не совсем корректно обрабатывает запросы.

@Le ecureuil @sergeyk @hellonow

Сегодня было еще обновление хрома, проверьте

[dimon27254]

1 минуту назад, Илья Картавенко сказал:

Сегодня было еще обновление хрома, проверьте

Пару часов назад, до создания темы, Chrome у меня обновился до версии 124.0.6367.79, но и на ней не работает.

[mega1volt]

Порт управления не менял, а вот флаг TLS 1.3 hybridized Kyber support (Enabled) 100% вызывает проблему с удаленным доступом, тоже давно хотел об этом написать.

[Denis P]

31 минуту назад, mega1volt сказал:

вот флаг TLS 1.3 hybridized Kyber support (Enabled) 100% вызывает проблему с удаленным доступом

ничего подобного, проверено на 5 локациях, как с прямым так и облачным доступом.

флаг был специально изменен с default на enabled

Есть предположение что всё таки зависит от провайдера, магистрала, наличия ТС**...

Изменено 24 апреля пользователем Denis P

[dimon27254]

1 час назад, Denis P сказал:

Есть предположение что всё таки зависит от провайдера, магистрала, наличия ТС**...

Скорее всего, так оно и есть. Значит, дело и не в браузерах, и не в Кинетиках, а совсем в другом.
В моем случае, Кинетики выходят в интернет через Ростелеком и Дом.ру.

[Floppy_63Rus]

18 часов назад, dimon27254 сказал:

Скорее всего, так оно и есть. Значит, дело и не в браузерах, и не в Кинетиках, а совсем в другом.
В моем случае, Кинетики выходят в интернет через Ростелеком и Дом.ру.

Да, в точности такая же ситуация и как раз на этих двух провайдерах.
На остальных все ОК, как и было раньше.
Независимо от типа доступа.

Причем доступа нет даже если стучаться внутри сети одного провайдера.

Изменено 25 апреля пользователем Floppy_63Rus

[hellonow]

@dimon27254 https://www.reddit.com/r/sonicwall/comments/1cac4ii/content_filter_blocking_cfs_legitimate_traffic/

Хотя в версии 124.0.6367.92 браузера более описанная ситуация не воспроизводится.  

 

[dimon27254]

9 минут назад, hellonow сказал:

https://www.reddit.com/r/sonicwall/comments/1cac4ii/content_filter_blocking_cfs_legitimate_traffic/

Таким образом получается, что проблема в оборудовании фильтрации трафика, в моем случае установленном у интернет-провайдера.

3 минуты назад, hellonow сказал:

Хотя в версии 124.0.6367.92 браузера более описанная ситуация не воспроизводится.  

Обновил сейчас Chrome до этой версии, но ситуация не изменилась. Пока Kyber не выключить вручную через групповые политики или флаги - веб-интерфейс Кинетиков остается недоступен.

[Drafted]

Подтверждаю проблему. Версия Chrome 124.

В iOS Safari (17.4.1) и Firefox 123 (Win) все ок.

Проблема проявляется только при SSL подключении, по HTTP все работает.

Выключение TLS 1.3 hybridized Kyber support через флаги в Chrome вроде решает проблему.

Изменено 28 апреля пользователем Drafted

[hellonow]

@dimon27254 было принято решение создать кейс NDM-3284 на улучшение совместимости с TLS 1.3 hybridized Kyber, что позволит не отключать указанный флаг на стороне браузеров.

[dimon27254]

@hellonow проверил на трех Кинетиках с 4.2 Alpha 9 - доступ к веб-интерфейсу заработал без отключенного флага. Спасибо!

В ветку 4.1 планируется добавить это исправление?

[hellonow]

@dimon27254 да, версия готовится к выпуску, сначала в превью канале.