가이드

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

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 모니터링 및 릴레이가 정상적으로 작동하기까지 필요한 일주일간의 컨센서스 대기 시간에 대해 상세히 안내합니다.

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

Tor 릴레이는 공인 IP 주소를 가진 서버에서 실행되며, 다른 사용자의 암호화된 트래픽을 전달하는 Tor 데몬입니다. 디렉터리 권한(directory authorities)이 이 릴레이를 공개하면, Tor 클라이언트는 이를 통해 회로를 구성합니다. 가드(guard) 또는 중간(middle) 릴레이는 트래픽을 다른 릴레이로만 전달할 뿐, 타인을 대신하여 웹사이트에 직접 연결을 생성하지 않습니다. 이러한 특성 덕분에 악용 관련 메일이 오지 않으며, 일반적인 VPS 환경에서 기여하기에 가장 적합한 형태입니다.

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

가드, 미들, 브리지, 출구 노드: 설치 전 선택하기

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

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

출구 릴레이는 범용 VPS에서 운영하기에 적합하지 않은 유일한 역할입니다. 출구 릴레이는 해당 활동을 사전에 허용하고, 전용 IP 주소와 공개된 악용 신고 연락처를 제공하는 호스팅 업체에서만 운영해야 합니다. 대부분의 일반적인 호스팅 약관은 이를 금지하며, 이를 무시할 경우 서버 정지 및 IP 주소 회수라는 결과를 초래합니다. 가드나 미들 릴레이는 동일한 사용자 트래픽을 처리하면서도 이러한 위험에 노출되지 않습니다.

아래의 모든 설정은 가드/미들 릴레이를 구축하기 위한 것입니다. 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 오류를 출력한다면, Signed-By: 라인에 지정된 경로에 디아머(dearmored) 키가 없는 것이며, 이로 인해 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 오리진을 추가하십시오:

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

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

중요한 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 RAM을 가진 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는 이전 할당량을 소진한 속도를 추적하여 새로운 구간 내의 임의 시점을 선택합니다. 이는 수천 개의 릴레이가 동시에 네트워크에 복귀하는 것을 방지하기 위함입니다. 매달 마지막 주에 릴레이가 사라지면 디렉터리 권한 기관(directory authorities)이 측정하는 안정성 점수가 하락합니다. 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는 자체적으로 테스트를 반복 수행하므로 방화벽 문제를 해결하면 자동으로 감지되며, 서비스를 재시작하면 즉시 반영됩니다.

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

sudo cat /var/lib/tor/fingerprint

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

새로 구축한 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 및 family 키

릴레이를 하나만 운영한다면 이 섹션은 건너뛰어도 됩니다. 동일한 운영자가 두 개 이상의 릴레이를 운영하는 경우, 클라이언트가 귀하의 장비로 들어와서 다시 나가는 회로를 구성하지 않도록 서로를 선언해야 합니다. 이를 방지하지 않으면 한 명의 운영자가 회로의 양쪽 끝을 모두 볼 수 있게 됩니다.

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

MyFamily AAAAAAAAAA,BBBBBBBB

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

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 목록도 그대로 유지하십시오. family 인증서를 아직 인식하지 못하는 클라이언트는 기존 목록을 계속 읽으며, 해당 목록을 제거할 수 있는 시점이 되면 Tor Project에서 공지할 것입니다.

실행 후 문제가 발생하는 경우

버전이 구버전이 됩니다. Unattended upgrades가 패키지를 교체하더라도, 프로세스를 재시작하기 전까지는 기존에 실행된 바이너리가 메모리에 남아 있습니다. 서버의 tor --version 버전과 릴레이의 Relay Search 페이지에 표시된 버전을 비교하십시오. 두 버전이 다르다면 네트워크는 여전히 구버전을 인식하고 있으므로 서비스를 재시작해야 합니다.

시스템 시간이 어긋납니다. 컨센서스 문서와 인증서는 모두 유효 기간이 정해져 있습니다. 따라서 시스템 시간이 크게 어긋난 서버는 컨센서스를 거부하고 릴레이 게시를 중단합니다. timedatectl 명령을 실행했을 때 시스템 시간이 동기화된 상태여야 합니다. 그렇지 않다면 systemd-timesyncd을 활성화하거나 chrony를 설치하십시오.

IP 주소가 변경됩니다. 디스크립터에는 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로 제한하므로 클라이언트가 해당 릴레이를 선택하는 경우가 거의 없습니다. 약 3일 차부터 대역폭 권한(bandwidth authorities)이 측정을 시작하며, 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에서 도입된 패밀리 키를 사용하십시오. 이를 사용하면 계속 늘어나는 목록 대신 하나의 FamilyId만 배포하면 됩니다.

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