Назад | Перейти на главную страницу

Wireguard VPN + OpenVPN VPN приводит к сбою разрешения DNS для туннеля OpenVPN

У меня есть две VPN - одна через проводную защиту для моего общего интернет-трафика, другая через openvpn (для работы). Разрешение DNS через openvpn работает только частично.

Когда оба туннеля открыты:

А) systemd-resolve нужно "научить" использовать tun0. (Это работало раньше, когда обе VPN использовали openvpn.)

> systemd-resolve jenkins.staging.mycompany.com
jenkins.staging.mycompany.com: resolve call failed: All attempts to contact name servers or networks failed

> systemd-resolve -i tun0 jenkins.staging.mycompany.com
jenkins.staging.mycompany.com: 10.1.2.36       -- link: tun0

-- Information acquired via protocol DNS in 48.5ms.
-- Data is authenticated: no

> systemd-resolve jenkins.staging.mycompany.com
jenkins.staging.mycompany.com: 10.1.2.36       -- link: tun0

-- Information acquired via protocol DNS in 852us.
-- Data is authenticated: no

Б) копать работает из коробки. nslookup работает, только если я укажу ему, какой DNS-сервер использовать. curl не работает.

> curl jenkins.staging.mycompany.com:8080
curl: (6) Could not resolve host: jenkins.staging.mycompany.com

> dig jenkins.staging.mycompany.com

; <<>> DiG 9.11.5-P4-5.1ubuntu2.1-Ubuntu <<>> jenkins.staging.mycompany.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 2834
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;jenkins.staging.mycompany.com. IN  A

;; AUTHORITY SECTION:
mycompany.com.      56  IN  SOA [aws dns info]

;; Query time: 47 msec
;; SERVER: 172.16.0.1#53(172.16.0.1)
;; WHEN: Sat Apr 18 09:08:44 EDT 2020
;; MSG SIZE  rcvd: 143

> nslookup jenkins.staging.mycompany.com
Server:     172.16.0.1    <- uses wrong dns server by default
Address:    172.16.0.1#53

** server can't find jenkins.staging.mycompany.com: NXDOMAIN

> nslookup jenkins.staging.mycompany.com 10.0.0.2
Server:     10.0.0.2
Address:    10.0.0.2#53

Non-authoritative answer:
Name:   jenkins.staging.mycompany.com
Address: 10.1.2.36

Моя теория заключалась в том, что Wireguard каким-то образом крал обязанности DNS у systemd, поэтому я попытался добавить DNS, предоставленный openvpn, в файл conf клиента:

[Interface]
PrivateKey = xxx
Address = 172.aa.bb.cc/32
DNS = 172.16.0.1 10.0.0.2

Но это не помогает.

Конфигурация systemd-resolve выглядит нормально, я думаю (?):

> resolveconf status

Global
       LLMNR setting: no
MulticastDNS setting: no
  DNSOverTLS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
  Current DNS Server: 172.16.0.1
         DNS Servers: 172.16.0.1
                      10.0.0.2
          DNS Domain: staging.mycompany.com
                      production.mycompany.com
                      infrastructure.mycompany.com
          DNSSEC NTA: 10.in-addr.arpa
                      ...
                      31.172.in-addr.arpa
                      corp
                      d.f.ip6.arpa
                      home
                      internal
                      intranet
                      lan
                      local
                      private
                      test

Link 5 (tun0)
      Current Scopes: DNS
DefaultRoute setting: yes
       LLMNR setting: yes
MulticastDNS setting: no
  DNSOverTLS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers: 10.0.0.2
          DNS Domain: staging.mycompany.com
                      production.mycompany.com
                      infrastructure.mycompany.com

У меня есть предложение, но у меня недостаточно репутации, чтобы комментировать, поэтому я помещаю свой комментарий в ответ. Вы смотрели метрику интерфейса для вашего виртуального адаптера Wireguard и виртуального адаптера OpenVPN? Я знаю, что в Windows, когда я сталкиваюсь с проблемой, которую вы описываете, мне приходится вручную устанавливать метрику интерфейса для обоих, для виртуального адаптера OpenVPN она просто должна быть ниже метрики для другого адаптера.