Jump to content

Le ecureuil

Forum Members
 View Profile  See their activity

  • Posts

    9,486

  • Joined

  • Last visited

  • Days Won

    544

 Content Type 

Posts posted by Le ecureuil

    Internet safety -> service - исчез пункт yandex dns и язык - только анг Installed version 3.7.4 keenetic start

    in Обсуждение IPsec, OpenVPN и других туннелей

    Posted

    Впрочем если GeoIP верны, то у вас скорее всего переключился регион с RU на UA. В UA недоступен Yandex.DNS, поскольку он заблокирован. Русский язык можно вернуть через установку компонента с языком.

    Internet safety -> service - исчез пункт yandex dns и язык - только анг Installed version 3.7.4 keenetic start

    in Обсуждение IPsec, OpenVPN и других туннелей

    Posted

    28 минут назад, ustas1 сказал:

    Internet safety  -> service - исчез пункт yandex dns  и язык - только анг  Installed version   3.7.4  keenetic start
    как получить  service - yandex dns  ?

    Покажите self-test.

    Совместное использование ndhcps и dnsmasq ?

    in Вопросы по сборке и настройке Opkg

    Posted

    2 часа назад, ale_xb сказал:

    -Так и сделано

    - Настроено

    - Чтобы заработал dnsmasq прошивочный DNS отключается специальной командой в CLI KeeneticOS opkg dns-override. Насколько я понял, эта команда просто убирает прослушку 53-го порта прошивочным ndhcps, чтобы не конфликтовать с dnsmasq. Собственно ndhcps в запущенных процессах остается, т.к. он же продолжает работать в качестве DHCP, поэтому и появилаcь мысль из п.3, но каких-либо файлов настроек для ndhcps я не обнаружил, параметры его запуска весьма скудны (для смены порта ничего нет), и даже, где/как на это повлиять я тоже не знаю.

    Если это поможет, добавлю подробностей. Началось вот с этого https://habr.com/ru/post/428992/ При этом используется (там же в комментариях) встроенный в KeeneticOS механизм прокси DNS (для DoT/DoH в частности). Спустя небольшое время, я обнаружил, что у меня перестали разрешаться имена в домашней локалке и рабочей (через openvpn) сети. При этом средствами/командами KeeneticOS я вижу, что встроенный ndhcps успешно регистрирует имена хостов в моей домашней сети при общении с ними по DHCP. Теперь пытаюсь решить проблему, как эту инфо сообщить dnsmasq-у. Если я правильно понял, то, следует как-то разруливать DNS запросы через dns-proxy KeeneticOS (есть подозрение, что он работает/настраивается, к сожалению, только для DoT/DoH) к а) прошивочному ndhcps для домена домашней сети (при этом его надо заставить слушать на отличном от 53 порту), б) к NDS серверам, прилетающим через openvpn для домена рабочей сети, в) к DoT/DoH - для всех остальных. Осталось все это правильно настроить,  если такое возможно 🙂

    Совсем тупой вариант, но в целом рабочий - это по вызову neighbour.d с action == update_dhcp получать из ndmq список dhcp-лизов через 'show ip dhcp bindings', засовывать в dnsmasq и слать ему сигнал на перечитывание конфига.

    Request: Selecting DNS protocol in NextDNS

    in Feature Requests

    Posted

    В 04.04.2022 в 01:47, Delka сказал:

    If you dont want to use only DoT - then okay, dont fuck with the settings. If i want to use only DoT -  there is nothing i could do rn.

    As you can see, NextDNS gives us separate DNS addresses, leaving the choice of which DNS protocol we want to use. But we cant choose that with this new NextDNS update - internet safety, filtering tab.

    Besides, i can use which DNS protocol I want with DDNS and DoT or DoH settings, without this "NextDNS update".

    If I "DONT WANT TO" use DoH, i just enable DoT from system components, entering my NextDNS DoT address and i use only DoT.

    So whats the point of "NextDNS update" and "Internet Safety - filtering tab" if i cant decide to which DNS protocol i will use? Is it just to remove the DDNS requirement? I was able to choose the DNS protocol as I my ass wanted even before this update.

    "You can't choose the DNS protocol you want, but I've saved you the hassle of using DDNS." Is that all?

    I still can't see any reasonable point for choosing DoT over DoH.

    Will disclosure some facts behind implementation. We discussed protocols selection and fallback with NextDNS team and they advised us to stuck on DoH only, as it provides best possible service over others with neglectible expense. That's the point from authors of the NextDNS, and I totally agree with them. Yes, they support many other protocols, but as legacy fallback with degradation of service quality.

    So I will ask you again: is there any reasonable point for DoT over DoH?

    • Thanks 2

    Request: Selecting DNS protocol in NextDNS

    in Feature Requests

    Posted

    8 часов назад, Delka сказал:

    As you can see (Screenshot 6) there is DoH and DoT address, im on developer channel on Keenetic and im using NextDNS configuration. My connections are always on "DoH" (screenshot 7). I don't want to use DoH, i just want to use DoT. I think it would be great if there was a menu where I could set this (like example on screenshot 8).

    Screenshot_6.png

    Screenshot_7.png

    Screenshot_8.png

    "Don't want" is not a valid reason. I don't want on the other hand, so what?

    Will any real considerations appear?

    K3, VOX, DSL, LTE на 2.16 - в канале draft

    in 2.16 [legacy]

    Posted

    19 минут назад, vmaloy86 сказал:

    Здравствуйте, обновил свои работающие без проблем Zyxel Keenetic Viva 2.14.C.0.0-4 на 2.16.D.12.0-5, появилась аналогичная проблема в IP-IP туннелях ("расшарено" подключение максимально тарифа внутри сети одного провайдера), точно так же не грузятся некоторые сайты.

    Подскажите,пожалуйста, где и как править MTU

    interface IPIPX mtu 1250

    SSH-соединение с public интерфейса при явном запрете

    in Обмен опытом

    Posted

    53 минуты назад, t800 сказал:

    Спасибо за ответ. Но хочу пояснить почему вообще возник мой вопрос. Я предполагал, что ACL имеет наивысший приоритет только для сетевых интерфейсов. Ssh-сервер, всё-таки, это служба, пусть и имеющая настройку security-level. Поэтому, разрешив входящий трафик из Wireguard0, я ожидал, что ssh-сервер не пустит входящий коннект от public-интерфейса, раз это явно запрещено. Исходя из вашего объяснения, получается, что ssh-сервер имеет тот же подход в работе уровней безопасности, что и сетевые интерфейсы. Это всё объясняет, но было бы неплохо в какой-то форме отразить это в документации. Допускаю, что я один такой тугой, но всё-таки служба <> интерфейс, отсюда и вопросы.

    Для простоты считайте что настройка security-level - это такой автоматический фаервол для службы, который работает сразу на всех интерфейсах. Тогда будет в разы понятнее, почему службы и интерфейсы не разделяются как таковые.

    SSH-соединение с public интерфейса при явном запрете

    in Обмен опытом

    Posted

    17 часов назад, t800 сказал:

    Отправил в запрос. 

    Виноват, обычно вполне внятно изъясняюсь. Попробую еще раз:

    1. Есть два кинетика - Giga и Giga-III, между ними поднят Wireguard-тоннель, имя интерфейса на обоих - Wireguard0

    2. На Giga-III Wireguard0 имеет уровень public. 

    3. Подключения с хостов в домашней сети Giga 192.168.1.0/24 по ssh к Giga-III проходят успешно. На мой взгляд это неверно, потому на Giga-III настроено  

    ip ssh
security-level private

    Я понимаю это так, что ssh-сервер должен принимать входящие соединения только с интерфейсов с уровнем private. Таким образом, с Wireguard0 ssh-соединения в текущей конфигурации проходить не должны. Но они проходят, и я хотел бы разобраться в причинах.

    Да, теперь из self-test я все понял.

    Вы сами разрешили эти соединения, задав в ACL:

        permit ip 192.168.1.0 255.255.255.0 0.0.0.0 0.0.0.0

    Дословно это означает: "разрешить из 192.168.1.0/24 на любое назначение".

    Судя по всему, у вас в Wireguard0 проходят SSH запросы с источником 192.168.1.0/24 и назначением 10.0.0.2, что вполне подходит под условие и коннект разрешается.

    И да, ACL имеет высший приоритет, чем security-level, потому все, что явно разрешено или запрещено в ACL будет работать именно так.

    Если не нужен доступ по SSH, закройте его явно первым правилом в ACL:

     deny tcp 192.168.1.0 255.255.255.255 0.0.0.0 0.0.0.0 port eq 22

    SSH-соединение с public интерфейса при явном запрете

    in Обмен опытом

    Posted

    18 минут назад, t800 сказал:

    Не отправлял, только куски конфигурации. Но инженер поддержки и не просил, с его точки зрения всё очевидно, а я неправ в своих ожиданиях. Посмотрите - запрос № 578948

    Пришлите туда пожалуйста. Пока вообще ничего непонятно из вашего описания, потому без технических подробностей не хочу обсуждать что там происходит.

    Компонент qBittorrent

    in 2.16 [legacy]

    Posted

    7 часов назад, Rootdiv сказал:

    Значит влезет не всем. Жаль.

    Разумеется, это было ожидаемо. В основном он для NAND-flash, там места везде с запасом.

    • Thanks 1
×
×
  • Create New...