Перейти к содержанию

Вопрос

Опубликовано

Хотелось бы понять логику работы DoT/DoH и взаимодействие с name-server.

Пробуем прописать, при включенном opkg dns-override и полном отсутствии ydns/adguard/...:

(config)> dns-proxy tls upstream 1.1.1.1 sni cloudflare-dns.com
Dns::Secure::ManagerDot: DNS-over-TLS name server "1.1.1.1" is disregarded while Internet Filter is active.

Т.е. как я понимаю, для резолва запросов самим роутером (RPC) DoT/DoH использовать нельзя, они будут ходить напрямую? (использовать name-server только для необходимых резолвов для DoH, и затем переходить полностью на DoH/DoT)

Как можно диагностировать работу DoT/DoH?

Рекомендуемые сообщения

  • 0
Опубликовано

Пару дней "чудил" интернет, не резолвились домены и, как результат, Chrome не отображал, Steam ругался на оффлайн режим и тд. Проблема проявлялась через минут 5 после загрузки роутера (половина программ на телефонах переставала работать, на компьютере Стим), при этом nslookup на удивление работал. Стоит DoH и DoT, для блокировки транзитного трафика стоял AdGuard DNS с профилем по умолчанию "Без фильтрации". Прошивка 3.3.16, пробовал ещё 3.4 Alpha 15.

Проблема оказалась в AdGuard, сначала убрал интернет фильтр, потом поставил Яндекс "Без фильтрации" - проблема пропала.

  • 0
Опубликовано
2 часа назад, Alex M. Jake сказал:

для блокировки транзитного трафика стоял AdGuard DNS с профилем по умолчанию "Без фильтрации"

К сожалению это так не работает. Если выбрано "Без фильтрации" применяются установленные вами DoH/DoT сервера, но никакие транзитные при этом не ловятся. Они ловятся только в случае когда выбран какой-то из режимов фильтрации для того чтоб никто мимо не убежал. 

  • 0
Опубликовано
5 hours ago, keenet07 said:

К сожалению это так не работает. Если выбрано "Без фильтрации" применяются установленные вами DoH/DoT сервера, но никакие транзитные при этом не ловятся. Они ловятся только в случае когда выбран какой-то из режимов фильтрации для того чтоб никто мимо не убежал. 

 

  • 0
Опубликовано
5 минут назад, Alex M. Jake сказал:

 

Да. Год назад я так и считал, так же почитав форум. Позже программисты подсказали, что это не совсем так.

6 минут назад, Alex M. Jake сказал:

Да и не в этом вопрос. Вопрос почему при DoH/DoT и AdGuard "Без фильтрации" перестали резолвится имена?

А в дох/дот у вас какие сервера прописаны? У меня к примеру при использовании только серверов cloudflare периодически возникают подтупливания при открытии страниц. А если добавляю дополнительно сервер от гугла, всё становится нормально. Чем больше всяких разных серверов добавлено, тем стабильнее по идее должно работать. Запрос отправляется на все сразу, а ответ используется от того кто вперед ответит.

  • 0
Опубликовано
57 minutes ago, keenet07 said:

А в дох/дот у вас какие сервера прописаны?

dns-proxy
    tls upstream 8.8.8.8 sni dns.google.com
    tls upstream 8.8.4.4 sni dns.google.com
    tls upstream 1.1.1.1 sni cloudflare-dns.com
    tls upstream 1.0.0.1 sni cloudflare-dns.com
    tls upstream 9.9.9.9 sni dns.quad9.net
    https upstream https://cloudflare-dns.com/dns-query json
    https upstream https://dns.google/dns-query dnsm
    https upstream https://dns.google/resolve json

 

58 minutes ago, keenet07 said:

У меня к примеру при использовании только серверов cloudflare периодически возникают подтупливания при открытии страниц.

У меня не подтупливает, а сразу отлуп о неразрезолвенном имени.

  • 0
Опубликовано

Техподдержка предположила, что DoH фильтруется провайдером (Дом.ру, будь он неладен, их уже не раз ловили на играх с DNS серверами и запросами).

Оставил только DoT, тестирую....

  • 0
Опубликовано

Подскажите, постоянно в журнале ошибка 

Цитата
Май 4 21:27:02

 

https-dns-proxy
TLS certificate verify error: Error

Ставил по инструкции через CLI, один в один как в шапке. С чем может быть связана проблема?

  • 0
Опубликовано (изменено)
1 час назад, Alexei сказал:

Подскажите, постоянно в журнале ошибка 

Ставил по инструкции через CLI, один в один как в шапке. С чем может быть связана проблема?

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

Изменено пользователем keenet07
  • 0
Опубликовано
4 минуты назад, keenet07 сказал:

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

Да, спасибо. Решил не париться, удалил DoH и оставил только DoT. В журнале чисто. 

  • 0
Опубликовано
[W] May  4 20:11:00 https-dns-proxy: Unknown rrtype 'TLSA'
[W] May  4 20:11:00 kernel: do_page_fault(): sending SIGSEGV to https_dns_proxy for invalid read access from 00000000
[W] May  4 20:11:00 kernel: epc = 77a02418 in libuClibc-1.0.32.so[779b3000+b6000]
[W] May  4 20:11:00 kernel: ra  = 77a01fd4 in libuClibc-1.0.32.so[779b3000+b6000]
[E] May  4 20:11:00 ndm: Service: "DoH "Policy1" proxy #0": unexpectedly stopped.
[W] May  4 20:11:01 https-dns-proxy: Unknown rrtype 'TLSA'
[W] May  4 20:11:01 kernel: do_page_fault(): sending SIGSEGV to https_dns_proxy for invalid read access from 00000000
[W] May  4 20:11:01 kernel: epc = 77e76418 in libuClibc-1.0.32.so[77e27000+b6000]
[W] May  4 20:11:01 kernel: ra  = 77e75fd4 in libuClibc-1.0.32.so[77e27000+b6000]
[E] May  4 20:11:01 ndm: Service: "DoH "Policy1" proxy #1": unexpectedly stopped.

Периодически в логе вижу такие записи, кажется что их не должно быть. Через пару секунд после них сообщения о том что https-dns-proxy подялись. С этим в поддержку или здесь смогут помочь?

  • 0
Опубликовано
13 часа назад, keenet07 сказал:

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

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

  • 0
Опубликовано
13 часа назад, Alexander Kudrevatykh сказал:

[W] May  4 20:11:00 https-dns-proxy: Unknown rrtype 'TLSA'
[W] May  4 20:11:00 kernel: do_page_fault(): sending SIGSEGV to https_dns_proxy for invalid read access from 00000000
[W] May  4 20:11:00 kernel: epc = 77a02418 in libuClibc-1.0.32.so[779b3000+b6000]
[W] May  4 20:11:00 kernel: ra  = 77a01fd4 in libuClibc-1.0.32.so[779b3000+b6000]
[E] May  4 20:11:00 ndm: Service: "DoH "Policy1" proxy #0": unexpectedly stopped.
[W] May  4 20:11:01 https-dns-proxy: Unknown rrtype 'TLSA'
[W] May  4 20:11:01 kernel: do_page_fault(): sending SIGSEGV to https_dns_proxy for invalid read access from 00000000
[W] May  4 20:11:01 kernel: epc = 77e76418 in libuClibc-1.0.32.so[77e27000+b6000]
[W] May  4 20:11:01 kernel: ra  = 77e75fd4 in libuClibc-1.0.32.so[77e27000+b6000]
[E] May  4 20:11:01 ndm: Service: "DoH "Policy1" proxy #1": unexpectedly stopped.

Периодически в логе вижу такие записи, кажется что их не должно быть. Через пару секунд после них сообщения о том что https-dns-proxy подялись. С этим в поддержку или здесь смогут помочь?

Могут, я посмотрю.

  • 0
Опубликовано
23 часа назад, Alexander Kudrevatykh сказал:

[W] May  4 20:11:00 https-dns-proxy: Unknown rrtype 'TLSA'
[W] May  4 20:11:00 kernel: do_page_fault(): sending SIGSEGV to https_dns_proxy for invalid read access from 00000000
[W] May  4 20:11:00 kernel: epc = 77a02418 in libuClibc-1.0.32.so[779b3000+b6000]
[W] May  4 20:11:00 kernel: ra  = 77a01fd4 in libuClibc-1.0.32.so[779b3000+b6000]
[E] May  4 20:11:00 ndm: Service: "DoH "Policy1" proxy #0": unexpectedly stopped.
[W] May  4 20:11:01 https-dns-proxy: Unknown rrtype 'TLSA'
[W] May  4 20:11:01 kernel: do_page_fault(): sending SIGSEGV to https_dns_proxy for invalid read access from 00000000
[W] May  4 20:11:01 kernel: epc = 77e76418 in libuClibc-1.0.32.so[77e27000+b6000]
[W] May  4 20:11:01 kernel: ra  = 77e75fd4 in libuClibc-1.0.32.so[77e27000+b6000]
[E] May  4 20:11:01 ndm: Service: "DoH "Policy1" proxy #1": unexpectedly stopped.

Периодически в логе вижу такие записи, кажется что их не должно быть. Через пару секунд после них сообщения о том что https-dns-proxy подялись. С этим в поддержку или здесь смогут помочь?

Вроде поправил, но падение так и не смог воспроизвести.

Нельзя ли снять дамп dns-запросов на LAN-интерфейсе в этот момент?

  • 0
Опубликовано
On 5/5/2020 at 8:30 PM, Le ecureuil said:

Вроде поправил, но падение так и не смог воспроизвести.

Нельзя ли снять дамп dns-запросов на LAN-интерфейсе в этот момент?

Запустил tcpdump но за сутки падение не воспроизвелось, если получится воспроизвести - напишу.

  • 0
Опубликовано

Прописал 7 серверов DoT и  2 DoH.

(config)> show dns-proxy

     proxy-status:
              proxy-name: System

            proxy-config:

rpc_port = 54321
rpc_ttl = 10000
rpc_wait = 10000
timeout = 7000
proceed = 500
stat_file = /var/ndnproxymain.stat
stat_time = 10000
dns_server = 127.0.0.1:40500 .
dns_server = 127.0.0.1:40501 .
dns_server = 127.0.0.1:40502 .
dns_server = 127.0.0.1:40503 .
dns_server = 127.0.0.1:40504 .
dns_server = 127.0.0.1:40505 .
dns_server = 127.0.0.1:40506 .
dns_server = 127.0.0.1:40508 .
dns_server = 127.0.0.1:40509 .
static_a = my.keenetic.net 78.47.125.180
static_a = aedb814b5517802488eb4160.keenetic.io 78.47.125.180
set-profile-ip 127.0.0.1 0
set-profile-ip ::1 0
dns_tcp_port = 53
dns_udp_port = 53

Смущают две последних строки. Фильтры отключены.

  • 0
Опубликовано (изменено)
12 минуты назад, sng сказал:

dns_tcp_port = 53
dns_udp_port = 53

Смущают две последних строки. Фильтры отключены.

А чем смущают? У вас же активирован DoH, а он в качестве бутстрапа использует обращения к нескольким обычным DNS серверам по 53 порту для собственного функционирования.

Все пользовательские запросы идут защищенными каналами.

Но, если оставить только DoT то и этих двух строк не будет. Компонент DoH правда для этого нужно полностью удалить.

Изменено пользователем keenet07
  • 0
Опубликовано
3 часа назад, sng сказал:

Прописал 7 серверов DoT и  2 DoH.

(config)> show dns-proxy

     proxy-status:
              proxy-name: System

            proxy-config:

rpc_port = 54321
rpc_ttl = 10000
rpc_wait = 10000
timeout = 7000
proceed = 500
stat_file = /var/ndnproxymain.stat
stat_time = 10000
dns_server = 127.0.0.1:40500 .
dns_server = 127.0.0.1:40501 .
dns_server = 127.0.0.1:40502 .
dns_server = 127.0.0.1:40503 .
dns_server = 127.0.0.1:40504 .
dns_server = 127.0.0.1:40505 .
dns_server = 127.0.0.1:40506 .
dns_server = 127.0.0.1:40508 .
dns_server = 127.0.0.1:40509 .
static_a = my.keenetic.net 78.47.125.180
static_a = aedb814b5517802488eb4160.keenetic.io 78.47.125.180
set-profile-ip 127.0.0.1 0
set-profile-ip ::1 0
dns_tcp_port = 53
dns_udp_port = 53

Смущают две последних строки. Фильтры отключены.

Эти строки определяют порт сервера, на котором он работает. Логично, что из LAN он будет доступен по обычному plaintext - варианту.

  • 0
Опубликовано (изменено)

Оставил только DoT через  AdGuard DNS без фильтрации.

Периодически  появляется вместо  1-2х серверов

DNS leak test

Test complete

Query round    Progress...    Servers found
1        ......        4
2        ......        1
3        ......        4
4        ......        6
5        ......        5
6        ......        6

IP     Hostname     ISP     Country
162.158.180.91     None     Cloudflare     United States
74.125.112.1     None     Google     Finland
74.125.112.11     None     Google     Finland
74.125.112.2     None     Google     Finland
74.125.112.4     None     Google     Finland
74.125.112.9     None     Google     Finland
74.125.46.131     None     Google     Lappeenranta, Finland
74.125.46.132     None     Google     Lappeenranta, Finland
74.125.46.135     None     Google     Lappeenranta, Finland
74.125.46.140     None     Google     Lappeenranta, Finland
74.125.74.1     None     Google     Lappeenranta, Finland
74.125.74.13     None     Google     Lappeenranta, Finland
74.125.74.131     None     Google     Lappeenranta, Finland
74.125.74.136     None     Google     Lappeenranta, Finland
74.125.74.139     None     Google     Lappeenranta, Finland
74.125.74.141     None     Google     Lappeenranta, Finland
74.125.74.5     None     Google     Lappeenranta, Finland
74.125.74.7     None     Google     Lappeenranta, Finland
74.125.74.9     None     Google     Lappeenranta, Finland

Как от финов избавиться?

 

Изменено пользователем sng
  • 0
Опубликовано (изменено)
5 часов назад, sng сказал:

Оставил только DoT через  AdGuard DNS без фильтрации

Как от финов избавиться?

 

Сам себе и отвечаю...

Эти фины от серверов DoT/DoH Гугла.  :)

Изменено пользователем sng
  • 0
Опубликовано

@Le ecureuil,

KeeneticOS 3.4.1

при настройке DoT/DoH (cloudflare google.dns) происходят рандомные отвалы раз в сутки с последующим перезапуском: 

[I] May 23 06:56:39 ndhcpc: GigabitEthernet1: received ACK for 95.xx from 85.xx.
[E] May 23 06:57:56 ndm: Service: "DoT "System" UDP-to-TCP proxy #1": unexpectedly stopped.
[I] May 23 07:01:40 ndhcpc: GigabitEthernet1: received ACK for 95.xx from 85.xx.
[I] May 23 07:11:40 ndhcpc: Core::Syslog: last message repeated 2 times.
[I] May 25 03:22:14 ndhcpc: GigabitEthernet1: received ACK for 95.xx from 85.xx.
[I] May 25 03:37:15 ndhcpc: Core::Syslog: last message repeated 3 times.
[E] May 25 03:41:45 ndm: Service: "DoT "System" UDP-to-TCP proxy #1": unexpectedly stopped.
[I] May 25 03:42:15 ndhcpc: GigabitEthernet1: received ACK for 95.xx from 85.xx.
[I] May 25 03:52:16 ndhcpc: Core::Syslog: last message repeated 2 times.

настройка проводится после полного сброса устр-ва, остальные настройки выставлены по-дефолту. 

как лечить?

  • 0
Опубликовано
23 часа назад, cheburashkaDNS сказал:

@Le ecureuil, я бы и не обращал если бы при этом не пропадало интернет соединение. продолжительность сессии не сбрасывается, но связь пропадает на это время.

Надолго пропадает?

  • 0
Опубликовано (изменено)

@Le ecureuil, смотрите, я изначально настроил шифрование по протоколу dns-over-https на dns.google и заметил что спорадически раз в сутки стало пропадать интернет-соединение, в журнале в этот момент было сообщение о перезапуске службы, сменил на cloudflare история повторилась. пропадает ровно на время между двумя событиями: остановкой службы и поднятием соединения GigabitEthernet1, по логам можете посмотреть. при этом как уже говорил ресурсы не открываются, а в системном мониторе значится "без доступа в интернет", после возобновления продожительность сессии не сбрасывается. в один момент также я смотрел онлайн потоковый стрим на youtube, когда произошла потеря соединения ни один ресурс не открывался, но при этом сам стрим продолжался в течении нескольких минут до нормализации и это был прямой эфир не предзагруженный в кэш сегмент. сейчас настроил DoT на dns.google и cloudlare пока вторые сутки все нормально, один раз в логе был скоротечный перезапуск но я был оффлайн. 

Изменено пользователем cheburashkaDNS
  • 0
Опубликовано

и такой вопрос
в активных соединениях обнаружил вот таких два чучундрика:

848591941_2020-05-27161615.thumb.jpg.2431dfa74838f1fa24bf83a396cda883.jpg

первый вроде имеет отношение к KeenDNS (хотя я его не настраивал) 
второй какой-то проктор энд гэмбл немецкий http://your-server.de/ 

нормальная активность?

  • 0
Опубликовано

да, вы абсолютно правы. отключил - пропало.

я так понимаю для полного удаления KeenDNS нужно удалить компонент "Агент облачной службы Keenetic Cloud и KeenDNS" и тогда запросы по порту UDP/4044 прекратятся?

Присоединяйтесь к обсуждению

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

Гость
Ответить на вопрос...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

  • Последние посетители   0 пользователей онлайн

    • Ни одного зарегистрированного пользователя не просматривает данную страницу
×
×
  • Создать...

Важная информация

На этом сайте используются файлы cookie. Нажимая "Я принимаю" или продолжая просмотр сайта, вы разрешаете их использование: Политика конфиденциальности.