Начиная с Ubuntu 18, почему не делает client.ovpn openvpn: “dhcp-опция 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://askubuntu.com/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-запросов мерзавца" или, "проверяют с помощью ping-запросов git.mycompany.com" для нахождения нашего внутреннего сервиса мерзавца (или любого внутреннего сервиса), я просто мерзавец 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 ответа
Следующее: набор DNS к 127.0.0.53 systemd - как измениться постоянно?
Если я устанавливаю 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
Это не прямой ответ на вопрос (я не знаю, почему/etc/resolv.conf правильно не обновляется - но независимо от того, почему, настоящая проблема состоит в том, что это не), а скорее решение базовой проблемы. После попытки БОЛЬШОГО КОЛИЧЕСТВА вещей я читал здесь и в другом месте, это - единственная вещь, которая наконец работала на меня:
в/etc/systemd/resolved.conf, изменение "да" к "нет" в этой строке (и некомментарий при необходимости) так, чтобы Вы закончили с:
DNSStubListener=no
Я верю тому, что это делает, говорит системе не смотреть на/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 сценарии, как предполагается, фиксируют (но делают не для некоторых людей).