Estoy alojando varias aplicaciones desde casa. Mi solución "sucia" actual es reenviar varios puertos en mi enrutador. La desventaja es que tengo que recordar qué puertos sirven para qué aplicación. Además, hay servicios/aplicaciones que necesitan un nginx en el frente para proporcionar conexiones seguras TLS, es decir, nextcloud.
Me gustaría limpiar las cosas. La solución ideal sería obtener un certificado comodín letsencrypt y en nginx tener algo como (pseudo configuración abreviada):
server {
server_name nextcloud.mydyndnsdomain.org;
location / {
proxy_pass https://internalip:port;
}
}
server {
server_name someotherapplication.mydyndnsdomain.org;
location / {
proxy_pass https://internalip:anotherport;
}
}
El problema es que no puedo encontrar un proveedor de Dyndns que permita subdominios. Se permiten varios nombres de host, pero no subdominios para ellos.
Otra solución en la que pensé sería algo como esto:
server {
server_name mydyndnsdomain.org;
location /nextcloud/ {
proxy_pass https://internalip:port;
}
location /someotherapplication/ {
proxy_pass https://internalip:anotherport;
}
}
El problema es que una vez que estoy trabajando, por ejemplo, con nextcloud, otros enlaces ya no funcionan, ya que /nextcloud/faltan en la URL. Por lo tanto, la versión "más correcta" de esto sería
server {
server_name mydyndnsdomain.org;
location /nextcloud/ {
redirect 301 https://internalip:port;
}
location /someotherapplication/ {
redirect 301 https://internalip:anotherport;
}
}
El problema es que ya no me beneficio de una conexión TLS segura y todavía tengo que reenviar el puerto en el enrutador y así sucesivamente.
O, por supuesto, registro varios nombres de host en mi proveedor de Dyndns. Pero luego volvería a necesitar varios certificados y estaría limitado a una cierta cantidad de nombres de host. Y hay que recordar qué aplicación se sirve con qué nombre de host.
Entonces mi pregunta es, ¿cómo hacen esto otras personas? ¿Cuál es la solución recomendada? ¿O hay algo que no entendí bien con mis pobres habilidades con nginx?
Respuesta1
Se puede hacer que los 3 métodos funcionen con bastante facilidad.
El problema es que no puedo encontrar un proveedor de Dyndns que permita subdominios. Se permiten varios nombres de host, pero no subdominios para ellos.
Compra tu propio dominio y luego podrás crear tantos subdominios como quieras. Hay dos formas de hacer que actualice las direcciones dinámicamente:
Hazlo tu mismo:Compre su propio dominio, aloje sus servidores de nombres en un proveedor de DNS que tenga algún tipo de API, asegúrese de que los registros DNS A tengan configurado un TTL suficientemente bajo (por ejemplo, de 5 a 10 minutos) y eso es todo: tendrá sus propios "dyndns". " con subdominios ilimitados.
La comunidad Certbot/LetsEncrypt podría ser una buena fuente de proveedores de DNS compatibles (es decir, automatizables), ya que los desafíos basados en DNS son un requisito para obtener un certificado comodín de LetsEncrypt, por lo que necesitaría esta funcionalidad de todos modos. (No es que necesites un certificado comodín, de verdad...)
Hay muy poca diferencia entre Certbot que actualiza registros TXT para desafíos LE y un cliente Dyndns que actualiza registros A, y algunos proveedores de DNS incluso tienen una API compatible con los actualizadores de Dyndns.
¹ El host del servidor de nombres no tiene que ser el mismo lugar que el registrador que le vendió el dominio; todos los registradores le permiten cambiar las direcciones del servidor de nombres, por lo que puede, por ejemplo, comprar un dominio en Namecheap pero alojar DNS en Linode o Route53 o cualquier otra cosa. es lo más conveniente.
² Lo único que queda es elinternoretraso en la propagación entre los servidores de nombres del proveedor de DNS: si bien la mayoría de los proveedores comienzan a servir los nuevos registros tan pronto como los envía, todavía hay algunos que solo recargan sus bases de datos cada 10 a 15 minutos, así que tenga cuidado con ellos si necesita actualizaciones extremadamente rápidas.
Utilice el proveedor actual:Compre su propio dominio, use registros CNAME para apuntar sus diversos subdominios hacia su nombre de Dyndns existente. Esto no requiere ninguna configuración adicional, ni por parte del proveedor de Dyndns (no pueden distinguir un solucionador que sigue un CNAME de uno que simplemente realiza una consulta directa), ni por su parte (el uso de CNAME es invisible tanto para HTTP como para TLS). Cualquier servidor de nombres normal también servirá, porque los registros CNAME en sí no necesitan actualización.
Cuando el CNAME está implementado, cuando visitas, por ejemplohttps://nube.ejemplo.comObtendrá automáticamente la dirección IP de ejemplo.dyndns.org, pero Nginx seguirá viendo que intenta visitar cloud.example.com y elegirá el bloque y certificado de servidor{} correctos.
Esta opción tiene dos desventajas: ahora estás administrando la configuración del dominio endosservicios, y todavía está limitado a actualizaciones de direcciones IP únicamente; lo más probable es que no pueda usar esto para desafíos LE DNS, por lo que no hay ningún certificado comodín para usted.
Una vez que estoy trabajando, por ejemplo, con nextcloud, otros enlaces ya no funcionan, ya que falta /nextcloud/ en la URL.
La mayoría de las aplicaciones web se pueden configurar para que aparezcan en cualquier URL base que desee. Por ejemplo, Nextcloud tiene lasobrescribir raíz webopción para eso.
Por lo tanto, la versión "más correcta" de esto sería
redirect 301 https://internalip:port;
No, si necesita que se pueda acceder a las aplicaciones desde el exterior, esa debería ser su decisión.externodirección (y puerto): el objetivo de las redirecciones es que son manejadas por el cliente y los clientes externos no podrán conectarse a su dirección IP interna.
El problema es que ya no me beneficio de una conexión TLS segura
Si sus redireccionamientos apuntan a diferentes puertos del mismo dominio dyndns, entonces no hay nada que le impida ofrecer TLS en todos esos puertos múltiples del mismo dominio, incluso usando el mismo certificado.
Si algunas aplicaciones web necesitan una interfaz para TLS, simplemente configure el mismo Nginx con más server{}bloques listenen diferentes puertos. Por ejemplo, en el puerto 443 puede servir redirecciones y en el puerto 8443 puede enviar proxy /a Nextcloud.