나만의 컨트롤 서버.
쥘 만한 가치가 있는 것은 지도입니다.

"제 기계들이 서로에게 비공개로 닿게 하고 싶다"는 물음에는 정직한 답이 셋 있고, 이 가이드는 그중 하나일 뿐입니다. 순정 WireGuard가 가장 작습니다. 커널 모듈 하나, 피어당 설정 파일 하나, 인터페이스 말고는 데몬도 없고, 운영체제 말고는 최신 상태로 유지할 것도 없습니다. 당신 기기가 고정 주소를 가진 서버들이고 한 손으로 셀 수 있는 수라면, 여기서 멈추고 대신 WireGuard 가이드를 읽으십시오. 소프트웨어는 더 적고, 고장 날 수 있는 것의 목록은 더 짧아질 것입니다.

Tailscale은 셋 중 가장 큽니다. 밑바탕은 같은 WireGuard이고, 여기에 코디네이션 서비스, 거의 모든 환경 뒤에서도 작동하는 NAT 통과, 여러 대륙에 걸친 릴레이 네트워크, 웹 콘솔, 싱글 사인온, 지원 계약까지 더해집니다. 정말로 훌륭한 소프트웨어이고 무료 티어만으로도 가정에서는 충분합니다. 대가는 돈이 아닙니다. 당신이 소유한 모든 기기의 지도와, 각 기기가 어디서 접속하는지에 대한 기록이 한 회사의 데이터베이스에 저장된다는 것, 그것이 대가입니다.

Headscale은 세 번째 답이며, 둘보다 범위가 좁습니다. 코디네이션 서버를 오픈소스로 다시 구현한 것으로, 운영자는 당신이고, 대화 상대는 동일한 공식 클라이언트입니다. 자동화와 NAT 통과 기능은 그대로 누리는 대신, 운영해야 할 작은 서비스 하나와 기능이 일부뿐이라는 한계, 그리고 읽어야 하는 업그레이드를 떠안게 됩니다. 이것이 공짜라고 말할 사람은 없어야 합니다. 대신 정확히 한 가지를 얻습니다. 그리고 그것이 이 사이트가 신경 쓰는 바로 그것입니다. 지도를 쥔 사람이 당신 말고는 아무도 없다는 것.

설치할 것 자체가 달라지니, 나중이 아니라 지금 정해 둘 것이 하나 더 있습니다. 이 네트워크가 오직 당신만을 위한 것인지, 아니면 다른 사람도 합류할 것인지입니다. 혼자 쓰는 테일넷은 내부를 활짝 열어 두어도 아무 문제가 없습니다. 동료나 계약직, 가족이 함께 쓰는 테일넷은 첫 주부터 — 단계 05 — 문서화된 접근 규칙이 필요하고, 모두가 로그인을 나눠 쓰는 대신 사용자를 분리해 둬야 합니다. 미리 정해 두면 문단 하나면 끝나지만, 나중에 뜯어고치려면 오후 반나절이 듭니다.

Headscale과 Caddy, 그게 전부입니다. Headscale은 Docker 네트워크 안에서 평범한 HTTP로 리스닝하고, Caddy가 TLS를 종단하며 첫 부팅 때 인증서를 받아 요청 없이도 갱신합니다. 메트릭 리스너는 localhost에만 남겨 둡니다. 공개용이 아니라 내부 디버그용 창구이기 때문입니다.

파일을 보기 전에 규칙 하나. 이미지를 정확한 버전으로 고정하십시오. Headscale은 1.0 이전 소프트웨어로, 마이너 릴리스를 거치며 설정 키와 CLI 서브커맨드 이름이 한 번 이상 바뀌었습니다. 플로팅 태그를 쓰면 평범한 컨테이너 재시작 한 번이, 다른 모든 것에 닿게 해 주는 것이 본업인 서비스의 장애로 둔갑합니다.

/srv/headscale/docker-compose.yml

services:
  headscale:
    image: docker.io/headscale/headscale:0.26            # pin it; never :latest
    container_name: headscale
    command: serve
    volumes:
      - ./config:/etc/headscale
      - ./data:/var/lib/headscale
    ports:
      - "3478:3478/udp"                                  # STUN, for your own DERP
    restart: unless-stopped

  caddy:
    image: caddy:2-alpine
    container_name: caddy
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy_data:/data
    restart: unless-stopped

volumes:
  caddy_data:

/srv/headscale/Caddyfile

vpn.example.com {
    reverse_proxy headscale:8080
}

프록시 설정은 이것으로 끝입니다. Caddy는 HTTP/2를 구사하고 시키지 않아도 장기 연결을 업그레이드해 주는데, 모든 클라이언트가 지도 업데이트를 받으려고 연결 하나를 계속 열어 두는 이 상황에서 이 점이 중요합니다. 처음부터 새로 쓰지 말고, 고정해 둔 버전에 딸려 오는 샘플 설정 파일을 가져다 수정하십시오. 파일은 길지만 대부분은 이치에 맞는 기본값이고, 중요한 키는 다음과 같습니다.

/srv/headscale/config/config.yaml — the lines that matter

server_url: https://vpn.example.com          # exactly what clients will dial
listen_addr: 0.0.0.0:8080                    # inside the Docker network only
metrics_listen_addr: 127.0.0.1:9090          # debug surface, keep it local

prefixes:
  v4: 100.64.0.0/10
  v6: fd7a:115c:a1e0::/48

noise:
  private_key_path: /var/lib/headscale/noise_private.key

database:
  type: sqlite                               # postgres for a large fleet
  sqlite:
    path: /var/lib/headscale/db.sqlite

dns:
  magic_dns: true
  base_domain: ts.example.com                # NOT a parent or child of server_url
  nameservers:
    global:
      - 1.1.1.1                              # replaced by your own in step 05

일단 띄운 다음, 짐작하지 말고 로그를 읽으십시오. 인증서를 받지 못했거나 서버 호스트네임과 겹친다는 이유로 DNS 접미사를 거부한 첫 부팅은, 그 사실을 분명히 알리고 멈춥니다.

docker compose up -d
docker compose logs -f headscale

# From your laptop — a control server that is up answers this:
curl -s https://vpn.example.com/health

첫 부팅은 /srv/headscale/data에 개인 키 자료를 생성합니다. 기기가 단 한 대라도 등록되기 전에 지금 바로 안전한 곳에 복사해 두고, 첫 등록이 끝난 뒤 다시 한번 복사하십시오. 이 키를 잃으면 그동안 신뢰해 온 서버를 모든 기기가 거부하게 되며, 유일한 복구책은 전부 손으로 재등록하는 것뿐입니다. 단계 06에서 이 복사본을 진짜 백업으로 만듭니다.

모든 기기가 서로에게 닿는 테일넷은 그 자체로 이미 쓸모가 있습니다. 여기에 세 가지를 더하면 단순한 터널 묶음이 아니라 하나의 네트워크가 되는데, 이 셋은 사람들이 흔히 걸려 넘어지는 성질을 공유합니다. 클라이언트가 기능을 광고하면, 서버가 그것을 승인해야 한다는 점입니다. 광고만 되고 승인되지 않은 라우트는 조용히, 그냥 존재하지 않는 것이 됩니다. 증상은 라우터까지는 핑이 가지만 그 뒤에 있는 것에는 닿지 않는다는 것입니다.

서브넷 라우터 — LAN 전체를 테일넷에 올립니다. 가정이나 사무실 네트워크에서 기계 한 대가 그 네트워크의 대역을 광고하면, 다른 모든 기기는 별도 설치 없이도 그 뒤에 있는 프린터, NAS, 관리 인터페이스에 닿게 됩니다. 커널의 포워딩부터 켜 두십시오. 그렇지 않으면 패킷은 오류 메시지 하나 없이 라우터에서 멈춰 버립니다.

# On the machine that sits inside the LAN:
echo 'net.ipv4.ip_forward = 1'          | sudo tee /etc/sysctl.d/99-ts.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-ts.conf
sudo sysctl -p /etc/sysctl.d/99-ts.conf

sudo tailscale up --login-server https://vpn.example.com \
  --advertise-routes=192.168.1.0/24 --accept-routes

# On the control server — approve it, or it does not exist.
# The subcommand moved between releases; check `hs nodes --help` first.
hs nodes list
hs nodes approve-routes --identifier 3 --routes 192.168.1.0/24

엑시트 노드 — 모든 트래픽을 VPS 밖으로 내보냅니다. 같은 메커니즘을 더 넓은 경로에 적용한 것입니다. 스스로를 엑시트 노드로 광고하는 기기는 다른 기기의 인터넷 연결 전체를 실어 나르겠다고 나섭니다. 신뢰할 수 없는 카페나 호텔 네트워크에서는 정확히 이것이 필요하며, 이 가이드에서 개인용 VPN에 가장 가까운 것이 바로 이것입니다.

# On the VPS that will do the exiting (forwarding must be on, as above):
sudo tailscale up --login-server https://vpn.example.com --advertise-exit-node

# Approve it on the control server, then on the laptop:
tailscale set --exit-node=100.64.0.1 --exit-node-allow-lan-access
tailscale set --exit-node=                    # turn it off again

엑시트 노드는 상용 VPN이 아니며, 스스로에게 그런 것처럼 팔아서는 안 됩니다. 그 주소는 오직 당신 것이고 고정되어 있어서, 카페 와이파이를 상대할 때는 탁월하지만 여러 사이트에 걸친 장기 상관분석 앞에서는 무력합니다. 이 트레이드오프는 필라 가이드에서 자세히 다룹니다. 엑시트 노드를 두 번째의 더 저렴한 VPS에서 돌려, 컨트롤 서버는 포워딩 트래픽에서 완전히 자유롭게 둘 수도 있다는 점도 기억해 두십시오.

접근 규칙 — 두 번째 사람이 합류하기 전에 써 두십시오. 기본 정책은 모두 허용이며, 이는 혼자 쓰는 테일넷에는 맞지만 다른 사람이 들어오는 순간 틀린 선택이 됩니다. 정책은 작은 HuJSON 문서입니다. 사용자 그룹, 기계에 붙이는 태그, 그리고 어떤 출발지가 어떤 포트로 어떤 목적지에 닿을 수 있는지 정하는 규칙 목록으로 이루어집니다. 설정에서 이 파일을 가리키게 하고, 파일은 버전 관리에 두고, 수정할 때마다 리로드하십시오.

{
  "groups": {
    "group:admin":     ["alice"],
    "group:contractor":["bob"]
  },
  "tagOwners": {
    "tag:server": ["group:admin"],
    "tag:exit":   ["group:admin"]
  },
  "acls": [
    // Admins reach everything.
    { "action": "accept", "src": ["group:admin"], "dst": ["*:*"] },

    // The contractor reaches one machine, on two ports, and nothing else.
    { "action": "accept", "src": ["group:contractor"],
      "dst": ["tag:server:22,443"] }
  ],
  "autoApprovers": {
    "routes":   { "192.168.1.0/24": ["tag:server"] },
    "exitNode": ["tag:exit"]
  }
}

이 파일에 대해 짚어 둘 것이 두 가지 있습니다. 정책 언어는 Tailscale의 것이고, Headscale은 그 전부가 아니라 크고 계속 늘어나는 일부만 구현합니다. 특이한 규칙에 기대기 전에 당신 버전의 문서를 확인하십시오. 그리고 정책이 어디에 사는지도 옮겨 다녔습니다. 예전 릴리스는 최상위 설정에서 경로를 지정했고, 최신 릴리스는 규칙을 데이터베이스에 둘 수도 있는 모드와 함께 정책 섹션 아래로 묶었습니다. 둘 다 문서화되어 있으니, 중요한 것은 당신이 고정해 둔 버전이 실제로 무엇을 쓰느냐입니다.

MagicDNS — 짧은 이름, 그리고 어디서나 나만의 리졸버. MagicDNS를 켜면, 모든 기기가 단계 02에서 고른 접미사 안의 짧은 이름으로 응답하게 되어, hosts 파일 없이도 어디서나 ssh nas가 작동합니다. 흥미로운 것은 뒤쪽 절반입니다. 컨트롤 서버는 모든 클라이언트에 네임서버 목록도 함께 밀어 주는데, 이는 프라이빗 DNS 리졸버 가이드에서 만든 리졸버가, 인터넷에서는 전혀 닿을 수 없는 테일넷 주소로만 리스닝하면서도 모바일 데이터로 접속한 휴대폰까지 필터링·캐싱하고 아무것도 로깅하지 않은 채 서빙할 수 있다는 뜻입니다.

dns:
  magic_dns: true
  base_domain: ts.example.com
  override_local_dns: true          # beat whatever DHCP handed the device
  nameservers:
    global:
      - 100.64.0.5                  # your resolver, on the tailnet

컨트롤 플레인을 셀프 호스팅하는 것은 실질적이고 구체적인 개선이지, 마술처럼 문제를 사라지게 하는 요술이 아닙니다. 위의 모든 것을 다 해내고 나서도 변하지 않는 사실이 다섯 가지 있고, 이것을 아는 것이야말로 진짜 방어와 그저 위안이 되는 이야기의 차이를 가릅니다.

컨트롤 서버는 이름을 가진 공개 엔드포인트입니다. 모든 기기가 이 주소로 접속하므로 호스트네임이 하나 필요하고, 그 호스트네임은 인증서가 발급되는 순간 인증서 투명성 로그에 실립니다. 어디에도 링크한 적 없어도 찾아낼 수 있으며, 그 주소는 당신의 모든 기기가 공유하는 유일한 상수입니다. 무엇인지 설명하는 이름 대신, 이미 공개해 둔 도메인의 서브도메인을 쓰십시오.

Headscale은 재구현체이고, 스스로도 그렇다고 밝힙니다. Tailscale이 만들거나 지원하는 제품이 아니며, 기능 동등성은 구조적으로 일부에 그치고, 호스팅형 제품이 파는 것 중 일부 — 웹 콘솔, 공개 릴레이 네트워크, 잘 다듬어진 싱글 사인온 경로 — 는 여기 아예 없거나, 누구도 감사하지 않은 서드파티 프로젝트로 대신해야 합니다. 어떤 기능을 두고 계획을 세우기 전에, 그것이 실제로 존재하는지 프로젝트 문서에서 확인하고, 업그레이드는 백그라운드에서 저절로 되는 일이 아니라 하나의 작업으로 다루십시오.

기본 릴레이는 여전히 남의 것입니다. 내장 DERP 서버를 켜기 전까지는, 다이렉트로 붙을 수 없는 연결이 공개 릴레이 네트워크로 폴백됩니다. 페이로드는 여전히 종단간 암호화되어 있어 아무도 읽을 수 없지만, 당신의 두 기기가 대화를 나누고 있다는 사실과 그 양은 당신 소유가 아닌 인프라를 거쳐 갑니다. 대부분의 사람이 첫날 오후에 놓치는 신뢰 사슬의 그 부분이 바로 이것입니다.

엑시트 노드는 안정적인 주소이지, 군중이 아닙니다. 트래픽을 당신 VPS로 돌리면 카페 네트워크와 ISP의 프로파일링은 무력화됩니다. 하지만 상관분석은 무력화하지 못합니다. 그 주소는 오직 당신 것이고 바뀌지 않기 때문입니다. 상용 VPN의 공유 주소는 바로 이 위협 하나를 제외한 모든 면에서 더 나쁩니다.

그 기계는 여전히 어느 건물 안에 있습니다. 임대 서버도 문과 직원이 있는 데이터센터의 실제 하드웨어 위에서 돌아갑니다. 달라지는 것은, 당신 기기들을 모아 놓은 제품 차원의 색인이 없고, 각 기기가 어디서 접속하는지 기록하는 회사 데이터베이스가 없으며, 다음 분기에 슬쩍 바뀔 수 있는 개인정보 정책도 없다는 점입니다. 달라지지 않는 것은, 디스크가 물리적으로 존재하며 그것이 당신 집 안에 있지는 않다는 점입니다.

정확히 무엇을 산 것인지 말하자면: 당신이 가진 모든 기계의 목록, 각 기기가 어디서 접속하는지에 대한 기록, 그리고 새 기기를 추가할 권한까지, 이 모두가 특정한 이름 없이 빌린 서버 위에 놓이게 됩니다. 좁지만 진짜인 주장입니다. 이것이 값어치를 하는 것은 오직 단계 06까지 마쳤을 때뿐입니다. 검증된 복원 절차가 없는 셀프 호스팅 컨트롤 플레인은 프라이버시의 개선이 아니라, 브랜딩만 그럴듯한 단일 장애점일 뿐입니다.