Das Problem
Ich habe eine VPC, in der ich über private FQDNs auf die Server zugreifen muss. Die VPC ist über ein Wireguard-VPN zugänglich. Der VPN-Server dient auch als DNS-Server mit BIND9. Ich habe den DNS-Server mit einer privaten Zone entsprechend eingerichtetLernprogramm. Innerhalb des VPC funktioniert das DNS wie erwartet und ich kann die Server über die in der DNS-Zone definierten FQDNs erreichen.
Wenn ich mich über den VPN-Tunnel mit dem VPC verbinde, kann ich diese FQDNs nicht auflösen, obwohl ich meinen VPN-Client so eingerichtet habe, dass er meinen privaten DNS-Server verwendet. Ich weiß, dass der VPN-Client meinen privaten DNS-Server verwendet, weil nslookup google.comich beim Ausführen die IP-Adresse meines DNS sehe, wie Sie im folgenden Ergebnis sehen können:
Server: 10.118.0.2
Address: 10.118.0.2#53
...
Wenn ich von einem Computer ausführe, nslookup myprivate.domain.comder über den VPN-Tunnel mit dem VPC verbunden ist, erhalte ich eine NXDOMAIN, dasselbe gilt für ping, es schlägt mit dem Fehler fehl Name or service not known. Wenn ich jedoch vom VPC aus einen Ping auf der privaten IP-Adresse ausführe, funktioniert es. Wenn also myprivate.domain.comauf dem Server unter gehostet wird 10.118.0.3, ist der Ping auf der IP-Adresse erfolgreich, schlägt aber auf dem FQDN fehl.
Sehen Sie sich außerdem die Dig-Ergebnisse innerhalb des VPC im Vergleich zu denen von einem über das VPN verbundenen Computer aus an:
dig dev.myprivatedomain.com ns: VON 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
VOM 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
Mir fällt auf, dass beide den gleichen DNS-Server verwenden, aber bei einer Anfrage vom VPN wird die Autorität für meine private Domain nicht zurückgegeben.
Abschließend, nach mehreren Stunden der Recherche gelingt es mir nicht, herauszufinden, was den Clients fehlt, die über das VPN eine Verbindung zum VPC herstellen, um die von meinem privaten DNS definierten FQDNs auflösen zu können.
Weitere Informationen
- Der Server ist Ubuntu 20.04 LTS
- Bindung 9:
BIND 9.16.1-Ubuntu (Stable Release) - Wireguard:
wireguard-tools v1.0.20200513über Wirespeed installiert - UFW aktiviert
Die VPN- und DNS-Server-IP im VPC lautet 10.118.0.2.
Der VPN-Adresspool ist 10.99.0.0/16und ich habe die BIND9-Konfigurationen folgendermaßen eingestellt:
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;
};
};
Die Zone ist folgendermaßen konfiguriert:
$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
und die Reverse-Zone-Datei:
$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 ist so eingestellt, dass Port 53 sowohl für TCP als auch für UDP zugelassen ist.
Außerdem verfügt UFW über Regeln, um Datenverkehr vom VPN zuzulassen:
*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.99.0.0/16 -o eth1 -j MASQUERADE
Die vorherige Regel wurde eingerichtet, um einem Client die Verbindung zum VPN-Tunnel und die Nutzung des privaten DNS-Servers zu ermöglichen. Ohne diese Regel kann ich nicht auf das Internet zugreifen, es sei denn, ich stelle die DNS-Adresse auf eine öffentliche Adresse wie die von Google ein. Ich bin bei meinen Recherchen auf diese Regel gestoßen, kenne mich jedoch noch nicht sehr gut mit Firewall-Konfigurationen aus und verstehe ihre Bedeutung noch nicht vollständig. Sie hat mir geholfen, meinem Ziel näher zu kommen, aber ich muss mich noch weiter damit befassen.
Unten finden Sie die Wireguard VPN-Clientkonfiguration:
[Interface]
...
DNS = 10.118.0.2
Address = 10.99.0.2/16
[Peer]
...
AllowedIPs = 10.99.0.0/16, 10.118.0.0/20
UPDATE: PROBLEMUMGEHUNG
Der Wireguard-Server wurde über eine andere Software installiert, die ihn verpackte und zusätzliche Dienste bereitstellte (Weboberfläche, vereinfachte Einrichtung). Der Nachteil war, dass ich kaum Kontrolle über die Konfiguration des Wireguard-Servers hatte.
Folglich habe ich die Software entfernt und Wireguard manuell installiert, wodurch ich das VPN richtig einrichten konnte, insbesondere damit die Routing-Regeln mit meinem VPC-Setup funktionierten. Ich musste den Datenverkehr im VPN-Tunnel von der VPN-Schnittstelle zur privaten VPC-Schnittstelle statt zur öffentlichen Schnittstelle umleiten. Dadurch wurde mein Problem letztendlich gelöst, ohne dass ich den DNS-Server und die Zonenkonfigurationen ändern musste.