☰

在家托管多个应用程序

tag-icon • tag-icon networking dns ssl nginx dynamic-dns
在家托管多个应用程序

我在家里托管了几个应用程序。我目前的“肮脏”解决方案是，在路由器中转发多个端口。缺点是，我必须记住哪些端口服务于哪个应用程序。此外，有些服务/应用程序需要前端的 nginx 来提供 TLS 安全连接，即 nextcloud。

我想把一切都清理干净。理想的解决方案是获取 letsencrypt 通配符证书，并在 nginx 中使用类似以下内容（简化的伪配置）：

server {
    server_name nextcloud.mydyndnsdomain.org;
    location / {
        proxy_pass https://internalip:port;
    }
}
server {
    server_name someotherapplication.mydyndnsdomain.org;
    location / {
        proxy_pass https://internalip:anotherport;
    }
}

问题是，我找不到允许子域名的 dyndns 提供商。允许多个主机名，但不允许子域名。

我想到另一个解决方案是这样的：

server {
    server_name mydyndnsdomain.org;
    location /nextcloud/ {
        proxy_pass https://internalip:port;
    }
    location /someotherapplication/ {
        proxy_pass https://internalip:anotherport;
    }
}

问题是，当我使用 nextcloud 等链接时，其他链接不再起作用，因为/nextcloud/URL 中缺少 。因此，“更正确”的版本应该是

server {
    server_name mydyndnsdomain.org;
    location /nextcloud/ {
        redirect 301 https://internalip:port;
    }
    location /someotherapplication/ {
        redirect 301 https://internalip:anotherport;
    }
}

问题是，我不再受益于安全的 TLS 连接，而且我仍然必须在路由器中进行端口转发等等。

或者当然，我在 dyndns 提供商处注册了多个主机名。但这样一来，我又需要多个证书，并且主机名数量也受到限制。而且必须记住哪个应用程序在哪个主机名下提供服务。

所以我的问题是，其他人是怎么做到的？推荐的解决方案是什么？还是我对 nginx 技能的了解不够深入？

答案1

所有这 3 种方法都可以相当轻松地发挥作用。

问题是，我找不到允许子域名的 dyndns 提供商。允许多个主机名，但不允许子域名。

购买您自己的域名，然后您就可以在其下创建任意数量的子域名。有两种方法可以使其动态更新地址：

自己做：购买您自己的域名，将其名称服务器托管在具有某种形式 API 的 DNS 提供商处，确保 DNS A 记录上配置了足够低的 TTL（例如 5-10 分钟），就这样 – 您拥有具有无限子域的自己的“dyndns”。

Certbot/LetsEncrypt 社区可能是兼容（即可自动化）DNS 提供商的良好来源，因为基于 DNS 的质询是从 LetsEncrypt 获取通配符证书的必要条件，因此无论如何您都需要此功能。（实际上，您不需要通配符证书...）

Certbot 更新 LE 挑战的 TXT 记录和 dyndns 客户端更新 A 记录之间几乎没有区别，一些 DNS 提供商甚至具有与 dyndns 更新程序兼容的 API。


¹ 名称服务器主机不必与向您出售域名的注册商位于同一位置 - 所有注册商都允许您更改名称服务器地址，因此您可以在 Namecheap 购买域名，但在 Linode 或 Route53 或其他最方便的地方托管 DNS。

² 唯一剩下的就是内部的DNS 提供商的名称服务器之间的传播延迟 – 虽然大多数提供商会在您提交新记录后立即开始提供新记录，但仍有一些提供商每 10-15 分钟才重新加载一次数据库，因此如果您需要极快速的更新，请留意这些提供商。


使用当前提供商：购买您自己的域名，使用 CNAME 记录将其各个子域指向您现有的 dyndns 名称。这不需要任何额外的设置，无论是 Dyndns 提供商方面（他们无法区分遵循 CNAME 的解析器和仅进行直接查询的解析器），还是您方面（CNAME 的使用对 HTTP 和 TLS 都是不可见的）。任何常规名称服务器也可以这样做，因为 CNAME 记录本身不需要更新。

当 CNAME 到位时，当您访问例如https://cloud.example.com您将自动获取 example.dyndns.org 的 IP 地址，但 Nginx 仍会将您视为尝试访问 cloud.example.com 并选择正确的服务器{} 块和证书。

此选项有两个缺点：您现在正在管理域的配置二服务，并且您仍然仅限于 IP 地址更新 —— 您很可能无法将其用于 LE DNS 挑战，因此无法为您提供通配符证书。

例如，当我使用 nextcloud 时，其他链接就不再起作用，因为 URL 中缺少 /nextcloud/。

大多数 Web 应用可以配置为在您想要的任何基本 URL 上进行自我引导。例如，Nextcloud 具有覆盖网页根目录选项。

因此，“更正确”的版本应该是

redirect 301 https://internalip:port;

不，如果你需要从外部访问应用程序，那真的应该是你的外部的地址（和端口）——重定向的全部意义在于它们由客户端处理，外部客户端将无法连接到您的内部 IP 地址。

问题是，我不再受益于安全的 TLS 连接

如果您的重定向指向同一个 dyndns 域的不同端口，那么没有什么可以阻止您在同一域的所有多个端口上提供 TLS，即使使用相同的证书。

如果某些 Web 应用需要 TLS 前端，则只需在同一个 Nginx 上配置更多server{}块，这些块listen位于不同的端口上。例如，您可以在端口 443 上提供重定向，在端口 8443 上可以代理/到 Nextcloud。

相关内容