LinuxMint.com.ru

Linux mint x64 cinnamon 20.2

При использовании впн совершенно дичайшим образом течет dns.
Кто-нибудь знает, как исправить?

FliXis писал(а): ↑
26 июл 2021, 20:30
Кто-нибудь знает, как исправить?

На хабре подымался вопрос
https://habr.com/ru/post/353878/

hellonet писал(а): ↑
27 июл 2021, 07:17
На хабре подымался вопрос

Но тут нет ничего про починку нетворк менеджера, в который каждые несколько лет наверняка нарочно добавляют эту ошибку. Насколько помню, после включения впн днс не резолвится на впн-ский.
В статье говорится про то, что неплохо использовать другой днс, но мол в идеале надо использовать vpn. Я уже использую впн, но рашкинский днс утекает из-за бага в нетворк менеджере.
Удивительно, что практически всем глубоко по барабану на подобную проблему, это в наши то времена, когда впн юзают очень многие.

FliXis писал(а): ↑
30 июл 2021, 17:27
Но тут нет ничего про починку нетворк менеджера, в который каждые несколько лет наверняка нарочно добавляют эту ошибку.

Да, это заговор. Прямо чтобы за вами лично следить.

FliXis писал(а): ↑
30 июл 2021, 17:27
Я уже использую впн, но рашкинский днс утекает из-за бага в нетворк менеджере.

Это не баг. Во всяком случае не в NM. Это кривые руки. У тех кто настраивал сервер VPN, или у вас лично.

FliXis писал(а): ↑
30 июл 2021, 17:27
Удивительно, что практически всем глубоко по барабану на подобную проблему, это в наши то времена, когда впн юзают очень многие.

Либо удосужитесь как следует изучить вопрос: "Как устроена сеть вообще, и DNS в частности?", либо просто поверьте словам специалиста: вы не там ошибку ищете. DNS "течь" не может по определению - там не подразумевается вариант "туда ходи, туда не ходи" своими средствами. Наоборот, в реализации DNS ресолверов изначально закладываются механизмы компенсации разрыва связности - резервные адреса серверов вплоть до обращения к корневым в крайнем случае. Если есть такое дикое желание "заблочить все обычное DNS" это делается через firewall - исходящие запросы на 53-й порт TCP и UDP протоколов. С исключением для IP "доверенных серверов".
А NM, кстати, вообще не является ресолвером DNS. В минте им работает systemd-resolvd.

slant писал(а): ↑
30 июл 2021, 18:52
Да, это заговор. Прямо чтобы за вами лично следить.

Регулярно ломать это дело от релиза к релизу, как минимум подозрительно.

slant писал(а): ↑
30 июл 2021, 18:52
Это не баг. Во всяком случае не в NM. Это кривые руки. У тех кто настраивал сервер VPN, или у вас лично.

Нет, именно баг. Если начать искать про утечку dns на ubunte/mint, то все жалуются именно на NM.

slant писал(а): ↑
30 июл 2021, 18:52
А NM, кстати, вообще не является ресолвером DNS. В минте им работает systemd-resolvd.

Значит трабла в нем, но мне без разницы, где именно, мне надо чтобы работало.

slant писал(а): ↑
30 июл 2021, 18:52
DNS "течь" не может по определению

Сомнительное заявление. Я проверюсь на dnsleaktest.com, оно утекает. До этого на 19м минте не утекало. На 18 утекало.
При этом с тем же самым впн на KDE всегда все отлично, но там нет кривого NM.

FliXis писал(а): ↑
30 июл 2021, 21:39
мне надо чтобы работало.

Надо? Почини.

Whowka писал(а): ↑
30 июл 2021, 21:54
Надо? Почини.

Я потому и создал тему, чтобы починить с помощью тех, кто знает как это сделать. Но, как видно, не по адресу написал.

FliXis, Понимаю что реализация DE отличается (KDE,Mate,Cinnamon), в одном случае QT в другом GTK,
что то туговато доходит, но мне видится, что NM одинаково работает и выполняет одни и те же функции для разных DE.

Не по теме

FliXis писал(а): ↑
30 июл 2021, 21:56
как видно, не по адресу

Попробуй наhttps://linuxmint.com/ обратиться. Там точно знают

Я правильно понял термин "утечка DNS" как возникновение ситуации, при которой система для разрешения доменных имен даже после соединения с VPN-сервером или сетью Tor продолжает запрашивать DNS сервера провайдера? Если это так и никаких ляпов при настройке соединения с VPN допущено не было, то лично мне ситуация вполне понятна
Разве при установлении связи с поставщиком VPN мы по воздуху прыгнули к нужному поставщику и воткнули второй конец своего сетевого шнурка в его аппаратную стойку? Или, всё-таки, наши сигналы идут по последовательной цепочке: роутер для соединения с провайдером, сети провайдера, шлюзы провайдера и далее, далее далее ... И на каждом этапе будет сидеть свой сердитый администратор, который будет "строить козни": так не ходи, вот так ходи. А будешь пытаться нарушать установленные нами правила хождения - привлечем к ответственности за несанкционированные попытки вмешательства в работу сетевой инфраструктуры. Для начала хорошо бы узнать каким инструментом было определено, что это утечка DNS, и как происходило расследование. На том же хабре несколько лет назад читал публикацию о том, что ряд провайдеров втихую принудительно заворачивают трафик на свои DNS и даже приводился способ как это определить.
И каким боком к утечке DNS NM? Если ваша уверенность в его вине настолько велика, то что вам мешает вырезать его из системы и настроить свою сеть без NM?

madesta писал(а): ↑
31 июл 2021, 01:43
Для начала хорошо бы узнать каким инструментом было определено, что это утечка DNS

https://dnsleaktest.com/

madesta писал(а): ↑
31 июл 2021, 01:43
никаких ляпов при настройке соединения с VPN допущено не было

Да какие там могут быть ляпы? Импортируешь файл в гуи openvpn, вот и вся "настройка". Если же Вы про настройку самого vds сервера, то там много лет все отлично и у других людей на других системах нет таких проблем.

Утечки nds нет на мобильном, утечки dns нет на windows, утечки dns нет на линуксах с kde.
Но зато она есть в минте с корицей.
Днс не резолвится при включении впн.

Для меня несколько удивительно, что Вы все тут упоминаете какие-то кривые руки, ошибки пользователя и т.п. Такое впечатление, что Вы не используете openvpn в linux mint cinnamon.

FliXis писал(а): ↑
31 июл 2021, 13:01
Да какие там могут быть ляпы?

Отсутствие в конфиге опции заставляющие клиент VPN дать команду ресолверу переключить используемые сервера. И это встречается на половине VPN серверов. Причем не всегда - ошибка. Т.к. не всем нужно свои DNS запросы прятать или иметь особые зоны.

Но в любом случае - может конкретику покажете уже? Чтобы не возиться со скриншотами - вот вам две команды:
systemd-resolve --status
nmcli d show
Покажите вывод с них, при отключенном и при подключенном VPN. Тогда может быть предметный разговор а не гадание на кофейной гуще.

DNS Jumper

DNS Jumper.tar.gz

Мутное какое-то происхождение DMS-Jumper, но в результате попыток найти какие-то концы понял только то, что Jumper просто напросто вносит изменения в resolv.conf, то есть меняет адреса 1-й и 2-й серверов DNS. Так, наверное, после внесения изменений нужно производить некий рестарт systemd, чтобы изменения вошли в силу?

madesta писал(а): ↑
31 июл 2021, 20:46
Так, наверное, после внесения изменений нужно производить некий рестарт systemd, чтобы изменения вошли в силу?

Вообще-то - нет. Если система вообще учитывает resolv.conf то достаточно просто сохранить изменения в файле - они сразу вступают в силу. Испокон веков так было. То же самое касается hosts, hostname и многих других. А вот если конфигурация сети выполнялась через статический файл /etc/network/interfaces - там уже могут быть варианты, в зависимости от того что поменялось. Иногда весь сервис networking требуется перезапустить целиком. Хотя обычно - только затронутый интерфейс.

Правда в современных системах resolv.conf обычно генерируется автоматически во время каждого подъема интерфейсов, так что лезть в него руками смысла мало.

DNS Jumper
Видео
Скачать видео

Хотелось бы, как говорит slant, всё-таки увидеть эту информацию.
И можно ли подробностей по вопросу:

FliXis писал(а): ↑
31 июл 2021, 13:01
Импортируешь файл в гуи openvpn, вот и вся "настройка"

resolv.conf
off vpn

Код: Выделить всё

nameserver 127.0.0.53
options edns0 trust-ad

on vpn

Код: Выделить всё

nameserver 127.0.0.53
options edns0 trust-ad

systemd-resolve --status

Global
LLMNR setting: no
MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
DNSSEC supported: no
DNSSEC NTA: 10.in-addr.arpa
16.172.in-addr.arpa
1**.1**.in-addr.arpa
17.172.in-addr.arpa
18.172.in-addr.arpa
19.172.in-addr.arpa
20.172.in-addr.arpa
21.172.in-addr.arpa
22.172.in-addr.arpa
23.172.in-addr.arpa
24.172.in-addr.arpa
25.172.in-addr.arpa
26.172.in-addr.arpa
27.172.in-addr.arpa
28.172.in-addr.arpa
29.172.in-addr.arpa
30.172.in-addr.arpa
31.172.in-addr.arpa
corp
d.f.ip6.arpa
home
internal
intranet
lan
local
private
test

Link 2 (enp4s0)
Current Scopes: DNS
DefaultRoute setting: yes
LLMNR setting: yes
MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
DNSSEC supported: no
Current DNS Server: fe80::****:ceff:****:2d8e
DNS Servers: 1**.1**.199.1
fe80::****:ceff:****:2d8e
DNS Domain: ~.

Global
LLMNR setting: no
MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
DNSSEC supported: no
DNSSEC NTA: 10.in-addr.arpa
16.172.in-addr.arpa
1**.1**.in-addr.arpa
17.172.in-addr.arpa
18.172.in-addr.arpa
19.172.in-addr.arpa
20.172.in-addr.arpa
21.172.in-addr.arpa
22.172.in-addr.arpa
23.172.in-addr.arpa
24.172.in-addr.arpa
25.172.in-addr.arpa
26.172.in-addr.arpa
27.172.in-addr.arpa
28.172.in-addr.arpa
29.172.in-addr.arpa
30.172.in-addr.arpa
31.172.in-addr.arpa
corp
d.f.ip6.arpa
home
internal
intranet
lan
local
private
test

Link 4 (tun0)
Current Scopes: DNS
DefaultRoute setting: yes
LLMNR setting: yes
MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
DNSSEC supported: no
Current DNS Server: 10.**.0.1
DNS Servers: 10.**.0.1
DNS Domain: ~.

Link 2 (enp4s0)
Current Scopes: none
DefaultRoute setting: no
LLMNR setting: yes
MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
DNSSEC supported: no

nmcli d show

GENERAL.DEVICE: enp4s0
GENERAL.TYPE: ethernet
GENERAL.HWADDR: BC:**:7B:**:56:63
GENERAL.MTU: 1500
GENERAL.STATE: 100 (connected)
GENERAL.CONNECTION: Wired connection 1
GENERAL.CON-PATH: /org/freedesktop/NetworkManager/ActiveConnection/1
WIRED-PROPERTIES.CARRIER: on
IP4.ADDRESS[1]: 1**.1**.199.3/24
IP4.GATEWAY: 1**.1**.199.1
IP4.ROUTE[1]: dst = 0.0.0.0/0, nh = 1**.1**.199.1, mt = 100
IP4.ROUTE[2]: dst = 1**.1**.199.0/24, nh = 0.0.0.0, mt = 100
IP4.ROUTE[3]: dst = 1**.2**.0.0/16, nh = 0.0.0.0, mt = 1000
IP4.DNS[1]: 1**.1**.199.1
IP6.ADDRESS[1]: 2a02:****:****:4800:be05:****:f5a6:2782/128
IP6.ADDRESS[2]: fe80::****:7bd4:****:522e/64
IP6.GATEWAY: fe80::****:ceff:****:2d8e
IP6.ROUTE[1]: dst = 2a02:****:****:4800::/64, nh = fe80::****:ceff:****:2d8e, mt = 100
IP6.ROUTE[2]: dst = ::/0, nh = fe80::****:ceff:****:2d8e, mt = 20100
IP6.ROUTE[3]: dst = fe80::/64, nh = ::, mt = 100
IP6.ROUTE[4]: dst = 2a02:****:****:4800:be05:****:f5a6:2782/128, nh = ::, mt = 100
IP6.DNS[1]: fe80::****:ceff:****:2d8e

GENERAL.DEVICE: lo
GENERAL.TYPE: loopback
GENERAL.HWADDR: 00:00:00:00:00:00
GENERAL.MTU: 65536
GENERAL.STATE: 10 (unmanaged)
GENERAL.CONNECTION: --
GENERAL.CON-PATH: --
IP4.ADDRESS[1]: 127.0.0.1/8
IP4.GATEWAY: --
IP6.ADDRESS[1]: ::1/128
IP6.GATEWAY: --
IP6.ROUTE[1]: dst = ::1/128, nh = ::, mt = 256

GENERAL.DEVICE: enp4s0
GENERAL.TYPE: ethernet
GENERAL.HWADDR: BC:**:**:21:56:63
GENERAL.MTU: 1500
GENERAL.STATE: 100 (connected)
GENERAL.CONNECTION: Wired connection 1
GENERAL.CON-PATH: /org/freedesktop/NetworkManager/ActiveConnection/1
WIRED-PROPERTIES.CARRIER: on
IP4.ADDRESS[1]: 1**.1**.199.3/24
IP4.GATEWAY: 1**.1**.199.1
IP4.ROUTE[1]: dst = 0.0.0.0/0, nh = 1**.1**.199.1, mt = 100
IP4.ROUTE[2]: dst = 176.1**.2**.154/32, nh = 1**.1**.199.1, mt = 100
IP4.ROUTE[3]: dst = 1**.1**.199.1/32, nh = 0.0.0.0, mt = 100
IP4.ROUTE[4]: dst = 1**.1**.199.0/24, nh = 0.0.0.0, mt = 100
IP4.ROUTE[5]: dst = 1**.2**.0.0/16, nh = 0.0.0.0, mt = 1000
IP4.DNS[1]: 1**.1**.199.1
IP6.ADDRESS[1]: 2a02:****:****:4800:be05:****:f5a6:2782/128
IP6.ADDRESS[2]: fe80::****:7bd4:****:522e/64
IP6.GATEWAY: fe80::****:ceff:****:2d8e
IP6.ROUTE[1]: dst = 2a02:2168:****:4800::/64, nh = fe80::****:ceff:****:2d8e, mt = 100
IP6.ROUTE[2]: dst = ::/0, nh = fe80::****:ceff:****:2d8e, mt = 20100
IP6.ROUTE[3]: dst = fe80::/64, nh = ::, mt = 100
IP6.ROUTE[4]: dst = 2a02:2168:****:4800:****:****:f5a6:2782/128, nh = ::, mt = 100
IP6.DNS[1]: fe80::****:ceff:****:2d8e

GENERAL.DEVICE: tun0
GENERAL.TYPE: tun
GENERAL.HWADDR: (unknown)
GENERAL.MTU: 1500
GENERAL.STATE: 100 (connected)
GENERAL.CONNECTION: tun0
GENERAL.CON-PATH: /org/freedesktop/NetworkManager/ActiveConnection/3
IP4.ADDRESS[1]: 10.**.0.16/16
IP4.GATEWAY: 10.**.0.1
IP4.ROUTE[1]: dst = 10.**.0.0/16, nh = 0.0.0.0, mt = 50
IP4.ROUTE[2]: dst = 0.0.0.0/0, nh = 10.**.0.1, mt = 50
IP6.ADDRESS[1]: fe80::aa**:cf:****:a489/64
IP6.GATEWAY: --
IP6.ROUTE[1]: dst = fe80::/64, nh = ::, mt = 256

GENERAL.DEVICE: lo
GENERAL.TYPE: loopback
GENERAL.HWADDR: 00:00:00:00:00:00
GENERAL.MTU: 65536
GENERAL.STATE: 10 (unmanaged)
GENERAL.CONNECTION: --
GENERAL.CON-PATH: --
IP4.ADDRESS[1]: 127.0.0.1/8
IP4.GATEWAY: --
IP6.ADDRESS[1]: ::1/128
IP6.GATEWAY: --
IP6.ROUTE[1]: dst = ::1/128, nh = ::, mt = 256

slant писал(а): ↑
31 июл 2021, 14:05
Отсутствие в конфиге опции заставляющие клиент VPN дать команду ресолверу переключить используемые сервера.

Опция такая имеется
Вывод я немного подредактировал, но это наверняка не помешает что-нибудь понять? Если мешает, то скажите

FliXis, А теперь то же самое но без "цензуры". Мак можете продолжать забивать, если паранойя мучает, но все IP адреса здесь нужно видеть как есть - иначе смысла в этом никакого.

slant писал(а): ↑
04 авг 2021, 18:00
иначе смысла в этом никакого.

А сам resolv.conf разве не говорит о том, что не происходит резолв после включения впн?
Там должен быть совсем другой айпишник, а не 127, как у меня

LinuxMint.com.ru

Утечка DNS

Утечка DNS

Утечка DNS

Утечка DNS

Утечка DNS

Утечка DNS

Утечка DNS

Утечка DNS

Утечка DNS

Утечка DNS

Утечка DNS

Утечка DNS

Утечка DNS

Утечка DNS

Утечка DNS

Утечка DNS

Утечка DNS

Утечка DNS

Утечка DNS

Утечка DNS

Утечка DNS