가이드

작성자 Matt Connor 2026-08-11 · 업데이트됨 2026-08-27

VPS에서 Tor 릴레이 운영하기: 설정 및 대역폭 관리 가이드

Q: Tor 릴레이는 대역폭을 얼마나 사용합니까?

설정한 만큼만 사용하며 그 이상은 사용하지 않습니다. RelayBandwidthRate은 각 방향의 릴레이 트래픽을 개별적으로 제한하므로, 1 Mbit/s로 설정된 릴레이는 동시에 1 Mbit/s의 수신 및 발신 트래픽을 처리할 수 있습니다. 이는 양방향을 합쳐 하루에 약 21.6 GB, 30일 기준으로 648 GB에 해당합니다. 해당 속도 아래에서 엄격한 월간 할당량을 적용하려면 AccountingMax과 AccountingRule sum를 추가하십시오.

Q: 1 TB 전송 제한이 있는 VPS에서 Tor 릴레이를 운영할 수 있습니까?

네, 양방향으로 약 1 Mbit/s 속도를 유지하면 가능하며, 이는 RelayBandwidthRate 125 KBytes에 해당합니다. 제공업체가 양방향 트래픽을 모두 측정하는 경우 한 달에 약 648 GB가 소모되므로 업데이트나 백업을 위한 여유 공간이 남습니다. AccountingMax 400 GBytes에 AccountingRule sum와 AccountingStart month 1 00:00을 추가하여 할당량을 초과하는 대신 릴레이가 휴면 상태로 전환되도록 설정하십시오. 제공업체가 발신 트래픽만 과금하는 경우 속도를 두 배로 높일 수 있습니다.

Linux VPS에서 가드 또는 미들 Tor 릴레이를 설정하는 방법을 안내합니다. torrc 설정법과 종량제 요금제 보호를 위한 대역폭 제한, nyx 모니터링, 그리고 신규 릴레이가 네트워크에 완전히 통합되기까지 필요한 일주일간의 대기 시간 등 실무적인 핵심 내용을 정리했습니다.

VPS에서 Tor 릴레이가 하는 역할

Tor 릴레이는 공인 IP 주소를 가진 서버에서 실행되는 Tor 데몬으로, 다른 사용자의 암호화된 트래픽을 전달하는 역할을 합니다. 디렉터리 권한(directory authorities)이 이를 게시하면 Tor 클라이언트가 이를 통해 회선을 구축합니다. 가드(guard) 또는 중간(middle) 릴레이는 트래픽을 항상 다른 릴레이로만 전달하므로, 타인을 대신하여 웹사이트에 직접 연결을 생성하지 않습니다. 바로 이 점 때문에 악용 사례에 대한 메일이 오지 않으며, 일반적인 VPS 환경에 가장 적합한 기여 방식이 됩니다. 릴레이는 타인의 트래픽을 운반할 뿐 자체적인 콘텐츠를 게시하지 않습니다. 따라서 패킷을 전달하는 대신 자신의 사이트를 네트워크에 올리고 싶다면, Nginx 뒤에서 v3 onion 서비스 운영하기는 동일한 tor 데몬을 사용하더라도 다른 작업에 해당합니다. 또한 릴레이를 운영하는 것은 본인의 브라우징 프라이버시와는 무관하며, 이는 대부분의 사람이 기대하는 것보다 훨씬 낮은 수준의 효과를 가집니다. SearXNG를 직접 호스팅할 때 실제로 숨겨지는 정보는 서비스를 자신의 VPS로 옮기는 것이 어느 정도의 효과를 갖는지 보여주는 적절한 척도입니다.

작업량은 적습니다. 패키지 하나 설치, 15줄의 설정, 방화벽 규칙 하나, 그리고 재시작 한 번이면 충분합니다. 이 가이드의 나머지 부분은 문제가 발생하기 쉬운 지점들을 다룹니다. 종량제 요금제에서의 대역폭 계산법과, 정상적으로 작동하는 새 릴레이가 왜 일주일 동안은 죽어 있는 것처럼 보이는지에 대한 이유를 설명합니다.

가드, 미들, 브리지, 엑시트: 설치 전 역할 선택

하나의 데몬이 네 가지 역할을 모두 수행합니다. 사용자의 설정과 디렉터리 권한(directory authorities)이 어떤 역할을 맡을지 결정합니다.

미들 릴레이(Middle relay): 가드로부터 트래픽을 받아 다른 릴레이로 전달합니다. 목적지 사이트와 직접 통신하지 않습니다. 모든 신규 릴레이는 여기서 시작합니다.
가드 릴레이(Guard relay): 미들과 동일한 설정에 플래그가 추가된 형태입니다. 디렉터리 권한은 충분히 빠르고 안정적인 릴레이에 가드 플래그를 부여합니다. 사용자가 직접 선택할 수 없으며, 아래의 설정을 통해 자격을 획득해야 합니다.
브리지(Bridge): 공개 디렉터리에 노출되지 않고 Tor가 차단된 지역의 사용자에게 비공개로 전달되는 릴레이입니다. 네 가지 역할 중 가장 부담이 적습니다. 대역폭이 낮고 공개 목록에 오르지 않으므로 소규모 운영 계획에 적합한 첫 단계입니다. 데몬과 함께 obfs4 프록시를 실행해야 하며 torrc 설정이 다릅니다. 저렴한 VPS에서 obfs4 브리지 설정하기에서 브리지 라인을 사용자에게 전달하는 방법까지 상세히 다룹니다.
엑시트 릴레이(Exit relay): 목적지 사이트로 연결을 여는 마지막 홉입니다. 사용자의 모든 요청이 사용자의 IP 주소를 통해 나가므로, 악용 신고나 경찰의 문의가 해당 IP 주소 소유자에게 전달됩니다.

엑시트 릴레이는 일반적인 VPS에서 운영하기에 적합하지 않은 역할입니다. 엑시트 릴레이는 반드시 사전에 운영을 허가받은 호스팅 업체에서, 전용 IP 주소를 사용하고, 공개된 악용 신고 연락처를 갖춘 상태로 운영해야 합니다. 대부분의 표준 호스팅 약관은 이를 금지하며, 이를 무시할 경우 서버 정지 및 IP 주소 회수 조치가 따릅니다. 그럼에도 엑시트 릴레이 운영을 원한다면 엑시트 릴레이 운영의 실제를 통해 엑시트 친화적인 호스트를 찾는 법, 엑시트 정책 및 역방향 DNS 설정, 그리고 관련 문의 대응 방법을 확인하십시오. 가드나 미들 릴레이는 동일한 사용자 트래픽을 처리하면서도 이러한 위험 부담이 없습니다.

아래의 모든 내용은 가드/미들 릴레이 구축을 기준으로 합니다. ExitRelay 0은 해당 역할을 유지하기 위한 설정 줄입니다.

시작 전 VPS가 갖추어야 할 조건

Tor Project는 릴레이 운영을 위한 필수 요구 사항을 명시하고 있습니다. 2026년 8월 기준 요구 사항은 다음과 같습니다. 릴레이용 공인 IPv4 주소 1개, 양방향 최소 10 Mbit/s 대역폭(16 Mbit/s 권장), 월간 최소 100 GB의 아웃바운드 트래픽, 그리고 40 Mbit/s 미만 속도에서는 512 MB, 그 이상에서는 1 GB 이상의 RAM이 필요합니다. 고정된 가동 시간 규칙은 없으나, 하루 2시간 미만으로 운영되는 릴레이는 네트워크에 거의 도움이 되지 않습니다.

10 Mbit/s라는 수치는 설정값이 아닌 회선 성능을 의미합니다. 해당 속도를 지원하는 포트가 필요합니다. 릴레이가 이 회선 대역폭 중 얼마를 사용하도록 허용할지는 월간 데이터 전송 허용량을 고려하여 별도로 결정해야 합니다. 설정을 변경하기 전에 가입한 요금제의 약관을 확인하십시오. 아직 서버를 선택 중이라면 VPS의 월별 실제 비용에서 데이터 전송 허용량이 어떻게 판매되는지 확인하고, VPS의 실제 네트워크 처리량 측정을 통해 판매 페이지의 광고 문구 대신 iperf3를 사용하여 실제 회선 성능을 확인하는 방법을 참조하십시오.

먼저 서버 보안을 강화하십시오. 릴레이는 공인 주소에서 운영되는 공개 서비스이므로, 네트워크에 게시된 후 몇 분 이내에 스캔 대상이 됩니다. SSH를 키 기반 인증으로 제한하고 sshd 설정 강화하기는 10분이면 완료할 수 있는 작업이며, 릴레이를 가동하기 전에 반드시 수행해야 합니다.

Tor Project 저장소에서 Tor 설치하기

배포판 패키지 대신 Tor Project의 공식 apt 저장소를 사용하십시오. 릴레이 코드는 안정적인 릴리스보다 빠르게 업데이트되므로, 수정 사항이 이 저장소에 먼저 반영되며 배포판 패키지는 릴리스 사이에 지연이 발생합니다.

sudo apt update
sudo apt install -y apt-transport-https gnupg wget

서명 키를 추가한 다음 저장소를 추가하십시오. 코드네임은 시스템에서 자동으로 읽어오므로, 동일한 블록을 Ubuntu 24.04(noble)와 Debian 13(trixie)에서 그대로 사용할 수 있습니다.

wget -qO- https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc \
  | gpg --dearmor \
  | sudo tee /usr/share/keyrings/deb.torproject.org-keyring.gpg >/dev/null

CODENAME=$(. /etc/os-release && echo "$VERSION_CODENAME")
echo "$CODENAME"

sudo tee /etc/apt/sources.list.d/tor.sources >/dev/null <<EOF
Types: deb deb-src
URIs: https://deb.torproject.org/torproject.org/
Suites: $CODENAME
Components: main
Signed-By: /usr/share/keyrings/deb.torproject.org-keyring.gpg
EOF

sudo apt update
sudo apt install -y tor deb.torproject.org-keyring
tor --version

tor --version은 방금 설치한 버전을 출력합니다. 만약 apt update이 NO_PUBKEY 오류를 출력한다면, dearmored 키가 Signed-By: 라인에 지정된 경로에 존재하지 않는 것입니다. 이 경우 apt가 릴리스 파일을 확인할 키를 찾지 못합니다. deb.torproject.org-keyring 패키지는 나중에 중요해집니다. 이 패키지는 서명 키를 일반 패키지 형태로 제공하므로, 키가 교체되어도 apt가 계속 정상적으로 작동하게 합니다.

자동 업그레이드를 활성화한 다음, 새로운 origin을 인식시키십시오.

sudo apt install -y unattended-upgrades apt-listchanges

Ubuntu에서는 /etc/apt/apt.conf.d/50unattended-upgrades 내의 Allowed-Origins 블록에 Tor origin을 추가하십시오:

Unattended-Upgrade::Allowed-Origins {
        "${distro_id}:${distro_codename}-security";
        "TorProject:${distro_codename}";
};

Debian에서는 동일한 파일이 Origins-Pattern을 사용하며, 추가할 라인은 "origin=TorProject";입니다. sudo unattended-upgrade --debug --dry-run로 결과를 확인하십시오. 이 명령은 적용 대상 origin을 출력하며 아무것도 기록하지 않습니다.

중요한 torrc 설정

패키지를 설치하면 주석이 가득 달린 긴 /etc/tor/torrc 파일이 생성됩니다. 릴레이 운영에 필요한 설정은 몇 줄 되지 않습니다. 파일 끝에 다음 내용을 추가하십시오.

Nickname mynicerelay
ContactInfo relay-ops[at]example.com
ORPort 9001
ExitRelay 0
SocksPort 0

Nickname은 1자에서 19자 사이의 영문자와 숫자로만 구성해야 합니다. 네트워크 전체에서 고유할 필요는 없으며, 이것이 서버의 식별자가 아닙니다. 실제 식별자는 핑거프린트입니다. 이 이름은 검색창에서 자신의 릴레이를 찾을 때 사용하므로, 전화로 불러주기 쉬운 이름을 선택하십시오.

ContactInfo는 누구나 다운로드할 수 있는 공개 문서인 릴레이 기술서(relay descriptor)에 게시되므로, 주소가 수집될 수 있습니다. 2년 뒤에도 확인할 수 있는 이메일 주소를 사용하고, 필요하다면 난독화하십시오. 이 주소는 Tor Project가 릴레이 관련 문제를 경고할 수 있는 유일한 통로입니다.

ORPort 9001은 다른 릴레이와 클라이언트가 연결을 시도하는 포트입니다. 9001번이 관례적으로 사용됩니다. 443번 포트도 흔히 선택되는데, 일부 제한적인 네트워크는 아웃바운드 443번 트래픽만 허용하므로 이 포트에서 대기하는 릴레이가 더 많은 클라이언트에게 도달할 수 있기 때문입니다. 서버의 다른 서비스가 443번 포트를 사용하지 않는 경우에만 이 포트를 선택하십시오.

SocksPort 0는 릴레이에서 사용하지 않는 로컬 SOCKS 프록시를 끄고, 시스템에서 대기 중인 소켓 하나를 제거합니다. ExitRelay 0는 이 의도를 파일에 명시합니다. 즉, 이 릴레이는 사용자를 대신하여 목적지에 연결하지 않으며, 나중에 설정을 읽는 사람도 기본값에서 유추할 필요가 없도록 합니다.

VPS에 IPv6 주소가 있다면 두 번째 ORPort 줄을 추가하십시오. Tor는 IPv4와 달리 IPv6 주소에 대해 "any"로 바인딩할 수 없으므로, 주소를 대괄호로 묶어서 작성해야 합니다.

ORPort 9001
ORPort [2001:db8::1]:9001

1 GB 용량의 VPS라면 MaxMemInQueues 512 MB 설정을 추가하십시오. Tor는 시스템이 인식하는 메모리 용량을 기준으로 큐 제한을 결정하는데, 소규모 공유 서버에서는 Tor가 사용하는 메모리 양이 의도보다 많아질 수 있습니다. 제한을 직접 설정하면 부하가 걸릴 때 Tor가 큐에 쌓인 셀을 폐기하여 프로세스가 커널에 의해 강제 종료되는 대신 릴레이가 안정적으로 유지됩니다.

방화벽에서 ORPort 열기

인바운드 방향의 ORPort는 인터넷 어디에서든 접근 가능해야 합니다. 아웃바운드 방향은 릴레이를 제한 없이 열어 두어야 합니다. 릴레이는 수많은 다른 릴레이와 다양한 포트로 연결을 맺으므로, 아웃바운드 허용 목록을 설정하면 릴레이 기능이 조용히 마비될 수 있습니다.

sudo ufw allow 9001/tcp comment 'tor ORPort'
sudo ufw status verbose

그다음 제공업체 자체의 네트워크 방화벽을 확인하십시오. 많은 제어판이 가상 머신 앞단에서 패킷 필터를 실행하며, 이 경우 ufw로 추가한 규칙은 적용되지 않습니다. 따라서 서버 내부에서는 포트가 열려 있는 것으로 보이지만 외부에서는 닫힌 상태로 나타날 수 있습니다. ufw가 생소하다면 모든 VPS에 필요한 ufw 규칙에서 기본 정책과 규칙이 일치되는 순서를 확인하십시오.

요금제에 맞춰 대역폭 설정하기

매뉴얼은 RelayBandwidthRate을 별도의 토큰 버킷으로 설명합니다. 이 설정은 "이 노드에서 릴레이되는 트래픽의 평균 수신 대역폭 사용량을 지정된 초당 바이트 수로 제한하며, 평균 송신 대역폭 사용량도 동일한 값으로 제한"합니다. 이 문장을 두 번 읽어 보십시오. 제한은 각 방향에 개별적으로 적용됩니다. 1 Mbit/s로 설정된 릴레이는 동시에 1 Mbit/s의 수신과 1 Mbit/s의 송신을 처리할 수 있으며, 양방향을 모두 측정하는 제공업체는 그 합계를 청구합니다.

ChartMonthly traffic at a sustained relay rate, both directions, 30 days

label

torrc_rate

gb_per_day

gb_per_month

1 Mbit/s

125 KBytes

21.6

648

2 Mbit/s

250 KBytes

43.2

1,296

5 Mbit/s

625 KBytes

108

3,240

10 Mbit/s

1250 KBytes

216

6,480

20 Mbit/s

2500 KBytes

432

12,960

The data behind this chart

[
  {
    "label": "1 Mbit/s",
    "torrc_rate": "125 KBytes",
    "gb_per_day": 21.6,
    "gb_per_month": "648"
  },
  {
    "label": "2 Mbit/s",
    "torrc_rate": "250 KBytes",
    "gb_per_day": 43.2,
    "gb_per_month": "1,296"
  },
  {
    "label": "5 Mbit/s",
    "torrc_rate": "625 KBytes",
    "gb_per_day": 108,
    "gb_per_month": "3,240"
  },
  {
    "label": "10 Mbit/s",
    "torrc_rate": "1250 KBytes",
    "gb_per_day": 216,
    "gb_per_month": "6,480"
  },
  {
    "label": "20 Mbit/s",
    "torrc_rate": "2500 KBytes",
    "gb_per_day": 432,
    "gb_per_month": "12,960"
  }
]

5개의 행은 실제 측정값이 아니라 산술적인 결과입니다. 릴레이가 30일 내내 양방향으로 해당 속도를 유지할 경우 발생하는 비용을 보여줍니다. 실제 릴레이는 특히 운영 초기 몇 주 동안은 설정한 한도보다 훨씬 낮은 트래픽을 처리합니다. 이 표는 기가바이트 단위의 청구서를 예측하기 위한 용도가 아니라, 감당할 수 없는 설정을 배제하기 위해 사용하십시오.

양방향 1 Mbit/s 속도에서 릴레이는 하루에 약 21.6 GB를 전송하므로, 30일 기준 한 달에 약 648 GB의 계측 트래픽이 발생합니다. 이는 1 TB 허용량 내에 들어가며 업데이트와 백업을 위한 여유 공간도 남습니다. 2 Mbit/s로 속도를 높이면 한 달에 1,296 GB가 소모되며, 이는 이미 1 TB 요금제를 초과합니다. 마지막 행인 20 Mbit/s은 한 달에 12,960 GB가 필요하므로 종량제 제한이 없는 포트에서 운영해야 합니다. 제공업체가 송신 트래픽만 청구한다면 모든 수치를 절반으로 나누십시오. 속도를 설정하기 전에 본인의 요금제 방식을 확인하십시오. 두 방식의 결과는 두 배 차이가 납니다.

이제 설정을 진행합니다. 속도 제한을 먼저 설정하고, 할당량(quota)을 나중에 설정하십시오.

RelayBandwidthRate 125 KBytes
RelayBandwidthBurst 250 KBytes
AccountingMax 400 GBytes
AccountingRule sum
AccountingStart month 1 00:00

RelayBandwidthBurst는 토큰 버킷의 크기이므로, 평균 속도를 유지하면서도 짧은 순간의 급증을 허용합니다. 속도 설정값의 약 2배 정도가 적절합니다.

AccountingRule은 많은 운영자가 놓치는 설정입니다. 기본값은 max이며, 이는 두 방향 중 더 큰 값을 기준으로 할당량을 측정합니다. 기본값 상태에서 AccountingMax 400 GBytes를 설정하면 수신 400 GB와 송신 400 GB를 허용하며, 양방향을 모두 측정하는 계측기에서는 800 GB로 계산됩니다. AccountingRule sum은 읽기와 쓰기를 합산하여 하나의 할당량에 대해 측정하며, 이는 실제 전송 허용량을 측정하는 방식입니다.

AccountingStart를 작성할 때는 반드시 AccountingMax와 함께 작성하십시오. 할당량은 수치이며, 시작 라인은 할당량이 초기화되는 주기입니다. 주기가 없는 할당량은 릴레이를 영구적인 휴면 상태로 만들 수 있습니다.

휴면(Hibernation)은 다소 투박한 도구입니다. 할당량이 소진되면 tor는 이를 로그에 기록하고 새로운 작업을 중단합니다:

Bandwidth soft limit reached; commencing hibernation. No new connections will be accepted

릴레이는 다음 주기가 시작되는 정확한 시점에 깨어나지 않습니다. Tor는 이전 할당량을 얼마나 빨리 소진했는지 추적하여 새로운 구간 내의 임의 시점을 선택합니다. 이는 수천 개의 릴레이가 동시에 네트워크로 복귀하는 것을 방지하기 위함입니다. 매달 마지막 주에 사라지는 릴레이는 디렉터리 기관이 측정하는 안정성 점수를 계속 잃게 됩니다. RelayBandwidthRate을 설정하여 한도에 도달하지 않도록 하고, AccountingMax은 청구서를 보호하는 최후의 안전장치로 유지하십시오.

릴레이를 시작하고 연결 가능 여부 확인

sudo systemctl restart tor@default
sudo systemctl status tor@default
sudo journalctl -u tor@default -n 50

몇 분 이내에 로그에 다음 줄이 나타나야 합니다:

Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.

이 문장은 다른 릴레이들이 귀하의 ORPort에 성공적으로 연결하여 회로를 구축했음을 의미합니다. 이 메시지가 나타나기 전까지는 귀하의 릴레이가 디렉터리에 포함되지 않으며 트래픽을 처리하지 않습니다. 실패 시에는 다음과 같은 메시지가 출력됩니다:

Your server has not managed to confirm reachability for its ORPort(s) at 203.0.113.10:9001. Relays do not publish descriptors until their ORPort and DirPort are reachable. Please check your firewalls, ports, address, /etc/hosts file, etc.

다음 순서대로 문제를 해결하십시오. ufw에서 ORPort가 열려 있는지 확인하십시오. 제공업체의 별도 네트워크 방화벽에서도 포트가 열려 있는지 확인하십시오. 메시지에 표시된 주소가 NAT 설정으로 인한 사설 주소가 아니라, 인터넷에서 실제로 귀하의 서버로 라우팅되는 주소인지 확인하십시오. 다른 기기에서 nc -vz 203.0.113.10 9001 명령을 사용하여 포트를 테스트하십시오. Tor는 자체적으로 테스트를 반복하므로 방화벽 설정을 수정하면 별도의 조치 없이도 감지되며, 서비스를 재시작하면 즉시 반영됩니다.

릴레이의 고유 식별자는 핑거프린트(fingerprint)입니다:

sudo cat /var/lib/tor/fingerprint

디스크립터가 게시된 후 약 3시간이 지나면 Relay Search에서 릴레이를 확인할 수 있습니다. 닉네임으로 검색하거나 핑거프린트를 붙여넣으십시오. 해당 페이지는 네트워크가 귀하의 릴레이를 어떻게 인식하는지 보여줍니다. 여기에는 릴레이가 보유한 플래그, 권한 기관이 부여한 가중치, 게시 중인 버전 정보가 포함됩니다.

새로 구축한 Tor 릴레이에 트래픽이 거의 없는 이유는 무엇입니까?

네트워크가 아직 해당 릴레이를 측정하지 않았기 때문이며, 측정에는 수주가 소요됩니다. Tor Project는 이 트래픽 증가 과정을 4단계로 설명하고 있으나, 이를 읽지 않은 운영자는 릴레이가 고장 났다고 판단하여 설정을 변경하기 시작합니다.

첫 3일 동안 릴레이는 측정되지 않은 상태입니다. 릴레이는 자체 테스트 결과를 보고하지만, 디렉터리 권한(directory authorities)은 게시된 가중치를 20 KB로 제한하므로 클라이언트는 거의 이 릴레이를 선택하지 않습니다. 약 3일에서 8일 사이에는 대역폭 권한(bandwidth authorities)이 실제 측정을 수행하며 가중치가 상승하지만, 클라이언트가 신규 릴레이를 첫 번째 홉(hop)으로 선택하지 않기 때문에 중간 홉으로만 사용됩니다.

약 8일이 지나면 릴레이는 Guard 플래그를 획득할 자격을 갖춥니다. 이 플래그를 획득하면 오히려 트래픽이 감소하는데, 이는 모두를 놀라게 하는 현상입니다. 클라이언트는 중간 홉을 선택할 때 가드가 이미 바쁘다고 가정하여 가드를 건너뛰기 때문에, 릴레이는 가드 트래픽을 얻기 전에 중간 트래픽을 잃게 됩니다. 트래픽은 클라이언트가 가드 세트를 교체함에 따라 서서히 채워지며, 이 과정에는 수주가 걸립니다. 약 68일경이 되면 릴레이를 이탈하는 클라이언트와 새로 추가하는 클라이언트의 수가 균형을 이루는 안정 상태에 도달합니다.

따라서 3일 동안은 아무런 트래픽이 없는 것이 정상이며, 일주일 후부터 조금씩 증가하고, 두 달이 지나야 실제 부하가 발생합니다. 설정을 하나 변경했다면, 그 결과가 나타날 때까지 일주일을 기다려야 합니다. 9001번 포트에 대한 TCP 체크를 포함한 직접 호스팅하는 Uptime Kuma 상태 페이지를 활용하는 것이 불안함을 해소하는 데 더 도움이 됩니다. 이는 사용자가 실제로 제어할 수 있는 부분, 즉 포트가 여전히 응답하고 있는지에 대한 질문에 답을 주기 때문입니다.

nyx를 사용하여 릴레이 모니터링하기

nyx는 실행 중인 릴레이를 위한 터미널 모니터입니다. 이 도구는 tor의 제어 포트와 통신하므로, 먼저 torrc에서 해당 기능을 활성화해야 합니다.

ControlPort 9051
CookieAuthentication 1
CookieAuthFileGroupReadable 1

ControlPort은 127.0.0.1에서만 수신 대기하며, 쿠키 인증 방식을 사용하므로 프로그램이 명령을 내리기 전에 비밀 파일을 읽어야 합니다. Tor는 해당 쿠키를 /run/tor/control.authcookie에 debian-tor 사용자의 권한으로 기록하며, 모드는 600으로 설정되어 다른 사용자가 읽을 수 없습니다. CookieAuthFileGroupReadable 1는 해당 파일을 그룹에 공개하며, 이를 통해 본인 계정으로 sudo 없이 nyx를 실행할 수 있게 됩니다.

sudo apt install -y nyx
sudo adduser "$USER" debian-tor
sudo systemctl restart tor@default

로그아웃 후 다시 로그인한 다음 nyx를 실행하십시오. 새로운 그룹 권한은 로그인 시점에 적용되므로, 설정을 올바르게 마쳤더라도 동일한 셸 세션에서 nyx를 실행하면 쿠키 파일에 대한 권한 오류가 발생합니다. nyx는 실시간 대역폭, 가동 시간, 로그 스트림 및 연결 목록을 보여줍니다. 운영 초기 몇 주 동안은 대역폭 그래프가 RelayBandwidthRate 아래로 유지되는지 확인하는 것이 중요합니다.

여러 개의 릴레이 운영: MyFamily 및 패밀리 키

릴레이를 하나만 운영한다면 이 섹션은 건너뛰어도 됩니다. 동일한 운영자가 두 개 이상의 릴레이를 운영하는 경우, 클라이언트가 귀하의 서버를 거쳐 들어오고 나가는 회로를 구성하지 않도록 서로를 선언해야 합니다. 이를 방지하지 않으면 운영자가 회로의 양 끝단을 모두 관찰할 수 있게 됩니다.

오랫동안 사용해 온 방식은 모든 릴레이의 torrc 파일에 MyFamily을 설정하고 다른 모든 릴레이의 핑거프린트를 나열하는 것입니다.

MyFamily AAAAAAAAAA,BBBBBBBB

모든 릴레이가 서로를 나열해야 하므로, 네 번째 릴레이를 추가하려면 네 개의 파일을 모두 수정해야 합니다. Tor 0.4.9 버전부터는 이를 패밀리 키(family key)로 대체했습니다. 키를 하나 생성한 뒤 공유하십시오.

tor --keygen-family myfamily

이 명령은 myfamily.secret_family_key 파일을 생성하고 FamilyId 라인을 출력합니다. 키 파일을 모든 릴레이의 DataDirectory 내 keys 하위 디렉터리(Debian 및 Ubuntu의 경우 /var/lib/tor/keys)로 복사하십시오. 이때 .secret_family_key 접미사를 유지해야 합니다. 출력된 FamilyId 라인을 각 torrc 파일에 추가하고 sudo systemctl reload tor@default 명령으로 설정을 다시 불러오십시오. 당분간은 MyFamily 목록도 그대로 유지하십시오. 패밀리 인증서를 아직 인식하지 못하는 클라이언트는 기존 목록을 계속 참조하며, 해당 목록을 제거할 수 있는 시점은 Tor Project에서 공지할 예정입니다.

실행 후 발생하는 문제

버전이 구버전이 됩니다. 자동 업데이트(Unattended upgrades)가 패키지를 교체하더라도, 실행 중인 프로세스는 서비스를 재시작하기 전까지는 처음 시작할 때의 바이너리를 계속 사용합니다. 서버의 tor --version과 릴레이의 Relay Search 페이지에 표시된 버전을 비교하십시오. 두 버전이 다르면 네트워크는 여전히 구버전을 인식하고 있는 상태이므로 서비스를 재시작해야 합니다.

시스템 시간이 어긋납니다. 컨센서스 문서와 인증서는 모두 유효 기간이 정해져 있습니다. 따라서 시스템 시간이 크게 차이 나는 서버는 컨센서스를 거부하고 데이터 전송을 중단합니다. timedatectl 명령은 시스템 시간이 동기화되었는지 보고해야 합니다. 만약 동기화되지 않았다면 systemd-timesyncd을 활성화하거나 chrony를 설치하십시오.

IP 주소가 변경됩니다. 디스크립터에는 IP 주소가 포함되어 있으며, 클라이언트는 변경된 주소로 접속할 수 없습니다. 공급자 이전이나 주소 변경 후에는 tor를 재시작하고 자가 진단(self-test) 로그가 출력되는지 확인하십시오.

릴레이 속도가 계획보다 느립니다. Tor의 릴레이 암호화는 최신 프로세서에서 효율적으로 작동하며, Tor Project는 AES-NI를 지원하는 CPU의 경우 양방향으로 대략 400에서 450 Mbit/s의 성능을 낼 수 있다고 봅니다. 이 한계치에 도달하기 훨씬 전에 포트 속도나 데이터 전송량 제한에 먼저 걸리게 됩니다. 이것이 앞서 언급한 계정(accounting) 섹션이 하드웨어보다 더 중요한 이유입니다.

FAQ

Tor 릴레이는 대역폭을 얼마나 사용합니까?

설정한 만큼만 사용하며 그 이상은 사용하지 않습니다. RelayBandwidthRate은 각 방향의 릴레이 트래픽을 개별적으로 제한하므로, 1 Mbit/s로 설정된 릴레이는 동시에 1 Mbit/s의 수신 및 발신 트래픽을 처리할 수 있습니다. 이는 양방향을 합쳐 하루에 약 21.6 GB, 30일 기준으로 648 GB에 해당합니다. 해당 속도 아래에서 엄격한 월간 할당량을 적용하려면 AccountingMax과 AccountingRule sum를 추가하십시오.

Tor 릴레이를 운영하면 악용 사례 신고가 들어옵니까?

가드(guard) 릴레이나 미들(middle) 릴레이는 다른 Tor 릴레이로만 트래픽을 전달하며 사용자를 대신해 웹사이트에 직접 연결하지 않으므로, Tor를 통한 행위에 대한 신고는 귀하가 아닌 엑시트(exit) 운영자에게 전달됩니다. 릴레이 주소가 공개적으로 목록에 올라가기 때문에 스캔 시도나 간헐적인 IP 평판 목록 등재는 발생할 수 있습니다. 엑시트 릴레이는 악용 관련 메일이나 법적 통지를 직접 받으므로, 이를 처리하기로 사전에 동의한 호스팅 업체를 이용해야 합니다. 어떤 유형의 릴레이를 시작하든 먼저 제공업체의 이용 약관을 읽어보십시오.

새로 만든 Tor 릴레이에 트래픽이 전혀 들어오지 않는 이유는 무엇입니까?

새 릴레이는 측정되기 전까지 설계상 속도가 제한되기 때문입니다. 처음 3일 동안은 디렉터리 권한(directory authorities)이 게시된 가중치를 20 KB로 제한하므로 클라이언트가 해당 릴레이를 선택하는 경우가 거의 없습니다. 대역폭 권한(bandwidth authorities)이 약 3일째부터 측정을 시작하며, 약 8일째가 되면 Guard 플래그를 획득할 자격이 생깁니다. 이때 클라이언트가 미들 홉을 선택할 때 가드 릴레이를 피하려는 경향이 있어 트래픽이 일시적으로 감소할 수 있습니다. 전체 부하가 발생하는 시점은 약 68일 후입니다. 로그에 "Self-testing indicates your ORPort is reachable from the outside"라는 메시지가 표시되는지 확인한 후 그대로 두십시오.

1 TB 전송 제한이 있는 VPS에서 Tor 릴레이를 운영할 수 있습니까?

네, 양방향으로 약 1 Mbit/s 속도를 유지하면 가능하며, 이는 RelayBandwidthRate 125 KBytes에 해당합니다. 제공업체가 양방향 트래픽을 모두 측정하는 경우 한 달에 약 648 GB가 소모되므로 업데이트나 백업을 위한 여유 공간이 남습니다. AccountingMax 400 GBytes에 AccountingRule sum와 AccountingStart month 1 00:00을 추가하여 할당량을 초과하는 대신 릴레이가 휴면 상태로 전환되도록 설정하십시오. 제공업체가 발신 트래픽만 과금하는 경우 속도를 두 배로 높일 수 있습니다.

릴레이를 하나만 운영해도 MyFamily를 설정해야 합니까?

아닙니다. Family 선언은 클라이언트가 동일한 운영자가 소유한 두 릴레이를 거쳐 회로를 구성하지 않도록 하기 위한 것이므로, 릴레이가 하나뿐이라면 의미가 없습니다. 두 번째 릴레이를 추가하는 즉시 설정하십시오. 모든 릴레이의 MyFamily 라인에 각 릴레이의 핑거프린트를 나열하거나, Tor 0.4.9에서 도입된 family 키를 사용하십시오. 이 키를 사용하면 계속 늘어나는 목록 대신 하나의 FamilyId을 배포할 수 있습니다.

#tor#relay#bandwidth #privacy #self-hosting #free-speech