[네트워크] VPN Tailscale 마이그레이션으로 NAS 원격 접속 바꾸는 법

기존 VPN을 오래 쓰신 분들이라면 한 번쯤 이런 순간이 옵니다. 집 밖에서 NAS에 붙으려는데 포트포워딩(Port Forwarding, 공유기에서 외부 요청을 내부 장비로 넘기는 설정) 상태를 다시 확인해야 하고, 인증서나 키 파일이 어디 있었는지 찾게 되고, 모바일에서는 또 프로파일이 꼬여 있더라고요. 저도 OpenVPN을 꽤 오래 썼고, WireGuard도 직접 올려서 운영했었는데, 결국 홈랩과 NAS 원격 접속 환경은 VPN Tailscale 마이그레이션 쪽으로 정리하게 됐습니다. 처음엔 “이게 그렇게까지 편한가?” 싶었는데, 실제로 써보니까 관리 포인트가 확 줄었습니다.

특히 NAS 원격 접속이 목적이라면, 단순히 연결만 되는 것보다 운영 피로도가 중요합니다. 가족 계정, 제 노트북, 아이패드, 테스트용 VM까지 장비가 늘어나면 기존 VPN은 언젠가 손이 많이 가기 시작하거든요. 이번 글에서는 OpenVPN Tailscale 전환, WireGuard Tailscale 이전을 고민하는 분들을 위해, 제가 직접 정리하면서 부딪혔던 포인트까지 포함해서 현실적인 마이그레이션 가이드를 적어보겠습니다.

기존 VPN 서버 중심 구조와 Tailscale 기반 장치 간 연결 구조를 한눈에 보여주는 개요 이미지입니다.

왜 기존 VPN에서 Tailscale로 옮기게 되나

쉽게 말해, 기존 VPN은 내가 서버를 운영하는 느낌이 강하고, Tailscale은 장치들을 하나의 사설 네트워크처럼 묶어 관리하는 느낌입니다. 물론 OpenVPN이든 WireGuard든 지금도 충분히 좋은 기술입니다. 문제는 운영 난이도거든요.

• OpenVPN: 성숙하고 자료가 많지만, 인증서 관리와 클라이언트 배포가 번거로운 편입니다.
• WireGuard: 설정은 간결하지만, 피어(Peer, 연결 대상 장치) 수가 늘어나면 키와 설정 동기화가 귀찮아질 수 있어요.
• Tailscale: WireGuard 기반 기술을 활용하면서도 장치 등록, 접근 제어, 상태 확인이 훨씬 간단합니다.

제가 직접 해보니, 성능 그 자체보다도 “다음 달의 나”가 덜 고생하는가가 더 중요하더라고요. 홈랩은 처음 세팅할 때보다, 6개월 뒤 유지보수할 때 본색이 드러나거든요.

OpenVPN, WireGuard, Tailscale 차이 한 번에 보기

여기서 중요한 포인트가 하나 있습니다. Tailscale이 기존 VPN을 기술적으로 완전히 대체한다기보다는, NAS 원격 접속 변경 관점에서 훨씬 관리하기 쉬운 형태로 추상화해준다고 보는 편이 정확합니다.

Tailscale 핵심 개념, 쉽게 말해 뭐가 달라지나

저도 처음엔 헷갈렸는데, 쉽게 말해 Tailscale은 장치마다 클라이언트를 설치하고 같은 네트워크 그룹에 묶어주는 방식입니다. 예전처럼 “외부에서 VPN 서버 하나에 먼저 들어간 뒤 내부망으로 이동”하는 사고방식에서, “허가된 장치끼리 안전하게 직접 통신”하는 쪽으로 바뀌는 거죠.

1. Tailnet(테일넷, Tailscale 네트워크 그룹)

같은 계정 또는 조직 아래 등록된 장치들이 묶이는 논리적 네트워크입니다. 제 경우엔 노트북, 스마트폰, 맥미니, NAS를 한 그룹으로 관리하니까 장치 찾기가 훨씬 쉬웠어요.

2. Node(노드, 네트워크에 참여한 장치)

NAS도 노드가 되고, 노트북도 노드가 됩니다. 각 장치는 보통 고유한 사설 주소와 이름을 받아서 접근할 수 있게 돼요.

3. ACL(Access Control List, 접근 제어 목록)

누가 누구에게 접근 가능한지 정하는 정책입니다. 이걸 잘 써두면 가족용 장치와 운영 장비를 분리하기 좋아요. 저도 처음에는 “일단 다 열어놓고 쓰자” 했다가, 나중에 다시 정리하느라 삽질 좀 했습니다. 처음부터 최소 권한으로 가는 게 낫습니다.

4. Subnet Router(서브넷 라우터, 기존 내부망 중계 장치)

NAS에 직접 Tailscale을 설치하지 못하는 환경이라면, 같은 내부망의 작은 리눅스 장비나 미니 PC를 중계 장치로 둘 수 있습니다. 구형 NAS에서 특히 유용해요.

VPN Tailscale 마이그레이션 전에 체크할 것

1. 현재 접속 방식 파악
   OpenVPN 서버인지, WireGuard 서버인지, 아니면 공유기 내장 VPN인지 먼저 정리합니다. 마이그레이션은 기술보다 현황 파악이 반입니다.
2. NAS에 직접 설치 가능한지 확인
   지원 패키지가 있거나 컨테이너(Container, 격리 실행 환경)로 우회 가능한지 봅니다. 불확실하면 서브넷 라우터 방식을 고려하세요.
3. 기존 VPN 종료 시점 분리
   이게 중요합니다. 기존 VPN을 바로 내리면 안 됩니다. 최소 하루에서 며칠은 병행 운영하세요.
4. 접속 대상 정리
   NAS 웹 관리 화면, SMB, SSH, 백업 에이전트 같은 실제 사용 경로를 적어두면 테스트가 훨씬 빨라져요.
5. 계정 정책 정리
   개인 계정으로만 쓸지, 가족/팀 멤버를 초대할지 미리 생각해두면 ACL 설계가 수월합니다.

이 단계는 좀 지루하지만, 실무에서도 그렇고 홈랩에서도 그렇고 여기 건너뛰면 뒤에서 더 오래 헤맵니다.

Tailscale 설정 가이드: NAS 원격 접속 단계별 이전

이제 본론입니다. 아래 순서는 제가 실제로 권장하는 흐름입니다. 핵심은 기존 VPN은 살아 있게 두고, 새 경로를 먼저 검증한 뒤 마지막에 전환하는 거예요.

1. 클라이언트 장치부터 Tailscale 설치

먼저 내 노트북이나 스마트폰에 Tailscale을 설치해서 네트워크가 어떤 느낌인지 보는 게 좋습니다. 서버보다 클라이언트부터 붙여보는 게 감을 잡기 쉽거든요.

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

설치 후 브라우저 로그인 절차가 나오면 계정 인증을 마칩니다. 장치가 등록되면 상태를 확인해봅시다.

tailscale status
tailscale ip -4

여기서 장치명이 잘 보이면 1차 성공입니다. 드디어 됐다 싶은 순간이 이때 옵니다.

2. NAS에 직접 설치하거나, 안 되면 우회 경로 준비

가장 이상적인 건 NAS 자체를 Tailscale 노드로 등록하는 거예요. 다만 NAS 모델과 운영체제에 따라 방법이 다릅니다. 패키지 지원이 있으면 그대로 쓰고, 없으면 같은 네트워크 대역에 있는 리눅스 장비를 Subnet Router로 구성하면 돼요.

예를 들어 리눅스 장비를 중계로 둘 때는 대략 이런 흐름입니다.

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up --advertise-routes=192.168.0.0/24

이후 관리 화면에서 광고된 라우트(Route, 경로)를 승인하면, Tailnet 안의 장치가 해당 내부망으로 들어갈 수 있어요. 즉, NAS에 직접 Tailscale이 없어도 내부 IP로 접속이 가능해지는 거죠.

NAS에 직접 에이전트를 올리는 방식과 별도 리눅스 장비를 중계로 두는 방식을 비교하는 설명 이미지입니다.

3. NAS 접근 대상별로 실제 접속 테스트

여기서부터는 단순히 핑(Ping, 연결 확인 신호)만 보면 안 돼요. 실제로 내가 쓰는 프로토콜이 붙어야 합니다.

1. NAS 관리 페이지 접속
2. SMB 또는 AFP 같은 파일 공유 접속
3. SSH 사용 시 원격 셸 접속
4. 백업 도구나 동기화 앱 연결 확인

예를 들어 SSH부터 확인하면 가장 단순해요.

ping <nas-or-router-tailnet-name>
ssh user@<nas-or-router-tailnet-name>

서브넷 라우터 방식이라면 내부 IP로 붙는 테스트도 해봅시다.

ping 192.168.0.10
ssh [email protected]

제가 실제로 써보니까, 브라우저 접속은 되는데 SMB가 안 되는 경우가 있었어요. 이런 건 대부분 라우팅이나 방화벽(Firewall, 트래픽 차단 규칙) 문제더라고요. “웹은 되니까 끝”이 아니라, 내가 쓰는 모든 경로를 꼭 따져봐야 합니다.

4. 최소 권한 기준으로 ACL 정리

혼자 쓰는 홈랩이면 처음엔 널널하게 열어도 되지만, 결국 다시 정리하게 될 거예요. 예시 수준으로 보면 아래처럼 특정 사용자 그룹만 NAS 대역에 접근하도록 정책을 둘 수 있습니다.

# Example concept only
# Grant admin group access to NAS subnet
acls:
  - action: accept
    src:
      - group:admins
    dst:
      - 192.168.0.0/24:*

정책 문법은 환경에 따라 다듬어야 하니, 운영 반영 전에는 테스트 장치로 먼저 검증하세요. 여기서 중요한 건 “모든 장치가 모든 장치에 붙을 필요는 없다”는 점이에요.

5. 기존 OpenVPN 또는 WireGuard와 병행 운영

이 단계가 진짜 중요합니다. OpenVPN Tailscale 전환이든 WireGuard Tailscale 이전이든, 바로 갈아타면 꼭 하나씩 빠지는 접속 경로가 생겨요. 저는 최소 이 순서로 갔습니다.

1. Tailscale 설치 및 장치 등록
2. NAS 또는 서브넷 라우터 연결 확인
3. 웹, 파일공유, SSH 테스트
4. 모바일 외부망 테스트
5. 자동 백업/동기화 테스트
6. 문제 없으면 기존 VPN 신규 접속만 중단
7. 며칠 관찰 후 기존 VPN 완전 종료

이렇게 하면 장애가 나도 바로 롤백(Rollback, 이전 상태로 복귀)할 수 있어요.

⚠️ 마이그레이션하면서 자주 만나는 문제

여기부터가 진짜 실전입니다. 문서만 보면 다 쉬워 보이는데, 현장에선 늘 변수가 있거든요.

문제 1. NAS는 보이는데 서비스 접속이 안 됩니다

원인은 보통 셋 중 하나예요.

• NAS 자체 방화벽이 Tailscale 경로를 허용하지 않음
• 서브넷 라우터는 붙었지만 경로 승인이 안 됨
• 서비스가 특정 인터페이스만 바인딩(Binding, 네트워크 인터페이스에 연결)됨

해결은 단순해요. 먼저 핑, 그다음 SSH, 그다음 웹, 마지막으로 SMB 순서로 작게 쪼개서 확인하세요. 한 번에 다 보려 하면 오히려 더 헷갈려요.

문제 2. 모바일에서는 되는데 노트북에서는 안 됩니다

저도 이걸 한 번 겪었는데, 회사 네트워크 정책이나 로컬 방화벽 영향일 때가 많았어요. 특히 사내 보안 에이전트가 있는 장비는 예상과 다르게 동작할 수 있습니다. 개인 장비와 회사 장비를 구분해서 테스트하세요.

문제 3. 기존 WireGuard보다 덜 직관적으로 느껴집니다

맞습니다. 설정 파일을 내가 다 쥐고 있던 방식에서 관리형 인터페이스로 넘어가면 처음엔 답답할 수 있어요. 근데 며칠 지나면 장치 추가와 정책 수정이 훨씬 편하다는 걸 체감하게 돼요. 처음의 낯섦과 장기 운영 편의성은 별개더라고요.

문제 4. 기존 VPN과 동시에 켜놓으니 경로가 꼬입니다

이건 충분히 가능한 증상이에요. 같은 내부 대역으로 들어가는 경로가 둘 이상이면 OS 라우팅 우선순위에 따라 엉뚱한 쪽으로 갈 수 있어요. 병행 운영 중에는 테스트 장비를 정해서 사용하고, 어느 경로를 타는지 꼭 확인하세요.

ip route
netstat -rn

운영체제에 따라 명령은 다를 수 있지만, 핵심은 “내 패킷이 어디로 가는지”를 보는 거예요. 네트워크는 감으로 보면 꼭 틀립니다.

핑, SSH, 웹 접속, 파일 공유 테스트 순서를 시각적으로 정리한 트러블슈팅 이미지입니다.

검증: NAS 원격 접속 변경이 제대로 끝났는지 확인하는 방법

마이그레이션이 끝났다고 말하려면, 단순 연결이 아니라 사용 시나리오 검증이 필요해요. 저는 아래 체크리스트를 기준으로 봅니다.

1. 외부 모바일 네트워크에서 NAS 관리 화면 접속 성공
2. 노트북에서 파일 공유 마운트 성공
3. SSH 세션이 안정적으로 유지됨
4. 백업 또는 동기화 작업이 정상 수행됨
5. 기존 VPN을 끈 상태에서도 동일 기능 유지

간단한 상태 점검 명령도 함께 확인해두면 좋아요.

tailscale status
tailscale ping <target-node>

제가 실제로 써보니까 가장 만족도가 높았던 건, 가족이나 다른 장치에 새 접속 환경을 설명할 때였어요. 예전엔 프로파일 파일 보내고, 키 넣고, 접속 주소 알려주고, 포트까지 설명해야 했는데요. 바꾸고 나서는 장치 등록과 승인 흐름만 정리하면 되니까 훨씬 덜 복잡했습니다. 운영자 입장에서는 이게 꽤 큰 차이예요. NAS 원격 접속 변경의 목적이 편리함과 안정성이라면 방향은 맞다고 봅니다.

정리: 어떤 사용자에게 특히 잘 맞나

기존 VPN 대비 Tailscale 전환 후 관리 포인트가 어떻게 줄어드는지 요약한 비교 이미지입니다.

자주 묻는 질문

Q1. 기존 VPN을 바로 지워도 될까요?

권장하지 않아요. 며칠이라도 병행 운영해보세요. 특히 자동화 백업이나 모바일 앱 접근은 나중에 빠진 게 발견되는 경우가 있거든요.

Q2. NAS에 직접 설치가 안 되면 포기해야 하나요?

아니에요. 같은 내부망의 리눅스 장비를 서브넷 라우터로 두면 충분히 현실적인 대안이 됩니다.

Q3. WireGuard를 이미 잘 쓰고 있는데 굳이 바꿔야 하나요?

굳이 바꿔야 하는 건 아니에요. 다만 장치 수가 늘고 운영 피로도가 커졌다면, WireGuard Tailscale 이전은 꽤 설득력 있는 선택입니다.

마무리

이번 VPN Tailscale 마이그레이션은 성능 수치보다 운영 경험을 바꾸는 작업에 가깝습니다. 저도 처음엔 “기존 OpenVPN이나 WireGuard도 잘 되는데 굳이?” 싶었거든요. 근데 실제로 써보니까, 특히 홈랩과 NAS처럼 장비가 서서히 늘어나는 환경에서는 이 차이가 계속 누적돼요. 접속 자체보다 관리가 쉬워진다는 게 진짜 포인트였습니다.

혹시 지금 포트포워딩, 인증서, 설정 파일 관리 때문에 조금씩 피곤해지고 계셨다면, 이번 기회에 작은 범위부터 옮겨보셔도 좋겠습니다. 다음 글에서는 Tailscale과 서브넷 라우터를 이용해 여러 VLAN(브이랜, 가상 LAN) 구간을 안전하게 다루는 방법도 정리해볼까 합니다. 이전 글에서 다뤘던 홈랩 방화벽 설계 내용과 같이 보면 더 이해가 잘 되실 거예요. 천천히 옮기되, 검증은 꼼꼼하게. 이게 제일 덜 고생하는 방법이었습니다.

전환 완료 후 노트북, 모바일, NAS가 안정적으로 연결된 상태를 상징적으로 보여주는 마무리 이미지입니다.