Начиная с Ubunutu 18, почему openvpn client.ovpn:"dhcp-option DNS xxx.xxx.xxx.xxx" не настраивает /etc/resolv.conf?
Я пытаюсь настроить клиент openvpn с Ubuntu 18. Я выполняю следующие магические шаги:
$ sudo apt-get install openvpn
$ sudo apt-get install openvpn-systemd-resolved
$ sudo openvpn --client --config ./client.ovpn
Wed Jan 2 16:24:14 2019 OpenVPN 2.4.4 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Sep 5 2018
Wed Jan 2 16:24:14 2019 library versions: OpenSSL 1.1.0g 2 Nov 2017, LZO 2.08
...
<14>Jan 2 15:58:07 update-systemd-resolved: Link 'tun0' coming up
<14>Jan 2 15:58:07 update-systemd-resolved: Adding IPv4 DNS Server 172.17.0.1
<14>Jan 2 15:58:07 update-systemd-resolved: Setting DNS Domain mycompany.com
<14>Jan 2 15:58:07 update-systemd-resolved: Adding IPv4 DNS Server 172.17.0.1
<14>Jan 2 15:58:07 update-systemd-resolved: Adding IPv4 DNS Server 8.8.8.8
<14>Jan 2 15:58:07 update-systemd-resolved: Setting DNS Domain mycompany.com
<14>Jan 2 15:58:07 update-systemd-resolved: Setting DNS Domain mycompany.com
<14>Jan 2 15:58:07 update-systemd-resolved: SetLinkDNS(4 3 2 4 172 17 0 1 2 4 172 17 0 1 2 4 8 8 8 8)
<14>Jan 2 15:58:07 update-systemd-resolved: SetLinkDomains(4 1 mycompany.com false)
Wed Jan 2 15:58:12 2019 ROUTE remote_host is NOT LOCAL
Wed Jan 2 15:58:12 2019 /sbin/ip route add 96.78.182.190/32 via 172.20.10.1
Wed Jan 2 15:58:12 2019 /sbin/ip route add 8.8.8.8/32 metric 101 via 172.27.232.1
Wed Jan 2 15:58:12 2019 /sbin/ip route add 172.27.224.0/20 metric 101 via 172.27.232.1
Wed Jan 2 15:58:12 2019 /sbin/ip route add 172.17.0.0/16 metric 101 via 172.27.232.1
Wed Jan 2 15:58:12 2019 Initialization Sequence Completed
где:
$ tail ./client.ovpn # Recently downloaded from the openvpn server
... # Appended this magic
.... # from here: https://Ask-ubuntu.ru/questions/1032476/ubuntu-18-04-no-dns-resolution-when-connected-to-openvpn
script-security 2
dhcp-option DNS 172.17.0.1
dhcp-option DOMAIN mycompany.com
up /etc/openvpn/update-systemd-resolved
down /etc/openvpn/update-systemd-resolved
down-pre
И если я посмотрю на:
$ ls -la /etc/resolv.conf
lrwxrwxrwx 1 root root 39 Nov 21 16:53 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf
$ cat /etc/resolv.conf
nameserver 127.0.0.53 <<< SHOULD BE 172.17.0.1
search mycompany.com
Так что, похоже, что клиент openvpn не настроен /etc/resolv.conf как это произошло с Ubuntu 14. Без этого, если я "ping git" или "ping git.mycompany.com", чтобы найти нашу внутреннюю службу git (или любую внутреннюю службу), я просто получаю IP-адрес кабельного модема для всех запросов ping.,
Если я отредактирую /etc/resolv.conf и заменим 127.0.0.53 на 172.17.0.1, как было запрошено в client.ovpn, то все работает нормально.
Почему этот client.ovpn не вызывает обновления /etc/resolv.conf в Ubuntu 18?
Любопытно, systemd-resolve не согласен с /etc/resolv.conf, Что с этим?
$ systemd-resolve --status
Global
DNSSEC NTA: 10.in-addr.arpa
16.172.in-addr.arpa
...
home
internal
intranet
lan
local
private
test
Link 4 (tun0)
Current Scopes: DNS
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
DNS Servers: 172.17.0.1
8.8.8.8
DNS Domain: mycompany.com
Link 2 (wlp2s0)
Current Scopes: DNS
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
DNS Servers: 172.20.10.1
fe80::1c71:e8cb:d5ec:89ef
Для копать, по крайней мере, что угодно systemd-resolve --status сообщает, игнорируется:
$ dig git
; <<>> DiG 9.11.3-1ubuntu1.3-Ubuntu <<>> git
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 55917
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;git. IN A
;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) <<< Not the DNS I want
;; WHEN: Wed Jan 02 15:41:39 PST 2019
;; MSG SIZE rcvd: 32
Связанные вопросы, которые не помогли:
2 ответа
Это не прямой ответ на вопрос (я не знаю, почему /etc/resolv.conf не обновляется должным образом - но независимо от того, почему настоящая проблема заключается в том, что это не так), а скорее решение Основная проблема. Попробовав МНОЖЕСТВО вещей, которые я читал здесь и в других местах, это единственное, что в итоге сработало для меня:
в /etc/systemd/resolved.conf измените "да" на "нет" в этой строке (и раскомментируйте, если необходимо), чтобы в итоге вы получили:
DNSStubListener = нет
Я полагаю, что это говорит системе о том, что система не должна смотреть на /etc/resolv.conf (который в моем случае направлял ее только на 127.0.0.53 - на ней не было серверов имен, предоставляемых OpenVPN, как упоминалось в первоначальном вопросе).) для DNS. Я предполагаю, что запрет на использование /etc/resolv.conf заставляет его использовать другие (правильные) настройки DNS, которые предоставляет OpenVPN.
Обратите внимание, что это не будет работать (по крайней мере, для меня) во время работы dnsmasq, поэтому, если он установлен, остановите службу и отключите ее.
Обратите внимание, что это предполагает Ubuntu 18.04 и, возможно, что другие решения, упомянутые здесь и в других местах, уже реализованы, включая openvpn-systemd-resolved а также resolvconf и включая необходимые строки в .ovpn файл:
script security 2
up /etc/openvpn/update-systemd-resolved
up-restart
down /etc/openvpn/update-systemd-resolved
down-pre
Хотя я подозреваю, что это исправление делает все это неактуальным, поскольку он получает DNS откуда-то, кроме /etc/resolv.conf, что, как я полагаю, и есть то, что должны исправить скрипты update-systemd-resolved (но не для некоторых людей),
Следующий: DNS установлен в systemd 127.0.0.53 - как изменить постоянно?
Если я установлю resolvconf:
$ sudo apt install resolvconf
$ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.
nameserver 127.0.0.53
... так что я думаю 127.0.0.53 == что угодно systemd-resolve --status говорит.
Там нет необходимости изменять /etc/resolvconf/resolv.conf.d/tail