Problema

Am un VPC în care trebuie să accesez serverele folosind FQDN-uri private. VPC-ul este accesibil printr-un VPN wireguard. Serverul VPN servește și ca server DNS care rulează BIND9. Am setat serverul DNS cu o zonă privată în conformitate cu aceasta tutorial. Din interiorul VPC-ului, DNS-ul funcționează conform așteptărilor și pot ajunge la servere prin FQDN-urile definite în zona DNS.

Când mă conectez la VPC prin tunelul VPN, nu pot rezolva acele FQDN-uri, deși mi-am configurat clientul VPN pentru a utiliza serverul meu DNS privat. Știu că clientul VPN folosește serverul meu DNS privat pentru că atunci când rulez nslookup google.com Văd adresa IP a DNS-ului meu, după cum puteți vedea rezultatul de mai jos:

Server: 10.118.0.2
Adresă: 10.118.0.2#53
...

Dacă rulez nslookup myprivate.domain.com de la o mașină conectată la VPC prin tunelul VPN, primesc un NXDOMAIN, același lucru este valabil și pentru ping, eșuează cu eroarea Numele sau serviciul nu este cunoscut. Cu toate acestea, dacă rulez ping pe adresa IP privată de la VPC, funcționează. Astfel, dacă myprivate.domain.com este găzduit pe server la10.118.0.3, ping-ul reușește pe adresa IP, dar eșuează pe FQDN.

În plus, vedeți rezultatele săpăturii când sunteți în VPC vs atunci când de la o mașină conectată prin VPN: dig dev.myprivatedomain.com ns: DE LA VPC:

;; ->>HEADER<<- opcode: QUERY, stare: NOERROR, id: 51703
;; steaguri: qr aa rd ra; ÎNTREBARE: 1, RĂSPUNS: 1, AUTORITATE: 0, SUPLIMENTARE: 1

;; PSEUDOSECȚIE OPT:
; EDNS: versiunea: 0, steaguri:; udp: 4096
; COOKIE: 9dccc02158dee7f70100000061a7e0a1ce2597e377b9c301 (bine)
;; SECȚIUNEA DE ÎNTREBĂRI:
;dev.myprivatedomain.com. ÎN NS

;; SECȚIUNEA AUTORITATE:
nabuinternal.com. 604800 ÎN SOA ns1.myprivatedomain.com. ...

;; Timp de interogare: 0 ms
;; SERVER: 10.118.0.2#53(10.118.0.2)
;; CÂND: miercuri 01 decembrie 20:52:49 UTC 2021
;; MSG SIZE rcvd: 93

DE LA VPN:

;; Am răspuns:
;; ->>HEADER<<- opcode: QUERY, stare: NXDOMAIN, id: 57158
;; steaguri: qr rd ra; ÎNTREBARE: 1, RĂSPUNS: 0, AUTORITATE: 1, SUPLIMENTARE: 1

;; PSEUDOSECȚIE OPT:
; EDNS: versiunea: 0, steaguri:; udp: 1232
;; SECȚIUNEA DE ÎNTREBĂRI:
;dev.myprivatedomain.com. ÎN NS

;; SECȚIUNEA AUTORITATE:
com. 900 ÎN SOA a.gtld-servers.net. nstld.verisign-grs.com. 1638392201 1800 900 604800 86400

;; Timp de interogare: 44 ms
;; SERVER: 10.118.0.2#53(10.118.0.2)
;; CÂND: miercuri, 01 decembrie, 15:57:05 EST 2021
;; MSG SIZE rcvd: 122

Observ că ambele folosesc același server DNS, dar când sunt solicitate de la VPN, autoritatea pentru domeniul meu privat nu este returnată.

In concluzie, după mai multe ore de cercetare, nu reușesc să aflu ce lipsește clienților care se conectează la VPC prin VPN pentru a putea rezolva FQDN-urile definite de DNS-ul meu privat.

informatii suplimentare

• Serverul este Ubuntu 20.04 LTS
• Legatura 9: BIND 9.16.1-Ubuntu (Versiune stabilă)
• apărătoare de sârmă: Wireguard-Tools v1.0.20200513 instalat prin wirespeed
• UFW activat

IP-ul serverului VPN și DNS din VPC este 10.118.0.2.

Pool-ul de adrese VPN este 10.99.0.0/16 și am setat configurațiile BIND9 în felul următor:

acl „de încredere” {
    10.118.0.2; # serverul vpn și dns
    ...
    10.99.0.0/16; # pool de adrese VPN
    
};
Opțiuni {
    directorul „/var/cache/bind”;
    listen-on-v6 { orice; };
    recursivitate da;
    allow-recursion { de încredere; };
    ascultare pe { 10.118.0.0/20; 10.99.0.0/16; };  
    permit-transfer { niciunul; };
    expeditori {
            8.8.8.8;
            8.8.4.4;
    };
};

Zona este configurată astfel:

604800 USD TTL
@ ÎN SOA ns1.myprivatedomain.com. admin.myprivatedomain.com. (
                              9; Serial
                         604800; Reîmprospăta
                          86400; Reîncercați
                        2419200; Expira
                         604800); Cache negativ TTL
;                         
; servere de nume - înregistrări NS
    ÎN NS ns1.myprivatedomain.com.

; servere de nume - A înregistrează
ns1.myprivatedomain.com. ÎN A 10.118.0.2

; 10.118.0.0/20 - A înregistrează
dev.myprivatedomain.com. ÎN A 10.118.0.4
staging.myprivatedomain.com. ÎN A 10.118.0.3

și fișierul cu zona inversă:

604800 USD TTL
@ ÎN SOA ns1.myprivatedomain.com. admin.myprivatedomain.com. (
                              7; Serial
                         604800; Reîmprospăta
                          86400; Reîncercați
                        2419200; Expira
                         604800); Cache negativ TTL
;
; servere de nume - înregistrări NS
    ÎN NS ns1.myprivatedomain.com.

; Înregistrări PTR
2.0 ÎN PTR ns1.myprivatedomain.com. ; 10.118.0.2
4.0 ÎN PTR dev.myprivatedomain.com. ; 10.118.0.4
3.0 ÎN PTR staging.myprivatedomain.com. ; 10.118.0.3

UFW este setat să permită portul 53 atât pentru TCP, cât și pentru UDP.

De asemenea, UFW are reguli înainte de a permite traficul de la VPN:

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

Regula anterioară a fost configurată pentru a permite unui client să se conecteze la tunelul VPN și să utilizeze serverul DNS privat. Fără această regulă, nu pot accesa internetul decât dacă setez adresa DNS la una publică precum cea a google. Am găsit această regulă în timpul cercetării mele, totuși nu sunt încă foarte familiarizat cu configurațiile firewall și nu înțeleg încă pe deplin implicația acesteia. M-a ajutat să mă apropii de obiectivul meu, dar trebuie să citesc în continuare despre el.

Mai jos este configurația clientului wireguard VPN:

[Interfață]
...
DNS = 10.118.0.2
Adresa = 10.99.0.2/16

[Peer]
...
IP-uri permise = 10.99.0.0/16, 10.118.0.0/20