Tengo muchos dispositivos de red en casa y me gustaría que sean accesibles en la red de una manera amigable para los humanos. No quiero que se pueda acceder a los dispositivos directamente desde Internet.
Mis necesidades:
- El dispositivo puede tener múltiples "alias"- p.ej. debería ser accesible bajo cualquiera de los dos
backup,dockeronasnombre- Porque estoy ejecutando varios servicios en un solo dispositivo y me gusta distinguirlos, con la opción de moverlos a otro dispositivo.
- Se debe poder acceder al dispositivo de forma remota mediante una VPN alojada en casa
- Porque me gustaría acceder a mi NAS y poder ejecutar copias de seguridad desde una ubicación remota
- Se debe poder acceder al dispositivo desde una estación de trabajo doméstica conectada a una VPN del trabajo.
- Porque a veces trabajo desde casa y todavía quiero acceder a mi red local
A lo largo de los años, he probado las siguientes soluciones. Sin embargo, ninguno de ellos satisface todas mis necesidades sin concesiones.
UsandomDNS
Esta fue mi configuración inicial, se puede acceder a los dispositivos enhostname.local
❓ El dispositivo puede tener múltiples "alias"
Es posible que tenga varios nombres mDNS por dispositivo; sin embargo, nunca lo investigué más debido al siguiente problema
❌ Se debe poder acceder al dispositivo de forma remota mediante una VPN alojada en casa
mDNSSe utiliza el protocolo broadcastque no se reenvía a través de una conexión VPN. Las mDNSrespuestas de los dispositivos no pueden llegar al cliente VPN.
✅ Se debe poder acceder al dispositivo desde una estación de trabajo doméstica conectada a una VPN del trabajo
Esto funciona bien porque mDNS"omite" la VPN y accede a la red local.
Usando sobre el servidor mDNSdomésticoDNS
Estoy alojando mi propio DNSservidor en casa. La idea es que esto debería resolver mis dos primeras necesidades. Sin embargo , no se recomienda tener *.localregistros en el servidor. DNSPor ejemplo digsalidas de advertencia
$ dig docker.local
...
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
...
✅ El dispositivo puede tener múltiples "alias"
Aunque no se recomienda que los nombres se resuelvan correctamente.
✅ Se debe poder acceder al dispositivo de forma remota mediante una VPN alojada en casa
Se accede al DNSservidor mediante una simple solicitud-respuesta, por lo que es totalmente compatible con VPN.
❌ Se debe poder acceder al dispositivo desde una estación de trabajo doméstica conectada a una VPN del trabajo
Esto no funciona porque la estación de trabajo utiliza DNS de trabajo dentro de la VPN que (obviamente) no tiene registros para mi archivo docker.local.
Usar DNSun servidor doméstico con un dominio exclusivo para el hogar personalizado
Este debería ser "el camino a seguir". He creado mi dominio local, por ejemplo. myplace(para evitar sombras *.home) y deje que el servidor DHCP configure este dominio para todos los dispositivos. La idea era utilizar el DNSservidor correctamente.
✅ El dispositivo puede tener múltiples "alias"
Gracias al DNSservidor.
✅ Se debe poder acceder al dispositivo de forma remota mediante una VPN alojada en casa
Se accede al DNSservidor mediante una simple solicitud-respuesta, por lo que es totalmente compatible con VPN.
❌ Se debe poder acceder al dispositivo desde una estación de trabajo doméstica conectada a una VPN del trabajo
Esto no funciona porque la estación de trabajo utiliza DNS de trabajo dentro de la VPN que (obviamente) no tiene registros para mi archivo docker.myplace.
Usar servidor público DNScon dominio público (hasta ahora solo teórico)
También pago por el dominio público, que así sea example.com. La idea es solucionar la tercera necesidad de la solución anterior teniendo, por ejemplo. docker.example.com = 192.168.0.17récord en el público DNS.
✅ El dispositivo puede tener múltiples "alias"
Gracias al DNSservidor.
✅ Se debe poder acceder al dispositivo de forma remota mediante una VPN alojada en casa
Se accede al DNSservidor mediante una simple solicitud-respuesta, por lo que es totalmente compatible con VPN.
✅ Se debe poder acceder al dispositivo desde una estación de trabajo doméstica conectada a una VPN del trabajo
Dado que el dominio público está alojado en DNSun servidor público docker.example.com, debería poder resolverse desde cualquier lugar (como el superuser.comdominio).
sin embargo. Esto es inseguro:
- Expondría todos los nombres de mis dispositivos y sus direcciones IP (domésticas) a Internet.
- Al acceder
docker.example.comdesde fuera de la red doméstica (en el trabajo, cafetería, etc.), me conectaría192.168.0.17ensured local. Esto podría terminar de diferentes maneras.- la dirección no existe - la conexión simplemente falla
- La dirección existe: me estaría conectando al dispositivo de alguien, lo que podría ser muy peligroso (por ejemplo, para conexiones inseguras).
¿Alguien tiene una mejor idea de cómo hacer esto?
Respuesta1
Esto no funciona porque la estación de trabajo utiliza DNS de trabajo dentro de la VPN que (obviamente) no tiene registros para mi docker.myplace.
El DNS doméstico interno funcionaría si su sistema operativo admitiera DNS dividido. Por ejemplo, con systemd-resolved en Linux, hay varios conjuntos de <dominios, servidores DNS> (uno por interfaz de red), de modo que puede tener servidores DNS VPN para dominios de trabajo pero DNS domésticos para todo lo demás, o viceversa. DNS doméstico para ".home.arpa" pero DNS VPN para todo lo demás. Antes de systemd, también era posible configurar dnsmasq o Unbound para lograr lo mismo.
(No debe confundirse con DNS de "cerebro dividido" o "vista dividida", que es una cuestión del lado del servidor).
Windows parece llamar a esto "reenvío condicional" en su software de servidor DNS, ypodríalo admite para el cliente VPN integrado (IKEv2), aunque es poco probable que las VPN corporativas lo permitan.
Expondría todos los nombres de mis dispositivos y sus direcciones IP (domésticas) a Internet.
Es esode hecho¿Es un problema? Los nombres de los dispositivos son, bueno, nombres; no me parecen algo intrínsecamente privado (aunque tal vez tengo una visión algo anticuada, de cuando esto solía ser algo bastante común en las redes domésticas). ; y de todos modos las direcciones IP no tienen significado fuera de la LAN de su hogar.
Sin embargo, siempre puedes tener una combinación de ambos: tener nombres DNS públicos (quizás nombres genéricos como docker) para los pocos dispositivos seleccionados a los que necesitas acceder desde la estación de trabajo, pero usar DNS interno para todo lo demás. Es posible configurar más de un sufijo de dominio en la mayoría de las PC (e incluso implementar una lista a través de DHCP).
Al acceder a docker.example.com desde fuera de la red doméstica (en el trabajo, cafetería, etc.), me conectaría a 192.168.0.17 en su red local. Esto podría terminar de diferentes maneras.
IPv6 sería la "solución" habitual para eso; un prefijo IPv6 privado generado aleatoriamente tendría ~56 bits únicos, lo que suele ser más que suficiente para evitar cualquier colisión.