☰

在家託管多個應用程式

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。


1 網域伺服器主機不必與向您出售網域的註冊商位於同一地點 - 所有註冊商都允許您變更網域伺服器位址，因此您可以在 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/。

大多數網頁應用程式都可以設定為在您想要的任何基本 URL 上運行。例如，Nextcloud 有覆蓋webroot選項。

因此，「更正確」的版本是

redirect 301 https://internalip:port;

不，如果您需要從外部存取應用程序，那確實應該是您的外部的位址（和連接埠）－重定向的全部意義在於它們由客戶端處理，外部客戶端將無法連接到您的內部 IP 位址。

問題是，我不再受益於安全的 TLS 連接

如果您的重新導向指向相同 dyndns 網域的不同端口，則沒有什麼可以阻止您在相同網域的所有多個連接埠上提供 TLS，即使使用相同的憑證也是如此。

如果某些 Web 應用程式需要 TLS 前端，則只需在不同連接埠上配置更多server{}區塊的相同 Nginx 即可。listen例如，在連接埠 443 上，您可以提供重新導向服務，在連接埠 8443 上，您可以代理/到 Nextcloud。

相關內容