☰

自宅から複数のアプリケーションをホストする

tag-icon • tag-icon networking dns ssl nginx dynamic-dns
自宅から複数のアプリケーションをホストする

私は自宅からいくつかのアプリケーションをホストしています。現在の「ダーティー」な解決策は、ルーターで複数のポートを転送することです。欠点は、どのポートがどのアプリケーションにサービスを提供しているかを覚えておく必要があることです。さらに、TLS で保護された接続を提供するために、フロントに nginx を必要とするサービス/アプリケーション (例: 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 プロバイダーが見つからないことです。複数のホスト名は許可されますが、サブドメインは許可されません。

独自のドメインを購入すると、その下にサブドメインを好きなだけ作成できます。アドレスを動的に更新するには、次の 2 つの方法があります。

自分でやれ：独自のドメインを購入し、何らかの API を備えた DNS プロバイダーでネームサーバーをホストし、DNS A レコードに十分に低い TTL (例: 5～10 分) が設定されていることを確認するだけで、無制限のサブドメインを持つ独自の「dyndns」が手に入ります。

Certbot/LetsEncrypt コミュニティは、互換性のある (つまり自動化可能な) DNS プロバイダーの優れた情報源になる可能性があります。DNS ベースのチャレンジは、LetsEncrypt からワイルドカード証明書を取得するための要件であるため、いずれにせよこの機能が必要になります。(ワイルドカード証明書が必要なわけではありませんが...)

LE チャレンジの TXT レコードを更新する Certbot と A レコードを更新する dyndns クライアントの間にはほとんど違いがなく、一部の DNS プロバイダーには dyndns アップデーターと互換性のある API もあります。


¹ ネームサーバー ホストは、ドメインを販売したレジストラと同じ場所である必要はありません。すべてのレジストラでネームサーバー アドレスを変更できるため、たとえば、Namecheap でドメインを購入して、Linode や Route53 など、最も便利な場所で DNS をホストすることができます。

² 残っているのは内部DNS プロバイダーのネームサーバー間の伝播遅延 - ほとんどのプロバイダーは、新しいレコードを送信するとすぐにその提供を開始しますが、データベースを 10 ～ 15 分ごとにしかリロードしないプロバイダーもまだあるため、非常に迅速な更新が必要な場合は、それらのプロバイダーに注意してください。


現在のプロバイダーを使用する:独自のドメインを購入し、CNAME レコードを使用して、そのさまざまなサブドメインを既存の dyndns 名に向けます。これには、Dyndns プロバイダー側​​ (CNAME に従うリゾルバーと直接クエリを実行するリゾルバーを区別できない) およびユーザー側 (CNAME の使用は HTTP と TLS の両方で不可視) のいずれにも追加の設定は必要ありません。CNAME レコード自体は更新する必要がないため、通常のネームサーバーでも問題ありません。

CNAMEが設定されている場合、例えばhttps://cloud.example.comexample.dyndns.org の IP アドレスが自動的に取得されますが、Nginx は依然として cloud.example.com にアクセスしようとしていると認識し、正しい server{} ブロックと証明書を選択します。

このオプションには2つの欠点があります。ドメインの構成を二サービスであり、IP アドレスの更新のみに制限されています。LE DNS チャレンジにはこれを使用できない可能性が高いため、ワイルドカード証明書は使用できません。

たとえば nextcloud を使用している場合、URL に /nextcloud/ がないため、それ以降のリンクは機能しなくなります。

ほとんどのウェブアプリは、任意のベースURLで動作するように設定できます。たとえば、Nextcloudにはウェブルートを上書きするそのためのオプションです。

したがって、これの「より正しい」バージョンは次のようになります。

redirect 301 https://internalip:port;

いいえ、アプリを外部からアクセス可能にする必要がある場合は、外部のアドレス (およびポート) - リダイレクトの重要な点は、リダイレクトがクライアントによって処理され、外部クライアントが内部 IP アドレスに接続できなくなることです。

問題は、安全なTLS接続の恩恵を受けられなくなったことです

リダイレクトが同じ dyndns ドメインの異なるポートを指している場合、同じ証明書を使用していても、同じドメインの複数のポートすべてで TLS を提供することを妨げるものは何もありません。

server{}一部の Web アプリケーションで TLS のフロントエンドが必要な場合は、異なるポートでブロックを追加して同じ Nginx を構成するだけですlisten。たとえば、ポート 443 ではリダイレクトを提供し、ポート 8443 では Nextcloud にプロキシすることができます/。

関連情報