Jump to content

ankar84

Forum Members
 View Profile  See their activity

  • Posts

    407

  • Joined

  • Last visited

  • Days Won

    3

 Content Type 

Everything posted by ankar84

  1. ankar84
    Через ping.eu проверил 443 и 80 по вашему имени открыты. Возможно дело в IPv6. Попробуйте отключить, если используете.
  2. ankar84
    Очень странно. Прикладываю свой скрипт (там в самом начале и строка запуска показана)generate-domains-blacklist.py
  3. ankar84
    После обновления на 2.15.A.3.0-2 уже 2 дня проблему не наблюдаю. Время от времени захожу в админку роутера, пока всё работает как часы. Если что-то изменится, напишу.
  4. ankar84
    В итоге получилось почти так как вы указали, только добавил вывод таблицы nat, так как без этого наше правило не выводилось. #!/bin/sh [ "$type" == "ip6tables" ] && exit 0 [ "$table" != "nat" ] && exit 0 [ -z "$(iptables -nvL -t nat | grep "to:192.168.1.1:53")" ] && iptables -t nat -I PREROUTING -p udp --dport 53 -j DNAT --to-destination 192.168.1.1:53 exit 0 После перезагрузки проверил - правило на месте, ошибки разумеется нет.
  5. ankar84
    А может быть уже есть готовая реализация? А то я далек от баша и iptables.
  6. ankar84
    А у меня всё по прежнему, вывод с ошибкой. Пока вроде нечего не обновилось.
  7. ankar84
    Вот прямо в моменте и не доступно. Возможно это связано, с тем, что KeenDNS FQDN разрешается как в мой белый IPv4 адрес, так и в облачный IPv6 адрес KeenDNS. Хотя только что поставил и затем снял галочку Режим работы (IPv6) на странице Доменное Имя и это имя стало разрешаться только в мой реальный IPv4 адрес. Но веб так и не доступен. Селф ниже как обычно.
  8. ankar84
    Теперь понял где и что поправлено. Подожду штатного обновления, так как проблема не слишком критичная.
  9. ankar84
    Что-то не пойму, куда именно добавлен патч. Установил самый свежий драфт 2.15.A.3.0-1, в Entware сделал update&&upgrade, а ошибка осталась.
  10. ankar84
    Супер! Большое спасибо! Как сообщите, перейду на драфт и протестирую.
  11. ankar84
    Доброго дня! Имею проблему с недоступностью webui по зарегистрированному имени KeenDNS с автоматическим получением сертификата Let's Encrypt. Так же по этой проблеме создан тикет #400857 в официальную поддержку, где коллеги уточнили, что с текущим уровнем журналирования происходящего с KeenDNS и в целом webui сложно диагностировать мою проблему и попросили обратится к разработчикам тут, на форуме, чтобы те добавили расширенную диагностику работы webui в том числе и по KeenDNS FQDN. От себя добавлю, что было бы очень здорово, если бы эта расширенная диагностика была опциональной, а не обязательной. То есть выполняешь в CLI что-то типа set http.debug=1 и у тебя включается эта самая расширенная диагностика. В целом, считаю данную функцию очень нужной. Притом и самим разработчикам для более точной диагностики возникающих проблем. Прошу поддержать голосованием. Спасибо!
  12. ankar84
    Нужно проверить, работает ли приземление DNS запросов клиентов на роутер, например, командой ~ # iptables-save | grep " --dport 53 -j DNAT --to-destination 192.168.1.1" Can't find library for target `CONNNDMMARK' -A PREROUTING -p udp -m udp --dport 53 -j DNAT --to-destination 192.168.1.1:53 Так же с помощью tcpdump host IP_проверяемого_девайса посмотреть куда именно проходят запросы, на какой сервер.
  13. ankar84
    Обновился до релиза 2.14 и проблема резко обострилась. Даже после перезагрузки роутер не доступен по KeenDNS FQDN. Напомню, Запрос #400857 Селф будет ниже. Большая просьба @Le ecureuil обратить внимание. Спасибо!
  14. ankar84
    @vlad @rotor я сегодня обновился до 2.14 релиза и подтверждаю проблему со скриптом приземления всех DNS запросов на резолвер роутера: Дек 3 22:46:51 ndm Opkg::Manager: /opt/etc/ndm/netfilter.d/01-ClientDNS-Redirect.sh: Can't find library for target `CONNNDMMARK'. Взываю на помощь @Александр Рыжов и @Le ecureuil Каких-то библиотек не находит простой скрипт #!/bin/sh [ "$type" == "ip6tables" ] && exit 0 [ "$table" != "nat" ] && exit 0 [ -z "$(iptables-save | grep " --dport 53 -j DNAT --to-destination 192.168.1.1")" ] && iptables -t nat -I PREROUTING -p udp --dport 53 -j DNAT --to-destination 192.168.1.1:53 exit 0
  15. ankar84
    @Le ecureuil @eralde ок, если это by design, то тему, думаю, можно закрывать. Спасибо за объяснения.
  16. ankar84
    Действительно, начиная с версии 2.11.A.6.0-0 где явно указано, что защита от перебора https есть.
  17. ankar84
    Тоже считаю, что защищать http, но не защищать https, который keenetic os даёт из коробки (за что огромное спасибо, это большая работа) это весьма странно.
  18. ankar84
    @rotor, @vlad у себя в логах такой записи не вижу. Давайте "сверять время", а точнее окружение. У меня сейчас 2.13.C.0.0-3 на Giga (KN-1010), Entware обновлял последний раз где-то с месяц или чуть больше назад. # dnscrypt-proxy --version 2.0.16 # iptables --version iptables v1.4.21
  19. ankar84
    В общем, именно так реализовать вряд ли получится. Так как зону lib умеют разрешать ТОЛЬКО серверы проекта OpenNIC, то только у них и нужно спрашивать об этой зоне. Если использовать общий список серверов, который так же включает в себя серверы opennic, то разрешить узлы зоны lib скорее всего не получится, так как есть гораздо более быстрые серверы, которые и будут отвечать на ваши запросы, а они в свою очередь ничего не знают про зону lib. Поэтому решением в лоб будет использовать только серверы opennic (я именно так и делаю). Так же можно решить это проблему средствами dnsmasq (как вы и указали) или же средствами самого dnscrypt-proxy (я имею ввиду forwarding). Но в обоих случаях, насколько я понимаю, будут выполняться обычные dns запросы, а не dnscrypt шифрованные запросы.
  20. ankar84
    По сообщению коллег из технической поддержки, на их экземпляре смартфона моей модели никаких проблем с воспроизведением видео историй в Инстаргам с включенным блютузом нет, что на самом деле очень странно, так как в гостях были друзья с таким же смартфоном и проблема проявлялась стабильно. Но тем не менее, было решено, что это у меня с женой такие не удачные образцы смартфонов и проблемы как таковой нет. Да и у меня за все время решения данной проблемы теперь есть, как говорят заокеанские коллеги, workaround в виде выключения блютуза дома для супруги и использования только 5ГГц точки для меня. На этом тему можно считать закрытой, хоть и не решенной. Если кто-то все же столкнется с такой же или подобной проблемой на своем девайсе, желаю удачи?
  21. ankar84
    Сейчас по запросу ТП проверил воспроизведение проблемы по своему алгоритму на всех каналах 1-2-3-4-5-6-7-8-9-10-11-12-13 и абсолютно на всех были зависания более 5 секунд. Переключался на следующий тестируемый канал после того как "ловил" зависание секунд в 5-10. Кстати, начиная с 12 канала мой внешний адаптер Alfa AWUS036NH на роутбуке уже не мог подключиться к роутеру, поэтому с 12 на 13 канал пришлось менять на тестируемом смартфоне - Xiaomi Redmi Note 4X Snapdragon 4\64 через браузер. Так же еще по статистике данной проблемы, проверил лично у родственников на их роутере от Ростелекома Eltex NTU-RG-1402G-W - проблема воспроизводится. Ранее мне жена говорила, что не замечала на нем проблем. В посте со статистикой информация обновил.
  22. ankar84
    На самом деле это странный баг/фича. Всегда использовал шифрование ещё с времён дефолтного интерфейса transmission, наверное, на 2.06 и всё качало/раздавало. Даже было видно, что все соединения с замочком (шифрованы). А сейчас при включении обязательного шифрования transmission просто не качает. Имхо, так быть не должно.
  23. ankar84
    Сегодня у друга проверил по алгоритму на своем телефоне с роутером MikroTik hAP ac. Результат - проблемы нет. В общей пост информацию добавил.
  24. ankar84
    За все телефоны отвечать не могу, лично тестировал только Xiaomi Redmi Note 5,Samsung S8, Xiaomi Mi5 и Xiaomi Redmi 4X 4\64 с Xiaomi Redmi Note 4X Snapdragon 4\64 разумеется. Так же могу с уверенностью сказать, что на проблему не влияет ни канал, ни его ширина, ни опции (TX Burst, 256-QAM) ни мощность сигнала. Суть в том, что на проблемных девайсах просто при включении блютуза начинает плохо работать WiFi 2.4ГГц, но только от Гиги. Пока ни на одном другом роутере кроме Гиги это не проявилось, что говорит о том, что решение может быть со стороны роутера. И это более правильно, имхо.
  25. ankar84
    На данный момент собралась следующая статистика. Устройства на которых наблюдаются зависания при подключении к точке доступа 2.4ГГц интернет-центра Keenetic Giga (KN-1010) и включенном на телефоне Bluetooth Xiaomi Redmi 4X 4\64 Xiaomi Redmi Note 4X Snapdragon 4\64 Список роутеров, при подключении к которым проблемных девайсов из списка выше наблюдается не стабильная работа WiFi при включенном на телефоне Bluetooth Keenetic Giga (KN-1010) Eltex NTU-RG-1402G-W Список роутеров\точек доступа, при подключении к которым проблемных девайсов из списка выше проблем не наблюдается Zyxel Keenetic Ultra UniFi AP AC Pro MikroTik hAP ac Список проверенных девайсов, при подключении которых к точке доступа 2.4ГГц интернет-центра Keenetic Giga (KN-1010) и включенном на телефоне Bluetooth никаких проблем не наблюдается: Xiaomi Redmi Note 5 Xiaomi Mi5 Samsung S8 Neken N6 Xiaomi Redmi 4 Prime Xiaomi Redmi 3s Надеюсь пост будет обновляемым, если будет возможность редактировать это сообщение.
×
×
  • Create New...