☰

Проблема

tag-icon • tag-icon vpn bind internal-dns ufw wireguard
Проблема

Проблема

У меня есть VPC, в котором мне нужно получить доступ к серверам с помощью частных FQDN. VPC доступен через Wireguard VPN. VPN-сервер также служит DNS-сервером с BIND9. Я установил DNS-сервер с частной зоной в соответствии с этимруководствоИзнутри VPC DNS работает так, как и ожидалось, и я могу связаться с серверами по полным доменным именам, определенным в зоне DNS.

При подключении к VPC через VPN-туннель я не могу разрешить эти FQDN, хотя я настроил свой VPN-клиент на использование моего частного DNS-сервера. Я знаю, что VPN-клиент использует мой частный DNS-сервер, потому что при запуске nslookup google.comя вижу IP-адрес своего DNS, как вы можете видеть ниже:

Server:     10.118.0.2
Address:    10.118.0.2#53
...

Если я запускаю nslookup myprivate.domain.comс машины, подключенной к VPC через VPN-туннель, я получаю NXDOMAIN, то же самое касается ping, он завершается ошибкой Name or service not known. Однако, если я запускаю ping на частном IP-адресе из VPC, он работает. Так что если myprivate.domain.comразмещен на сервере в 10.118.0.3, ping проходит успешно на IP-адресе, но не проходит на FQDN.

Кроме того, посмотрите результаты раскопок внутри VPC и с машины, подключенной через VPN: dig dev.myprivatedomain.com nsИЗ VPC:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51703
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 9dccc02158dee7f70100000061a7e0a1ce2597e377b9c301 (good)
;; QUESTION SECTION:
;dev.myprivatedomain.com.       IN  NS

;; AUTHORITY SECTION:
nabuinternal.com.   604800  IN  SOA ns1.myprivatedomain.com. ...

;; Query time: 0 msec
;; SERVER: 10.118.0.2#53(10.118.0.2)
;; WHEN: Wed Dec 01 20:52:49 UTC 2021
;; MSG SIZE  rcvd: 93

ИЗ VPN:

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 57158
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;dev.myprivatedomain.com.       IN  NS

;; AUTHORITY SECTION:
com.            900 IN  SOA a.gtld-servers.net. nstld.verisign-grs.com. 1638392201 1800 900 604800 86400

;; Query time: 44 msec
;; SERVER: 10.118.0.2#53(10.118.0.2)
;; WHEN: Wed Dec 01 15:57:05 EST 2021
;; MSG SIZE  rcvd: 122

Я заметил, что оба используют один и тот же DNS-сервер, но при запросе через VPN полномочия для моего частного домена не возвращаются.

В заключениеПосле нескольких часов исследований мне так и не удалось выяснить, чего не хватает клиентам, подключающимся к VPC через VPN, чтобы иметь возможность разрешать полные доменные имена, определенные моим частным DNS.

Дополнительная информация

  • Сервер — Ubuntu 20.04 LTS
  • Связка 9:BIND 9.16.1-Ubuntu (Stable Release)
  • wireguard: wireguard-tools v1.0.20200513установлен через Wirespeed
  • UFW включен

IP-адрес VPN- и DNS-сервера в VPC — 10.118.0.2.

Пул адресов VPN 10.99.0.0/16и настройки BIND9 я настроил следующим образом:

acl "trusted" {
    10.118.0.2;    # the vpn and dns server
    ...
    10.99.0.0/16;  # vpn address pool
    
};
options {
    directory "/var/cache/bind";
    listen-on-v6 { any; };
    recursion yes;
    allow-recursion { trusted; };
    listen-on { 10.118.0.0/20; 10.99.0.0/16; };  
    allow-transfer { none; };
    forwarders {
            8.8.8.8;
            8.8.4.4;
    };
};

Зона настроена следующим образом:

$TTL    604800
@       IN      SOA     ns1.myprivatedomain.com. admin.myprivatedomain.com. (
                              9         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;                         
; name servers - NS records
    IN      NS      ns1.myprivatedomain.com.

; name servers - A records
ns1.myprivatedomain.com.          IN      A       10.118.0.2

; 10.118.0.0/20 - A records
dev.myprivatedomain.com.            IN      A      10.118.0.4
staging.myprivatedomain.com.         IN      A      10.118.0.3

и файл обратной зоны:

$TTL    604800
@       IN      SOA     ns1.myprivatedomain.com. admin.myprivatedomain.com. (
                              7         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;
; name servers - NS records
    IN      NS      ns1.myprivatedomain.com.

; PTR Records
2.0   IN      PTR     ns1.myprivatedomain.com.         ; 10.118.0.2
4.0   IN      PTR     dev.myprivatedomain.com.         ; 10.118.0.4
3.0   IN      PTR     staging.myprivatedomain.com.      ; 10.118.0.3

UFW настроен на разрешение использования порта 53 как для TCP, так и для UDP.

Кроме того, в UFW есть правила, разрешающие трафик из VPN:

*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.99.0.0/16 -o eth1 -j MASQUERADE

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

Ниже представлена ​​конфигурация VPN-клиента Wireguard:

[Interface]
...
DNS = 10.118.0.2
Address = 10.99.0.2/16

[Peer]
...
AllowedIPs = 10.99.0.0/16, 10.118.0.0/20

ОБНОВЛЕНИЕ: ОБХОДНОЙ ПУТЬ

Сервер Wireguard был установлен через другое программное обеспечение, которое упаковывало его и предоставляло дополнительные услуги (веб-интерфейс, упрощенная настройка). Недостатком было то, что у меня было мало контроля над конфигурацией сервера Wireguard.

В результате я в конечном итоге удалил программное обеспечение и установил Wireguard вручную, что позволило мне правильно настроить vpn, особенно для правил маршрутизации, которые работали с моей настройкой VPC. Мне нужно было направить трафик в туннеле VPN с интерфейса VPN на частный интерфейс VPC вместо публичного интерфейса. Это в конечном итоге решило мою проблему без необходимости изменять конфигурации DNS-сервера и зоны.

Связанный контент