Я пытался включить DNS по TLS через systemd-resolved
. Я изменился /etc/systemd/resolved.conf
следующим образом:
[Resolve]
DNS=1.1.1.1
#FallbackDNS=
Domains=~.
#LLMNR=no
#MulticastDNS=no
#DNSSEC=no
DNSOverTLS=opportunistic
#Cache=yes
#DNSStubListener=yes
При контроле сети (с tcpdump), чтобы видеть, было ли получающееся поведение намеченным, кажется, что сессия TLS устанавливается с целевым сервером; но, затем сервер закрывает соединение. Я получаю те же результаты с 1.1.1.1, 8.8.8.8 и другие.
Какие-либо идеи о том, как зафиксировать это?
P.S.: systemd-resolved
заканчивает тем, что делал параллельное разрешение с традиционным DNS (несмотря на установку "Доменов" выше). Но мой основной вопрос для этого сообщения - то, что может идти не так, как надо с TLS один.
На основе моего опыта это не проложит себе путь упомянутое выше на Ubuntu 18.04 + (т.е. U19).
Так как Ubuntu 18 + использует Netplan параллельно с вещами NetworkManager, изменились решительно: больше никакой ручной конфигурации традиционными способами; - (Документация.... редка.
снимок может внести дальнейшие изменения. Это устанавливает дополнительные resolved.conf файлы. Однако следующее на самом деле работало (/w хорошая производительность).
Поскольку Информация о Netplan смотрит здесь.
Что DNS по TLS работал успешный (works4me):
1. В/etc/systemd/resolved.conf ТОЛЬКО изменяют DNSOverTLS = в
DNSOverTLS=opportunistic
Нет Никакой другой опции (см. объяснение здесь: DNS по TLS
46.182.19.48 resp. 2a02:2970:1002:: 18
Почему?Конфиденциальность!
Введите адрес сервера DNS в поле GUI для Вашего соединения при Настройках IPv4 / DNS-серверы и v6 соответственно.
Записи НЕ обнаружатся в /etc/resolv.conf
!! Который корректен. Вместо этого Вы будете видеть сервер имен 127.0.0.53
Это - новая Ubuntu.... больше не подходящая для администраторов хобби.
Установка соответствующих DNS-серверов может быть сделана непосредственно в /etc/resolv.conf
в обычном формате удалите 127.0.0.53 или что-то еще.
Проблема: перезаписывается Администратором сети в Ubuntu!
Средство: Как истинный корень (!) болтают файл/etc/resolv.conf
chattr +i /etc/resolv.conf
Это - грубая сила и может отключить автоматический DNS, кэширующийся через разрешенный.
Кредит к документации Дуги
Однако хорошо работает ;-) но нуждается в ручном обслуживании как в истинном корне!
Подсказка:
Вас целесообразно сделать resolv.conf
ссылка. Это требуется разрешенным работать правильно. Как sudo-корень отодвигают старый файл затем
sudo ln -s /run/resolvconf/resolv.conf /etc/resolv.conf
Мне не нравится этот путь, но по сути работает надлежащий.
.
Затем перезагрузка. Или сеть перезапуска.
.
# Как проверить
Проверьте DNS, на самом деле используемый systemd-разрешенным:
resolvectl status
Проверьте, решает ли DNS с resolvectl:
resolvectl query archlinux.org
(Попробуйте некоторые примеры),
Проверьте то, что на самом деле используется DNS, проверьте на утечки в VPN:
. 2. Запустите Wireshark и фильтр для "порта 53" и сделайте веб-трафик.
Это не должно показывать подключения на порте 53 больше. Затем фильтр для порта 853. Здесь должен много продолжиться.
Важный: Если весь трафик использует порт 853, и никакой трафик не использует 53, Вы сделали это успешно!
Примеры Wireshark здесь.
# Комментарий: Я попробовал тупиковый. тупиковый не интегрируется хорошо в Ubuntu, но можно получить ее работающий даже с NetworkManager. Существует одно руководство, чтобы сделать это успешно: Как использовать DNS по TLS на Ubuntu проблема Linux: производительность была чем-то вроде боли. Что-то странно, и я не узнал причины.
Включение DNSSEC=yes в/etc/systemd/resolved.conf должно быть возможным теперь.
Важный:
Это решение улучшает конфиденциальность много.
НО не достаточно, если Ваша персональная целостность зависит от конфиденциальности данных и безопасности!! Посмотрите протесты в resolvd описании. Не достаточно иметь оппортунистический режим. Затем лучше не упустите Хвосты Linux. Печальное приветствие всем политическим заключенным во всем мире.
Это здорово, но у меня есть одна гнида: если вы хотите получить контроль над resolv.conf, "официальный" ответ - удалить ссылку и сделать ее файлом. Это говорит и networkmanager, и systemd оставить его в покое и, по сути, стать клиентом (вместо «менеджера») для DNS в вашей системе. Имейте в виду, что если вы сделаете это, вы должны заполнить этот файл действительными записями сервера имен. Это прекрасно сочетается с запуском вашего собственного локального резолвера-заглушки (например, stubby или dnscrypt-proxy) либо на вашем локальном компьютере, либо в вашей локальной сети (или в обоих).
IP 46.182.19.48 соотв. 2a02:2970:1002::18 устарел. Digitalcourage предлагает новый сервер только для DNS-over-TLS с IP-адресом 5.9.164.112 (также с ограничением скорости)
, см. https://dns3.digitalcourage.de или https:// digitalcourage.de/support/zensurfreier-dns-server для подробностей (немецкий)