☰

집에서 여러 애플리케이션 호스팅

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

세 가지 방법 모두 매우 쉽게 작동할 수 있습니다.

문제는 하위 도메인을 허용하는 dyndns 공급자를 찾을 수 없다는 것입니다. 여러 호스트 이름이 허용되지만 하위 도메인은 허용되지 않습니다.

자신만의 도메인을 구입하면 그 아래에 원하는 만큼 하위 도메인을 만들 수 있습니다. 주소를 동적으로 업데이트하는 방법에는 두 가지가 있습니다.

너 스스로해라:자신의 도메인을 구입하고, 어떤 형태의 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.com자동으로 example.dyndns.org의 IP 주소를 얻게 되지만 Nginx는 여전히 귀하가 cloud.example.com을 방문하려고 시도하는 것으로 보고 올바른 서버 블록과 인증서를 선택합니다.{}

이 옵션에는 두 가지 단점이 있습니다. 이제 전체 도메인 구성을 관리하고 있습니다.둘서비스를 제공하며 여전히 IP 주소 업데이트로만 제한됩니다. LE DNS 문제에는 이를 사용할 수 없으므로 와일드카드 인증서는 없습니다.

예를 들어 nextcloud로 작업하면 /nextcloud/가 URL에 없기 때문에 추가 링크가 더 이상 작동하지 않습니다.

대부분의 웹앱은 원하는 기본 URL에서 작동하도록 구성할 수 있습니다. 예를 들어 Nextcloud에는웹루트 덮어쓰기그에 대한 옵션입니다.

따라서 이것의 "더 정확한" 버전은 다음과 같습니다.

redirect 301 https://internalip:port;

아니요, 외부에서 앱에 액세스할 수 있어야 한다면 실제로는 그렇게 해야 합니다.외부주소(및 포트) - 리디렉션의 요점은 클라이언트에서 처리하며 외부 클라이언트는 내부 IP 주소에 연결할 수 없다는 것입니다.

문제는 더 이상 보안 TLS 연결의 이점을 누릴 수 없다는 것입니다.

리디렉션이 동일한 dyndns 도메인의 다른 포트를 가리키는 경우 동일한 인증서를 사용하더라도 동일한 도메인의 여러 포트 모두에서 TLS 서비스를 제공하는 것을 막을 수 없습니다.

일부 웹앱에 TLS용 프런트엔드가 필요한 경우 다른 포트에 더 많은 server{}블록을 사용하여 동일한 Nginx를 구성하면 됩니다 . listen예를 들어 포트 443에서는 리디렉션을 제공할 수 있고, 포트 8443에서는 Nextcloud로 프록시할 수 있습니다 /.

관련 정보