Tailscale userspace-networking: 관리자 권한 없는 Mac 원격 접속

회사 정책상 관리자 권한은 어림도 없는데, 원격 접속 환경이 필요했다. 특히 갤럭시 탭으로 내 맥북에 붙어야 할 때가 잦았다.

보안 팀에 VPN 요청해봐야 절차만 복잡해질 게 뻔하고, 개인용으로 뭔가 설치하고 싶어도 sudo 비밀번호가 없으니 답답할 노릇. 이래저래 궁리하다가 Tailscale의 userspace-networking 모드가 눈에 들어왔다. 관리자 권한 없이 일반 사용자 영역에서 VPN처럼 작동할 수 있다는 말에 솔깃했다.

관리자 권한 없는 Mac, Tailscale이 답일까? 🤔

먼저, brew install tailscale로 CLI 버전을 설치했다. GUI 앱은 cask로 설치해야 하는데, 그건 또 sudo가 필요했다. CLI 설치는 다행히 권한 문제 없이 잘 넘어갔다.

문제는 그 다음부터였다. tailscaled를 실행해야 했는데, 기본적으로는 시스템 서비스로 등록되어야 하지만, userspace-networking 모드는 수동으로 돌려야 했다.

userspace-networking 모드로 tailscaled 백그라운드 실행하기

나는 다음 명령으로 tailscaled를 백그라운드에 띄웠다.

nohup tailscaled --tun=userspace-networking --statedir=$HOME/.tailscale --socket=$HOME/.tailscale/tailscaled.sock &

여기서 statedir와 socket 경로를 내 홈 디렉토리 밑으로 지정하는 게 핵심이었다. nohup으로 백그라운드에 띄웠으니 터미널을 닫아도 돌아가긴 했다.

하지만 문제는 launchd에 등록된 게 아니라서, 재부팅할 때마다 이 명령을 다시 쳐줘야 한다는 점이었다. 이걸 한두 번 잊었다가 접속이 안 돼 몇 분씩 헤맨 적도 있다. 내가 좀 게으른 편이라 이런 반복 작업은 질색이었다.

 

Tailscale CLI, 왜 자꾸 소켓 파일을 못 찾지?

tailscaled는 일단 돌아가니, 이제 tailscale CLI 명령으로 상태를 확인하거나 설정을 바꿔야 했다. tailscale status 같은 평범한 명령을 쳤는데 계속 에러가 떴다. "소켓 파일을 찾을 수 없다"는 식이었다. 순간 당황했다. 분명 백그라운드에서 돌아가고 있는데 왜? 😵‍💫

알고 보니 tailscale CLI는 기본적으로 /var/run/tailscale/tailscaled.sock 같은 시스템 기본 경로에서 소켓 파일을 찾도록 되어 있었다.

하지만 userspace-networking 모드에서는 소켓 파일이 내 홈 디렉토리인 $HOME/.tailscale/tailscaled.sock에 생성된 것이다. CLI가 이 경로를 자동으로 유추하지 못하니 매번 --socket 플래그로 명시해줘야 했다.

tailscale --socket=$HOME/.tailscale/tailscaled.sock status
tailscale --socket=$HOME/.tailscale/tailscaled.sock ip
tailscale --socket=$HOME/.tailscale/tailscaled.sock set --ssh

이 긴 경로를 매번 타이핑하는 게 여간 귀찮은 일이 아니었다. tailscale status를 하루에 다섯 번만 쳐도 꽤 시간이 걸리는 일이다. 명령어 뒤에 매번 저 옵션을 붙여야 한다는 게 솔직히 좀 짜증 났다. 내가 원하는 건 그냥 tailscale status 한 방이었는데 말이다.

이 맥의 hostname은 me-mac이고, Tailscale IP는 100.119.37.84로 잘 할당되었다. 내 계정 inme으로 기존 tailnet에 desktop-putfua9와 me-macmini가 이미 등록되어 있었다. 로그는 ~/.tailscale/tailscaled.log에 남았다.

userspace 모드의 치명적인 한계: SOCKS5 프록시 방식 😥

Tailscale 내장 SSH 기능도 tailscale set --ssh로 켜봤다. 갤럭시 탭(tab-s9-fe, 100.95.145.34)에서 me@100.119.37.84로 접속하니 맥의 SSH가 잘 붙었다.

macOS 원격 로그인을 따로 열어줄 필요가 없어져서 이 점은 아주 만족스러웠다. 다만, 맥 자신에서 자기 Tailscale IP로 접속 테스트를 해보니 타임아웃이 났다. 이건 userspace 모드의 특성상 인바운드 연결만 가능하고 아웃바운드 트래픽은 기본적으로 Tailscale을 통하지 않아서 생기는 현상이었다.

여기서 또 다른 허들을 만났다. userspace-networking 모드는 완전한 시스템 수준의 VPN이 아니라는 점이었다. 트래픽을 SOCKS5 프록시 방식으로 통과시키는 구조였다.

일반적인 VPN처럼 모든 앱의 트래픽이 자동으로 Tailscale을 타는 게 아니었다. 특정 앱에서 Tailscale 네트워크를 사용하려면 해당 앱의 프록시 설정을 Tailscale이 제공하는 SOCKS5 프록시 주소로 명시적으로 바꿔줘야 했다.

예를 들어, 웹브라우저에서 Tailscale 네트워크를 통해 특정 내부망 사이트에 접속하려면 브라우저의 프록시 설정을 수정해야 한다는 뜻이다. 처음엔 "분명 VPN인데 왜 브라우저에서 접속이 안 되지?" 하고 한참 삽질했다. 나중에야 이 프록시 방식의 차이점을 깨달았다. SOCKS5 프록시는 특정 도로로만 지나갈 수 있는 특별 통행증 같은 거라, 모든 차가 그 도로로 가는 건 아니었다.

 

결국, sudo 권한이 없다는 제약은 Tailscale을 '제대로' 쓰기 위해 몇 가지 타협을 받아들이게 만들었다. CLI 명령에 매번 소켓 경로를 붙여야 하는 불편함. 그리고 앱별로 프록시 설정을 해줘야 하는 번거로움.

재부팅하면 tailscaled를 다시 실행해야 하는 자동화의 부재. 이런 것들이 모두 관리자 권한 없이는 표준 설치 경로와 시스템 서비스 등록을 사용할 수 없기 때문에 발생한 일이었다.

이런 삽질을 겪으며 배운 건, 특정 환경 제약이 있다면 도구의 기본적인 작동 방식까지 깊이 파고들어야 한다는 점이다. 그리고 '공식 가이드'가 항상 내 상황에 딱 들어맞는 건 아니라는 걸 다시 한번 깨달았다.

※ 이 글은 직접 겪은 작업 경험을 바탕으로 AI의 도움을 받아 작성했습니다.