NAS에 외부에서 접속하려면 공유기에 포트를 열고 DDNS나 도메인을 연결해야 한다고 생각하기 쉽다.
공개 웹사이트처럼 불특정 사용자가 접근해야 하는 서비스라면 인터넷에서 도달 가능한 공개 경로가 필요하다.
하지만 DSM 관리화면, SSH, 내부 개발도구처럼 내 장치나 허가된 사용자만 접근하면 되는 서비스까지 모두 공개 인터넷에 노출할 필요는 없다.
Tailscale 같은 mesh VPN은 이 두 종류의 접속을 분리하는 데 특히 유용하다.
먼저 Public Service와 Private Administration을 나눈다
| 접속 유형 | 예시 | 필요한 접근 |
|---|---|---|
| Public | 공개 WordPress 사이트 | 인터넷 사용자 누구나 |
| Private | DSM·SSH·관리 DB | 승인된 사용자/장치만 |
| Mixed | Jellyfin 등 | 사용자 범위에 따라 설계 |
공개서비스와 관리서비스를 같은 방식으로 노출하면 관리포트까지 인터넷 공격면에 포함될 수 있다.
그래서 먼저 “외부접속이 필요한가?”가 아니라 누가 접근해야 하는가?를 묻는 것이 좋다.
Tailscale은 장치를 하나의 Private Network처럼 연결한다
Tailscale은 WireGuard 기반으로 tailnet에 등록된 장치 사이에 암호화된 연결을 만든다.
NAS와 노트북이 같은 tailnet에 있으면 집 밖에서도 Tailscale 주소나 이름을 이용해 NAS에 접근할 수 있다.
관리목적으로 사용한다면 공유기에서 DSM이나 SSH port를 인터넷 전체에 직접 forward하지 않고도 접근경로를 만들 수 있다.
Direct와 Relay는 주로 성능경로의 차이다
같은 private network 안에서도 실제 데이터가 이동하는 경로는 연결상태에 따라 달라질 수 있다. NAS 전송속도가 기대보다 낮다면 VPN 사용 여부만 보는 대신 현재 연결이 직접경로인지 중계경로인지 먼저 확인해야 원인을 좁힐 수 있다. 중계경로라는 사실 자체를 보안 실패로 해석하기보다 성능과 연결조건을 분리해서 보는 것이 핵심이다.
현재 Tailscale은 가능한 경우 두 장치 사이에 direct peer-to-peer 연결을 만든다.
네트워크 조건 때문에 direct 연결이 불가능하면 Peer Relay 또는 DERP relay가 사용될 수 있다.
모든 연결은 end-to-end encrypted 상태를 유지하지만 성능은 달라질 수 있다.
일반적으로:
Direct > Peer Relay > DERP Relay
순으로 throughput과 latency 측면에서 유리한 경우가 많다.
집에서는 빠른데 외부 Tailscale SMB 전송이 느리다고 하자.
바로 NAS CPU가 부족하다고 결론 내리기 전에:
- 양쪽 인터넷 회선의 upload/download
- Direct인지 Relay인지
- Wi-Fi 품질
- SMB 자체 overhead
를 확인해야 한다.
Tailscale 공식 문서에서도 tailscale status나 tailscale ping을 통해 direct 또는 relay 연결 여부를 확인할 수 있다고 안내한다.
DERP를 거친다고 해서 VPN 암호화가 해제되는 것은 아니다.
Relay는 두 endpoint가 직접 연결되지 못할 때 encrypted packet을 전달하는 중계경로다.
따라서 relay 사용은 주로 성능문제로 이해해야 한다.
DSM 7에서는 Synology의 Tailscale 동작방식을 하나 더 알아야 한다
현재 Tailscale 공식 Synology 문서에 따르면 DSM 7에서는 Package 권한제약 때문에 기본 설치 상태에서 NAS로 들어오는 Tailscale 연결은 가능하지만, NAS에서 실행되는 다른 애플리케이션이 tailnet으로 outbound 연결하는 기능은 기본적으로 활성화되지 않는다.
NAS 자신이 다른 tailnet 장치에 접속해야 한다면 TUN device 사용을 위한 별도 설정이 필요할 수 있다.
즉:
- 노트북 → NAS 접속
- NAS application → 다른 Tailscale 장치 접속
은 운영상 같은 요구사항이 아니다.
Private network 안에서도 최소권한을 적용한다
Private network를 사용한다고 해서 모든 장치와 모든 NAS 서비스에 같은 접근권한을 줄 필요는 없다. 관리용 DSM·SSH와 제한된 사용자 서비스는 필요한 대상과 권한을 분리할수록 운영상 실수의 범위를 줄일 수 있다. 즉 private access는 공개노출을 줄이는 수단이고, 권한설계는 그 안에서 별도로 해야 할 통제다.
VPN은 네트워크 접근범위를 줄이는 데 도움을 준다.
하지만 NAS 계정의 약한 password, 과도한 admin 권한, 업데이트되지 않은 서비스까지 해결하는 것은 아니다.
최소한 다음 통제는 별도로 필요하다.
- 관리자 계정 최소화
- MFA 적용 가능 여부 검토
- 장치와 사용자별 access policy
- 불필요한 서비스 비활성화
- DSM 및 Package 보안 업데이트
장치가 tailnet 안에 있다고 모든 장치가 NAS의 모든 port에 접근하도록 열어둘 이유는 없다.
운영환경에서는 사용자·장치·서비스 역할에 따라 access control을 나누는 편이 낫다.
예를 들면:
- 관리자 노트북 → DSM/SSH 허용
- 가족 장치 → Jellyfin만 허용
- 서버 → 필요한 DB/API port만 허용
처럼 private network 안에서도 최소권한 원칙을 적용할 수 있다.
Tailscale과 Reverse Proxy는 경쟁기술이 아니다
Reverse Proxy는 하나의 공개 endpoint에서 domain과 path에 따라 여러 web service로 traffic을 전달하는 역할을 할 수 있다.
Tailscale은 승인된 장치끼리 private connectivity를 제공하는 데 강점이 있다.
따라서:
- 공개 WordPress → public reverse proxy/Cloudflare 등
- DSM·SSH → Tailscale private access
처럼 목적에 따라 함께 사용할 수 있다.
‘포트포워딩 없음’ 자체를 목표로 삼을 필요는 없다
모든 port forwarding이 나쁘고 VPN만 정답이라는 뜻은 아니다.
공개 웹서비스를 운영한다면 외부에서 도달 가능한 ingress가 필요하다.
핵심은 공개해야 하는 서비스만 공개하는 것이다.
DSM과 SSH까지 public internet에 열어놓고 firewall rule로만 방어하는 것보다 관리평면 자체를 private overlay network 안에 두는 방식이 attack surface를 줄이는 데 도움이 된다.
결론
NAS 외부접속을 설계할 때 “포트포워딩 vs Tailscale”이라는 하나의 선택으로 보면 안 된다.
먼저 서비스를:
Public Service / Private Administration / Limited User Service
로 나눈다.
그 다음 공개서비스에는 필요한 public ingress를 제공하고, DSM·SSH 같은 관리접속은 가능한 경우 private access로 분리한다.
Tailscale의 가치는 단순히 포트를 열지 않는 편의기능이 아니라 NAS의 관리평면을 인터넷 공개서비스와 분리할 수 있다는 것에 있다.