개인 VPN에서 Discourse 사용: 이메일은 어떻게 되나요?

안녕하세요!

Discourse를 특별한 구성으로 사용하고자 합니다. 웹서버는 VPN 내부의 소수의 알려진 사용자들만 접근할 수 있도록 설정할 예정입니다. 서버 IP가 10.0.0.1과 같은 형태이므로, 유효한 공개 도메인 이름을 사용할 수 없다는 것은 명확합니다.

이메일 전송을 올바르게 설정하는 것이 강력히 권장된다는 내용을 읽었습니다. 또한 이메일 없이 몇 가지 해킹 기법을 통해 관리자 계정 생성을 완료할 수 있다는 것도 읽었습니다.

어떤 방식이 가장 좋은지 궁금합니다.

a) 이메일 없이 Discourse를 완전히 설정하는 방법. 이것이 작동할까요? 아마도 각 계정을 활성화하기 위해 다소 비공식적인 수동 절차를 따라야 할 것 같은데, 예상하는 제한된 사용자 수라면 괜찮습니다. 이것이 작동할까요? 이메일 전송이 작동하지 않을 경우 어떤 제한 사항이 있을까요? 물론 이메일 알림을 보낼 수는 없겠지만(제 입장에서는 상대적으로 작은 단점입니다) - 그것이 전부일까요?

b) 서버가 사설 IP를 사용하더라도, 이메일을 위한 공개 주소를 별도로 가질 수 있을 것입니다. 모든 것이 쉬운 설치를 위해 최적화되어 있을 것이라 기대하므로, 설치 가이드를 따르면서 서버 주소를 한 번만 입력하면 HTTP 리다이렉트 등에 사용될 뿐만 아니라 SMTP에도 사용될 가능성이 높습니다. 이 둘을 쉽게 구분할 수 있을까요? 사설 IP 주소를 가진 서버를 설정하면서, 이메일에만 사용되는 일치하지 않는 도메인을 쉽게 설정할 수 있을까요?

참고로 저는 아직 Discourse에 대한 경험이 없습니다. 실제 문제가 발생하면 스스로 찾아보며 해결할 준비가 되어 있습니다. 하지만 여기서 선택해야 할 근본적인 경로(a 또는 b)가 있다고 보며, 처음부터 잘못된 방향으로 나아가는 것을 피하기 위해 조언을 구하고 싶습니다.

감사합니다!

도메인 이름이 필요합니다. Discourse는 IP 주소로는 실행되지 않습니다.

서버가 인터넷에 접근할 수 있나요? 인터넷 없이 Discourse를 구축하는 것은… 까다로운 작업입니다.

서버가 인터넷에 접근할 수 있다면, 이메일을 보내는 것은 문제가 되지 않습니다.

공개 연결 위에 구축한 후, VPN 내에서 해당 프라이빗 IP에 대한 DNS 항목을 추가하고, 마지막으로 공개 접근을 차단하세요.

Lets Encrypt를 사용하지 마세요. 인증서 업데이트가 실패할 수 있습니다.

쉽게 업데이트할 수 없겠지만, 해당 환경을 격리하는 것이라면 이미 자명했을 것입니다.

이메일은 디스커스에 핵심적인 요소이며, 이메일이 없으면 다양한 기능이 작동하지 않습니다.

도와주려고 노력해 주셔서 감사합니다. 조금 더 자세히 설명해야 할 것 같습니다.

먼저 제가 잘 아는 부분과 잘 모르는 부분을 설명해야겠습니다. :slight_smile: 저층(Low-level) 부분은 꽤 잘 이해하고 있습니다. IP 주소, TCP 등요. 하지만 복잡한 웹 애플리케이션이 수행하는 기능들에 대해서는 경험이 없습니다. 이메일도 마찬가지입니다: 이메일 발신자는 어떻게 인증되며, 어떻게 무단 스팸 메일 전송이 방지되는지 확인하나요? (이 모든 것을 여러분에게 설명해 달라는 것은 아니니, 제 질문을 명확히 하기 위함입니다.)

여기에는 완비된 회사용 VPN 인프라가 없고, 현재 가지고 있는 것은 사설 VPN 서브넷과 IP 레벨 규칙뿐입니다.

구성은 다음과 같습니다: 서버는 공개적으로 도달 가능한 도메인을 가지고 있지만, VPN 진입 지점을 제외한 모든 포트는 닫혀 있습니다. VPN에 연결하는 클라이언트는 10.0.x.x 주소를 부여받습니다. 그런 다음 서버는 10.0.0.1:80에서 도달 가능합니다.

제 이해(아마 여기에서 틀린 것 같습니다)에 따르면, 서버는 자신의 도메인으로 도달 가능하기를 기대하는 것 같습니다.

예를 들어, 공개 IP 8.7.6.5로 해석되는 xyz.com이라는 도메인을 가지고 있다고 가정해 보겠습니다. 클라이언트는 터널에만 이 도메인/IP를 사용합니다. 터널이 설정된 후, 브라우저는 10.0.0.1에 연결합니다.

앞서 말했듯이, 저는 Discourse에 대한 경험이 없습니다. 제가 Discourse가 자신의 도메인을 사용하리라 기대하는 것은 리다이렉트 동작입니다. 예를 들어, 10.0.0.1을 여는 신규 클라이언트를 10.0.0.1/login.php로 전달하는 경우입니다. (또는 유사한 경우, 단순히 예시입니다). 만약 Discourse가 대신 .xyz Domain Names | Join Generation XYZ 리다이렉트한다면, 서버는 VPN 외부에서 도달 불가능하기 때문에 클라이언트는 길을 잃게 될 것입니다. 이것이 내부 주소를 구성해야 한다고 가정하는 유형의 예상 문제입니다.

이메일의 경우, 외부 메일 서버에 연결해야 합니다. 모든 단계에서 공개 인터넷에 도달할 수 있습니다! 이 주제에 대해서는 많이 알지 못합니다. 저는 단순히 "여보세요, 저는 10.0.0.1입니다. 제 메일 몇 통을 보내 주세요"라고 공개 메일 서버에 연결하는 것은 사설 IP 주소를 사용 중이므로 작동하지 않을 것이라고 기대합니다. 여기서는 공개 주소가 필요하다고 가정합니다.

여러분의 답변을 낙관적으로 읽으며, 구성된 도메인은 클라이언트 HTTP 세션에는 사용되지 않는다고 가정합니다. 서버가 사설 IP로 도달 가능하며, 저는 그 IP에 연결하므로, 모든 자기 참조 링크와 리다이렉트는 상대 경로이므로 사용자는 서버가 연결될 것으로 기대하는 도메인으로 리다이렉트되지 않습니다. 저는 xyz.com을 도메인으로 구성하되, 브라우저에서 10.0.0.1로 Discourse를 열 수 있으며, (작동하지 않는) xyz.com 주소로 전달되지 않을 것입니다.

제 질문이 다소 명확하길 바랍니다. 이렇게 혼란스럽게 해서 죄송합니다!
아, 그리고 HTTPS는 필수 사항이 아닙니다. 오히려 사용하지 않는 편을 선호합니다 - 저는 터널 안에 있으며, 사용자들이 안전하게 분리될 필요가 없기 때문입니다. 인증서와 호스트 이름 일치 관련 문제들을 모두 건너뛰고 싶습니다.

이것은 이메일 서버에 따라 다릅니다. MailGun, SendGrid 등의 메일 서비스를 사용한다고 가정해 보겠습니다. 이러한 서비스는 일반적으로 URL과 사용자/비밀번호를 통해 API로 인증합니다.

그곳에서는 서버가 외부 IP에 도달할 수 있는 경우(수신 필터링만 적용되는 경우) 메일 서비스에 연결하는 데 문제가 없어야 합니다.

특히 도메인이 올바른 IP로 해석되는 경우입니다.

VPN을 사용하여 도메인이 개인 IP를 가리키도록 설정하면 VPN 터널을 통해 example.com 도메인에 도달할 수 있으므로, 설치를 위해 포트 열기가 필요하지도 않습니다.

Discourse가 상대적 URL만 사용할지는 확신이 서지 않지만, 그렇지 않을 가능성이 매우 높습니다. 하지만 도메인의 DNS 레코드를 변경하여 두 개의 A 레코드를 만들 수 있습니다. 첫 번째 레코드는 10.0.0.1 주소를, 두 번째 레코드는 8.7.6.5 공용 IP를 가리키도록 설정하는 것입니다. 주소 해석 및 캐시 등에서 다소 까다로울 수 있지만, 시도해 볼 수 있습니다.

xyz.com이 10.0.0.1로 해석되도록 설정할 수 있습니다.

서버가 인터넷에 연결할 수 있다면, 유일한 문제는 Let’s Encrypt HTTPS 인증서를 생성할 수 없다는 것입니다.

여러분께 질문 하나 드리겠습니다. SSL로는 할 수 없는 것 중 VPN이 달성하는 것은 무엇인가요?

SSL로 보호된 초대 전용 디스코urs 인스턴스는 이미 인증과 암호화를 제공합니다. VPN은 여기에 무엇을 더하는 것일까요?

보호가 필요한 다른 서비스들이 실행 중입니다. 비표준 포트 하나만 열어두는 방식도 마음에 듭니다.

하지만 말씀하신 대로, 그 요구 사항을 완화해서 Discourse를 SSL을 사용하여 공개 인터페이스에서 실행하는 방안을 고려해봐야겠습니다.

여러분 모두 감사합니다. 제 문제를 정리해 보았습니다:

  • VPN 내부에서 실행되는 웹서버의 경우, VPN 서버가 DNS 역할도 수행해야 합니다. 내부 DNS는 동일한 도메인을 내부 IP로 해석해야 하며, 이는 대외적으로 외부 IP로 해석됩니다. 그리고 저는 서버 IP를 어디에도 직접 사용하지 않고, 이러한 복잡성을 DNS가 처리하도록 해야 합니다. 현재 제 VPN은 IP 수준에서만 작동하고 있었고, 이러한 세부 사항에 대해 인지조차 하지 못했습니다.
    단점: 모든 사용자의 www를 엉망으로 만들 수 있습니다.
  • 웹서버를 공개 포트에서 실행하고, SSL로 보호를 맡기는 방법도 있습니다.
    단점: 현실 세계의 모든 악의에 노출됩니다.