Утечка DNS

[FliXis]

Linux mint x64 cinnamon 20.2

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

[hellonet]

Кто-нибудь знает, как исправить?

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

[FliXis]

На хабре подымался вопрос

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

[slant]

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

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

Я уже использую впн, но рашкинский днс утекает из-за бага в нетворк менеджере.

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

Удивительно, что практически всем глубоко по барабану на подобную проблему, это в наши то времена, когда впн юзают очень многие.

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

[FliXis]

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

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

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

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

А NM, кстати, вообще не является ресолвером DNS. В минте им работает systemd-resolvd.

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

DNS "течь" не может по определению

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

[Whowka]

мне надо чтобы работало.

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

[FliXis]

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

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

[sheridan]

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

[Whowka]

Не по теме

как видно, не по адресу

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

[madesta]

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

[FliXis]

Для начала хорошо бы узнать каким инструментом было определено, что это утечка DNS

https://dnsleaktest.com/

никаких ляпов при настройке соединения с VPN допущено не было

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

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

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

[slant]

Да какие там могут быть ляпы?

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

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

[drooone]

DNS Jumper

DNS Jumper.tar.gz

[madesta]

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

[slant]

Так, наверное, после внесения изменений нужно производить некий рестарт systemd, чтобы изменения вошли в силу?

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

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

[drooone]

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

[madesta]

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

Импортируешь файл в гуи openvpn, вот и вся "настройка"

[FliXis]

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

Отсутствие в конфиге опции заставляющие клиент VPN дать команду ресолверу переключить используемые сервера.

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

[slant]

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

[FliXis]

иначе смысла в этом никакого.

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