Nextcloud는 VPN 전용으로: 먼저 모든 진입점을 조사하세요

VPN 전용 Nextcloud 계획은 브라우저만 보호하고 동기화 클라이언트를 잊으면 실패합니다. 웹 페이지, 데스크톱 동기화 엔진, 모바일 업로드, WebDAV 도구, 공유 링크 수신자 모두 같은 서비스로 가는 경로가 필요하며, 각각 다른 진입점을 노출할 수 있습니다. 무엇이든 닫기 전에 모두 조사하세요. 그 목록이 실제 경계입니다.

체크리스트를 순서대로 진행하세요. 첫 항목은 이 배포에서 프라이빗의 의미를 정의하고, 이후 항목은 배포가 정말 그 정의에 맞는지 시험합니다.

경계를 바꾸기 전에 프라이빗을 정의하세요

요구사항을 한 문장으로 적으세요: 모든 사용자는 애플리케이션에 도달하기 전에 VPN에 가입해야 하거나, 애플리케이션은 공개로 남고 그 원본만 프라이빗으로 유지될 수 있습니다. 서로 다른 설계이며, 프라이빗 터널로 전달하는 공개 리버스 프록시는 두 번째만 충족합니다.

프라이빗 백엔드 주소가 애플리케이션을 프라이빗으로 만들지는 않습니다. 공개 매핑, 두 번째 호스트 이름 또는 IPv6 리스너가 여전히 같은 Nextcloud 인스턴스에 도달한다면 백엔드 위치와 무관하게 진입점은 존재합니다. 서비스를 프라이빗이라고 선언하기 전에 각 이름을 외부에서 시험하세요. DNS 레코드 누락은 닫힌 포트와 같지 않습니다.

의도한 대상도 합의하세요: 직원, 한 가정, 파트너 조직 또는 계정의 일부입니다. 그 답이 공개 공유 링크를 기능으로 볼지 모순으로 볼지 결정합니다. 그 대상을 접근 계획에 적으세요. 이후 모든 예외에 대한 시험입니다.

모든 진입점과 모든 이름을 조사하세요

공개 주소 매핑, 리버스 프록시, 대체 호스트 이름, IPv6 리스너, 그리고 서비스에 도달하는 모든 터널 또는 메시 주소를 나열하고, 그 주소로 해석되는 이름도 포함하세요. 잊힌 DNS 레코드는 친근한 라벨이 붙은 진입점입니다.

프록시 구성에서 전달 헤더와 대체 서버 블록을 확인하세요. 다른 애플리케이션을 위해 추가된 프록시가 경로나 남은 가상 호스트를 통해 같은 업스트림을 노출할 수 있습니다. 의도한 다이어그램이 아니라 실제 구성을 읽으세요. 둘은 애플리케이션을 옮긴 뒤 가장 자주 어긋납니다.

그다음 선택하지 않은 진입점을 차단하세요. 공개 프런트엔드를 가진 프라이빗 백엔드는 VPN 전용 설계가 아니며, IPv4만 처리하는 방화벽 규칙은 IPv6 리스너를 열어 둡니다. 같은 변경에서 두 계열과 두 이름을 모두 닫으세요.

모든 클라이언트에 하나의 서비스 이름을 주세요

프라이빗 DNS를 서비스로 향하게 하고, 그 이름을 VPN으로 라우팅하고, 그에 대한 인증서를 발급하세요. 이름은 프라이빗 경로로 해석되고 경고 없이 검증되어야 합니다. IP에 직접 도달하는 클라이언트도 이름이 동작해야 합니다.

무관한 IP 주소로 연결하는 클라이언트가 설계를 동작시키려고 인증서 오류를 무시할 필요는 없어야 합니다. 안정적인 이름은 주소가 바뀔 때 동기화 클라이언트가 중복 서버 항목을 만드는 것도 막습니다. 프라이빗 서비스와 프라이빗 IP의 차이입니다.

인증서 검증을 활성화한 채로 두세요. 프라이빗 네트워크는 노출을 줄이지만 검증되지 않은 TLS 연결을 수용 가능하게 만들지는 않으며, 경고를 무시하는 데 익숙한 클라이언트는 다른 네트워크에서도 무시합니다.

네트워크 접근을 범위로 제한하고 LAN 전체를 허용하지 마세요

등록된 사용자가 Nextcloud 서비스와 필요한 종속성에 도달하도록 허용하고, 서버 관리는 별도 경로에 두세요. VPN이 클라이언트를 집이나 사무실 네트워크 전체에 들여보내는 경우 그 클라이언트에 애플리케이션이 요구하는 것보다 훨씬 많은 것을 줍니다.

VPN 가입은 Nextcloud 계정, 권한 또는 추가 인증을 대체하지 않습니다. 어떤 사용자가 어떤 파일을 읽을 수 있는지는 여전히 애플리케이션이 결정하며, 네트워크 계층이 유일한 통제가 되어서는 안 됩니다.

승인된 소스 범위와 서비스 포트를 기록하세요. 대상 소유자는 관찰된 소스가 필요하며, NAT 또는 프록시가 요청이 애플리케이션에 도달하기 전에 이를 다시 쓸 수 있습니다.

브라우저 외의 모든 워크플로를 검토하세요

데스크톱 동기화와 모바일 업로드는 각자의 시점에 자체 연결을 엽니다. 연결할 때 승인된 프라이빗 경로가 필요하며, VPN이 없을 때 다르게 동작할 수 있습니다: 재시도, 일시 중지 또는 오류 표시입니다. 브라우저만이 아니라 각각을 시험하세요.

WebDAV 도구와 캘린더 또는 연락처 클라이언트는 자체 구성이 있는 별도 통합입니다. 공개 URL을 캐시하는 클라이언트는 경계 변경 후에도 그 URL을 계속 시도하며, 실패는 애플리케이션 문제처럼 보입니다.

공유 링크에는 명시적 결정이 필요합니다. 링크는 수신자에게 VPN 접근을 주지 않으므로, 진정한 VPN 전용 설계에서는 링크가 유효해도 외부 수신자가 사용할 수 없습니다. 외부 공유가 필요하다면 그것은 자체 접근 경로를 가진 의도적 예외이며, 나중에 발견할 누락이 아닙니다.

페더레이션과 서버 간 통합도 같은 처리가 필요합니다. 그것은 설치 간 도달 가능성 관계이며, 프라이빗 전용 배포는 지원 여부를 밝혀야 합니다.

허용된 경우와 거부된 경우를 모두 받아들이세요

승인된 클라이언트에서 웹 인터페이스와 일반 파일 업로드 또는 다운로드를 확인하세요. 그다음 동기화 클라이언트와 브라우저 외 워크플로 하나를 확인하세요. 브라우저에서만의 성공은 승인이 아닙니다.

승인되지 않은 경로에서 인벤토리의 모든 진입점을 통해 애플리케이션에 도달할 수 없음을 확인하세요. 대체 호스트 이름과 IPv6 주소를 시험하고, 기본 URL만 시험하지 마세요.

마지막으로 네트워크 정책과 혼동하기 쉬운 애플리케이션 설정을 검토하세요. trusted_domains 는 인스턴스가 허용하는 이름을 나열하며, 클라이언트 IP 허용 목록이 아닙니다. 리버스 프록시가 주소 정보를 제공한다면, trusted_proxies 는 실제 프록시를 지정해야 하며 전달 헤더는 그것에서만 허용해야 합니다.

네트워크 변경과 함께 일반적인 강화 작업을 계속하세요: 데이터와 백업을 의도하지 않은 웹 경로 밖에 두고, 애플리케이션을 패치하고, 관리자 접근을 보호하며, 복구를 사용 가능하게 유지하세요. VPN은 진입 표면 하나를 제거하지만 등록된 클라이언트를 신뢰할 수 있게 만들지는 않습니다.