IT/작업기록

시놀로지 NAS + 라우터로 내부 서비스에 서브도메인 연결하기 (IP:포트 대신 도메인으로 접속하기)

aram 2026. 8. 20. 15:34

사내에서 192.168.1.x:8001 같은 IP:포트 조합으로 접속하던 내부 서비스를, 외부에 공개하지 않고도 service.example.com 같은 깔끔한 도메인으로 접속할 수 있게 만든 과정을 정리한다. 시놀로지 라우터(SRM)와 시놀로지 NAS(DSM)를 같이 쓰는 환경 기준이다.

왜 이렇게 하는가

  • 사내 전용 도구라 외부(인터넷)에 노출할 필요는 없음
  • 다만 IP:포트를 외워서 접속하는 게 불편하고, HTTPS도 안 걸려있어 평문 통신이던 상황
  • 외부 접속이 필요한 경우는 이미 VPN으로 커버되고 있어서, 이번 건은 순수 내부망 전용으로 처리

전체 그림

사내 PC → (DHCP로 DNS 서버 안내받음) → NAS의 DNS Server 패키지
        → sales.example.com이 NAS 내부 IP로 풀림
        → NAS의 리버스 프록시 → 실제 서비스 컨테이너(포트)

핵심은 도메인을 공개 DNS(가비아 등)에 등록하지 않고, 사내망 안에서만 해석되게 만드는 것이다. 등록된 진짜 도메인의 서브도메인을 그대로 쓰되, 그 레코드는 오직 내 라우터의 DHCP를 받는 기기들만 알 수 있다.

1단계: NAS에 DNS Server 패키지로 로컬 존 만들기

  1. DSM 패키지 센터에서 DNS Server 설치
  2. DNS Server 앱 → Zone 탭 → 생성 → Primary Zone
    • Domain type: Forward zone
    • Domain name: 실제 보유한 도메인 (예: example.com)
    • Primary DNS server: NAS 자신의 내부 IP
  3. 생성된 존에 A레코드 추가
    • Host: sales (서브도메인 이름)
    • Value: 서비스가 떠 있는 NAS의 내부 IP

 

놓치기 쉬운 부분: Zone만 만들어서는 부족하다. 왼쪽 메뉴의 Resolution 탭에서 "Enable resolution service"가 켜져 있어야 한다. 이게 꺼져 있으면 존/레코드가 다 정상인데도 클라이언트 조회에 응답을 안 한다.

2단계: 라우터가 이 DNS 서버를 쓰도록 지정

라우터(SRM)의 Local Network → DHCP Server 설정에서 Primary DNS를 NAS의 내부 IP로 지정한다.

여기서 제일 많이 헤맨 포인트: 이 칸에 라우터 자기 자신의 IP(기본 게이트웨이 IP)가 그대로 남아있으면, 사내 PC들이 DNS 질문을 라우터한테 하게 되는데, 라우터는 우리가 만든 존을 전혀 모른다. 그래서 nslookup을 해보면 항상 응답 서버가 라우터 IP로 나오고, 도메인을 못 찾는다는 결과가 반복된다. NAS DNS 서버 설정이 다 맞아도 이 한 칸이 틀리면 전부 실패한다.

3단계: 반영 확인

DHCP 설정 변경 후, 사내 PC에서:

ipconfig /release
ipconfig /renew
ipconfig /flushdns
nslookup sales.example.com

서버와 Address에 NAS의 IP가 나오면서, 동시에 sales.example.com의 값도 같이 나오면 성공. 서버 항목이 여전히 라우터 IP라면 2단계 설정이 아직 반영 안 된 것이다.

4단계: 리버스 프록시로 도메인 → 실제 서비스 포트 연결

DSM 제어판 > 로그인 포털 > 고급 > 역방향 프록시에서 규칙 생성:

  • 소스: HTTPS, sales.example.com, 443
  • 대상: HTTP, localhost, 실제 서비스 컨테이너의 포트

5단계: HTTPS 인증서 (내부 전용이라 Let's Encrypt 대신 자체서명)

내부 전용 도메인은 인터넷에서 도메인 검증이 안 되므로 Let's Encrypt 발급이 불가능하다. 대신 자체서명 인증서를 만든다.

DSM 최신 버전은 인증서 생성 마법사에 "자체서명 생성" 버튼이 없고 Import만 있는 경우가 있다. 이럴 땐 직접 만들어서 넣으면 된다:

openssl req -x509 -nodes -newkey rsa:2048 -keyout sales.key -out sales.crt -days 3650 -subj "/CN=sales.example.com"

생성된 .key, .crt를 인증서 Import 화면에 넣고, 리버스 프록시 규칙에 이 인증서를 연결한다. 자체서명이라 브라우저에서 보안 경고가 뜨는 건 정상이며, "고급 > 계속 진행"으로 넘기면 된다.

6단계: 애플리케이션 쪽 호스트 화이트리스트 확인

Django라면 ALLOWED_HOSTS, 다른 프레임워크도 비슷한 보안 설정이 있다. 새로 만든 도메인(sales.example.com)이 이 목록에 없으면, 리버스 프록시까지는 정상 도달해도 애플리케이션이 400 Bad Request로 거부한다. 기존에 IP로만 접속하던 걸 도메인으로 바꾸는 거라, 이 설정에 반드시 새 도메인을 추가해야 한다.

가능하면 하드코딩보다는 환경변수로 관리해서, 코드 배포(git push) 없이 컨테이너 환경변수만 바꾸고 재시작하는 걸로 끝낼 수 있게 하는 게 편하다.

정리: 막혔던 지점 순서대로

  1. Resolution 서비스가 기본적으로 꺼져 있어 응답 자체를 안 함
  2. DHCP Primary DNS가 라우터 자신을 가리키고 있어 새 존을 안 탐
  3. http://로 접속하면 리버스 프록시(443 전용 규칙)를 안 타고 기본 웹 페이지가 뜸
  4. 애플리케이션의 호스트 화이트리스트에 새 도메인이 없어 400 에러

전부 "설정은 맞는데 그 앞/뒤 단계 하나가 막혀서" 생기는 문제라, 각 단계마다 nslookup이나 직접 접속으로 검증하고 넘어가는 게 시간을 아끼는 길이다.