mooq

О, вот спасибо за полезные инструкции. 1. Зашел посмотреть на Доменное имя. Ну, как и ожидалось: Сертификат не действителен. 2. Выполнил команды. Проблема решена! Спасибо вам большое. Теперь буду знать, как лечить подобное.

Ничего не пишет. Обновил стартовый пост.

Сегодня вдруг роутер стал недоступен по HTTPS. Не после обновления, после обновления на 5.1.1 я несколько раз заходил на него по HTTPS без проблем. Он вдруг стал недоступен сегодня, хотя никаких манипуляций с ним не производилось в последнее время. То есть, он сам вдруг решил отключить доступ по HTTPS. Как так? Перезагрузка роутера не помогает. Доступен только по HTTP. А по HTTPS браузер показывает ошибку ERR_CONNECTION_CLOSED. В логе роутер ничего не пишет. Я лог очистил и при всех моих попытках подключения к роутеру в логе ни одной записи не появилось. Тест с помощью curl выдал такое: * IPv6: (none) * IPv4: 192.168.1.1 * HTTPS-RR: - * Trying 192.168.1.1:443... * ALPN: curl offers h2,http/1.1 * TLSv1.3 (OUT), TLS handshake, Client hello (1): * SSL Trust Anchors: * Native: Windows System Stores ROOT+CA * TLS connect error: error:00000000:lib(0):func(0):reason(0) * LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to 192.168.1.1:443 * closing connection #0 curl: (35) TLS connect error: error:00000000:lib(0):func(0):reason(0) Предположение: Может, роутер свой TLS сертификат обновляет со своего сайта? И вот он его обновил, и в результате у него в качестве сертификата лежит какая-то хрень. Потому-то браузеры и иные SSL клиенты не могут эту хрень нормально прочитать. В настройках обновления роутер пишет: "Соединение с сервером обновлений..." Не может соединиться. Какой вообще адрес у этого сервера обновлений? Я хоть браузером посмотрю, не угрожает ли этот сервер обновлений суверенитету России и ее духовным скрепам. PS: Проблема решена. Но жаль, что никто так и не сообщил адрес, на который стучится роутер за обновлениями. Чтобы его доступность хоть вручную посмотреть было можно.

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

Не, определять, какой домен должен идти по маршруту, а какой нет, путем текстового сравнения суффикса (x.com и yandex.com) - это, ребята, просто жопа. Да детсадовец может поправить ваш текстовый парсер доменов, чтобы он именно на домены строку разбивал, а не тупо по окончанию строки определял: подходит/не подходит. Вообще-то, ваша реализация - это какой-то позор.

Тоже сейчас проверил. Да, проблема ушла. Это хорошо.

Ну, попробуйте подолбить здесь разрабов, почему они не пошли путем использования dnsmasq. Если будете настойчиво долбить, может, кто из них и снизойдет для того, чтобы ответить на этот вопрос путем: "Пшол на йух!" Я вот не разбираюсь в этом и потому не знаю, является ли dnsmasq решением всех озвученных здесь проблем с DNS маршрутизацией, но сам бы с удовольствием послушал ответ разрабов. Но подозреваю, что ответ, если он вообще будет, то будет в виде, озвученном выше.

Посмотрю у себя как-нибудь. Наверное, уже после Beta 5.

Добавлю от себя. Если в одном из уровней есть пустая запись, как в данном случае: dsca.akamaiedge.net, то процесс построения маршрутов для записи, судя по всему, падает с ошибкой, и домен e10988.dsca.akamaiedge.net так же не добавляется. С таким тоже сталкивался. Но кроме того, наблюдал такое: domain1.net = 1.1.2.3 (некий IP) sub1.domain1.net = 2.1.2.3 (IP из другой подсети, никак не связанной с предыдущей) Если добавить в список DNS маршрутизации только domain1.net, а sub1.domain1.net не добавить (ибо ожидаем, что раз домен верхнего уровня есть в списке, то все его поддомены тоже будут маршрутизироваться по этому правилу), то трафик на sub1.domain1.net маршрутизироваться по правилу списка не будет. Приходится специально в список добавлять еще и sub1.domain1.net, чтобы трафик на него маршрутизировался. Но мы ожидаем, что такое добавление излишне, ведь в списке уже есть домен более высокого уровня, и потому все его поддомены должны подпадать под данное правило маршрутизации. Но нет, по факту они не подпадают.

Согласен со slayy. Я вот тоже воспринимаю эти иконки "со стороны роутера". Мы ж с роутером работаем, а не с компом. Мне, впрочем, не мешает, и так и так сойдет, но если вдруг выбирать, то я бы тоже их местами поменял.

У меня этот набор уже обошелся на 200 routes больше. А если кроме этого набора добавить еще другие вещи, то будет еще больше. В общем, безотносительно наших особенностей национальной сети, будет неплохо, если гномы-прошивкостаратели пофиксят проблему работы с большим количеством routes.

Возможно. Я портянку брал с известного сайта, там только на один утуб 700+ routes. Соответственно, если добавить кроме него еще нужные вещи, то получается... вот столько и получается. Возможно, можно как-то сократить - что-то объединить. Но в любом случае, маршрутов будет 2000+.

Я уже на эту страницу заходить боюсь. Зайдешь и попадешь в бесконечный круг "Время сессии истекло, авторизирйтесь - Время сессии истекло, авторизирйтесь - Время..." и не выйдешь из него. Да и не понятно, как при этом посмотреть на загрузку CPU, если во время генерации страницы с routes никуда больше зайти нельзя. Впрочем, не думаю, что знание того, насколько загружен в этот момент CPU, как-то поможет. Чем оно может помочь? К сожалению, мне, как родившемуся русским, высшие силы диктуют необходимость задать 3800 routes. Родился бы американцем, не знал бы такой проблемы.

Версия: 5.1 beta 1. Заходим на страницу "Сетевые правила/Маршрутизация/Маршруты IPv4" ( /staticRoutes/ipv4 ). 2. Задаем много маршрутов: например, 4000 маршрутов. 3. Чем больше маршрутов задано, тем больше страница тормозит. При очень большом количестве маршрутов (примерно 3500) наступает такой момент, что время отображения страницы начинает превышать время сессии работы в web-интерфейсе. То есть, юзер получает сообщение "Время сессии истекло, авторизируйтесь еще раз". 4. Юзер переходит на страницу логина, еще раз заходит, но после логина происходит переадресация на последнюю страницу, с которой юзер работал, то есть на /staticRoutes/ipv4. В результате эта страница опять пытается открыться, web-сервер долго не отвечает, и в конце опять "Время сессии истекло, авторизируйтесь еще раз". И так по кругу. Надо бы как-то сделать возможной работу со списком routes, когда их задано много. Даже со списком, где всего 900 routes, страница уже настолько тормозит, что браузер показывает сообщение "Страница не отвечает". При загрузке страницы /staticRoutes/ipv4 CPU, по моим наблюдениям, загружен примерно на 4-5%, с пиком 9%.