El problema
Tengo una VPC en la que necesito acceder a los servidores mediante FQDN privados. Se puede acceder a la VPC a través de una VPN Wireguard. El servidor VPN también sirve como servidor DNS ejecutando BIND9. He configurado el servidor DNS con una zona privada de acuerdo con estotutorial. Desde dentro de la VPC, el DNS funciona como se esperaba y puedo acceder a los servidores mediante los FQDN definidos en la zona DNS.
Cuando me conecto a la VPC a través del túnel VPN, no puedo resolver esos FQDN aunque configuré mi cliente VPN para usar mi servidor DNS privado. Sé que el cliente VPN usa mi servidor DNS privado porque cuando lo ejecuto nslookup google.comveo la dirección IP de mi DNS, como puede ver el resultado a continuación:
Server: 10.118.0.2
Address: 10.118.0.2#53
...
Si ejecuto nslookup myprivate.domain.comdesde una máquina conectada a la VPC a través del túnel VPN, recibo un NXDOMAIN, lo mismo ocurre con el ping, falla con el error Name or service not known. Sin embargo, si ejecuto ping en la dirección IP privada desde la VPC, funciona. Entonces, si myprivate.domain.comestá alojado en el servidor en 10.118.0.3, el ping se realiza correctamente en la dirección IP pero falla en el FQDN.
Además, vea los resultados de la excavación dentro de la VPC frente a cuando desde una máquina conectada a través de la VPN:
dig dev.myprivatedomain.com nsDESDE 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
DESDE 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
Noto que ambos usan el mismo servidor DNS, pero cuando se solicita desde la VPN, no se devuelve la autoridad para mi dominio privado.
En conclusión, después de varias horas de investigación, me estoy quedando corto para descubrir qué les falta a los clientes que se conectan a la VPC a través de la VPN para poder resolver los FQDN definidos por mi DNS privado.
información adicional
- El servidor es ubuntu 20.04 LTS.
- Enlace 9:
BIND 9.16.1-Ubuntu (Stable Release) - Wireguard:
wireguard-tools v1.0.20200513instalado a través de Wirespeed - UFW habilitado
La IP del servidor VPN y DNS en la VPC es 10.118.0.2.
El grupo de direcciones VPN es 10.99.0.0/16y he configurado las configuraciones de BIND9 de la siguiente manera:
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;
};
};
La zona se configura de esta manera:
$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
y el archivo de zona inversa:
$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 está configurado para permitir el puerto 53 tanto para TCP como para UDP.
Además, UFW tiene reglas anteriores para permitir el tráfico desde la VPN:
*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.99.0.0/16 -o eth1 -j MASQUERADE
La regla anterior se configuró para permitir que un cliente se conecte al túnel VPN y use el servidor DNS privado. Sin esta regla, no puedo acceder a Internet a menos que configure la dirección DNS como una pública como la de Google. Encontré esta regla durante mi investigación, sin embargo, todavía no estoy muy familiarizado con las configuraciones del firewall y aún no entiendo completamente sus implicaciones. Me ha ayudado a acercarme a mi objetivo, pero necesito leer más al respecto.
A continuación se muestra la configuración del cliente 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
ACTUALIZACIÓN: SOLUCIÓN ALTERNATIVA
El servidor Wireguard se instaló a través de otro software que lo empaquetó y proporcionó servicios adicionales (interfaz web, configuración facilitada). La desventaja era que tenía poco control sobre la configuración del servidor Wireguard.
En consecuencia, terminé eliminando el software e instalando Wireguard manualmente, lo que me permitió configurar correctamente la VPN, especialmente para que las reglas de enrutamiento funcionen con mi configuración de VPC. Necesitaba enrutar el tráfico en el túnel VPN desde la interfaz VPN a la interfaz privada de VPC en lugar de a la interfaz pública. Esto terminó resolviendo mi problema sin tener que modificar el servidor DNS y las configuraciones de zona.