Tor exit node 운영 가이드: 설정부터 악용 대응까지

Tor exit node의 역할과 운영자의 정체성

Tor exit node는 회로의 마지막 릴레이입니다. 이 서버가 목적지로 연결을 생성하므로, 목적지 서버는 사용자의 주소가 아닌 운영자의 서버 주소를 기록하게 됩니다. 이 가이드의 모든 결정 사항은 이 사실에서 비롯됩니다. 모든 트래픽이 이 주소를 거쳐 나가므로, 해당 주소는 다른 용도로 사용되지 않아야 하며, 해당 트래픽을 허용하기로 동의한 제공업체의 네트워크를 사용해야 합니다.

exit node를 운영하는 것은 익명성을 추구하는 것과는 정반대의 행위입니다. 릴레이는 누구나 다운로드할 수 있는 공개 디렉터리에 등재됩니다. 운영자의 연락처 주소는 ContactInfo 항목에 기재되며, 역방향 DNS(domain name system) 이름은 해당 서버의 정체를 알립니다. 또한 port 80은 동일한 내용을 안내하는 페이지를 제공하며, 운영자는 자신의 실명으로 직접 악용 사례(abuse) 관련 메일을 처리해야 합니다. 이 시스템에서 exit node 운영자보다 더 쉽게 식별되는 주체는 없습니다. 이것이 바로 이 역할의 본질이며, 이 시스템이 작동하는 이유입니다.

저희는 이러한 노드를 직접 운영합니다. SSD Nodes는 표현의 자유를 지원하기 위해 여러 국가에서 exit relay를 운영하고 있습니다. 저희는 exit 트래픽을 허용하기로 명시적으로 동의한 제공업체로부터 서버를 임대하며, 저희가 직접 해당 네트워크의 제공업체가 되지는 않습니다. 이는 의도적인 결정이며, 다음 섹션에서 그 이유를 설명합니다.

출구 노드가 적합한 곳과 그렇지 않은 곳

출구 노드(exit)는 범용 VPS(virtual private server)에 적합하지 않으며, 여기에는 당사의 서비스도 포함됩니다. 범용 네트워크는 수천 명의 서로 관련 없는 고객이 사용하는 웹사이트, 메일, 백업, 제어 패널을 인접한 주소에서 처리합니다. 출구 노드의 트래픽이 발생하면 해당 주소 중 하나가 스캔 보고서나 스팸 차단 목록에 오르게 되며, 그 영향은 이웃한 주소들까지 미치게 됩니다. 출구 노드를 적절히 운영하는 호스팅 제공업체는 이를 위해 별도의 주소 공간을 할당하고, Tor가 무엇인지 이미 숙지하고 있는 악용 대응 전담 부서(abuse desk)를 운영하는 등 전용 인프라를 갖추고 있습니다.

따라서 이 가이드를 작성하는 호스팅 업체는 다른 곳에서 장비를 구매할 것을 권장합니다. 이것이 실질적인 조언입니다. 당사는 출구 노드 트래픽이 IP 주소에 어떤 영향을 미치는지 잘 알고 있습니다. 당사 역시 타 업체에 비용을 지불하고 트래픽을 처리하고 있으며, 이를 제대로 처리하는 것은 범용 서버를 판매하는 것과는 완전히 다른 사업 영역이기 때문입니다.

Tor Project 또한 더욱 직설적인 표현으로 같은 내용을 전달합니다. 릴레이 유형 페이지에 따르면, 출구 릴레이는 "모든 릴레이 중에서 법적 노출과 책임이 가장 크며", "가정에서 Tor 출구 릴레이를 운영해서는 안 된다"고 명시되어 있습니다. 본인의 프로젝트를 운영 중인 범용 VPS는 생각보다 가정용 환경과 다를 바 없습니다. 이는 귀하가 소중히 여기는 장비이며, 깨끗하게 유지하고 싶은 IP 주소를 사용하기 때문입니다.

일반적인 VPS를 보유하고 있고 이번 주에 네트워크를 돕고 싶다면, 출구 노드가 아닌 일반 릴레이나 브리지(bridge)를 운영하십시오. 이는 차선책이 아닙니다. 위험 요소가 다른 별개의 작업이며, 네트워크에는 두 가지 모두 필요합니다. 일반 릴레이는 목적지로 연결을 직접 생성하지 않으므로 불만 사항이 거의 발생하지 않습니다. Tor 가이드에서는 릴레이 목록에 등재되기 위해 양방향으로 최소 2 MByte/s(초당 메가바이트)의 속도를 권장합니다. 브리지는 검열된 네트워크 환경의 사용자를 위한 비공개 진입점입니다. 24/7 연결 상태와 하나의 열린 TCP(transmission control protocol) 포트가 필요하며, 이는 소형 장비로 수행할 수 있는 가장 가치 있는 작업입니다. 이 두 가지는 이미 보유한 하드웨어에서 운영하기에 적합합니다. 출구 노드는 그렇지 않습니다.

출구 노드 운영에 우호적인 호스팅 업체를 찾는 방법

주문하기 전에 서면으로 문의하고 답변을 보관하십시오. Tor의 출구 노드 가이드라인은 두 단계로 나누어 질문할 것을 권장합니다. 먼저 해당 업체가 Tor 출구 노드 운영을 허용하는지 확인하고, 그 다음으로 전용 IP 주소나 대역을 할당해 줄 수 있는지 물어보십시오. 한 번에 두 가지를 모두 물어보면 반사적으로 거절할 가능성이 높습니다.

다음 네 가지 질문을 통해 해당 업체가 실제로 출구 노드 운영을 지원할 준비가 되어 있는지 판단할 수 있습니다.

• 다른 서비스가 호스팅되지 않는 전용 IP 주소를 할당해 줄 수 있으며, 요청하는 역방향 DNS(reverse DNS) 레코드를 설정해 줄 수 있습니까?
• 악용 신고 메일(abuse mail)은 누가 수신하며, 신고자의 주소를 그대로 유지한 채 편집 없이 저에게 전달해 주어 직접 대응할 수 있게 해 주겠습니까?
• 첫 번째 신고가 접수되면 어떻게 처리합니까? 저에게 먼저 전달합니까, 아니면 즉시 해당 주소를 null-route 처리한 뒤 나중에 통보합니까?
• 이 네트워크에는 이미 몇 개의 출구 노드가 운영 중입니까? Tor 가이드라인은 이에 대해 "우호적인 ISP 한 곳에 너무 많은 출구 노드가 집중되는 것은 도움이 되지 않는다"라고 명확히 밝히고 있습니다.

마지막 질문은 생각보다 중요합니다. 출구 노드의 가치는 네트워크 내 위치에 따라 결정됩니다. 이미 50개의 노드가 있는 네트워크에 추가하는 것보다, 새로운 네트워크에 배치하는 것이 훨씬 더 큰 기여를 합니다. Relay Search를 통해 어떤 네트워크에 이미 출구 노드가 있는지 확인할 수 있으므로, 계약 전에 미리 검토하십시오.

결제 전에 답변을 확보하고, 다른 서버를 운영 중인 계정에 추가하지 말고 별도의 계정으로 서버를 구매하십시오. VPS 호스팅의 안전성은 주로 어떤 서비스를 함께 배치하느냐에 달려 있으며, 이는 해당 원칙을 보여주는 가장 명확한 사례입니다.

하나의 주소, 하나의 역할

출구 노드의 주소에는 다른 서비스를 운영해서는 안 됩니다. 웹사이트, 메일, VPN, 모니터링 대시보드, 개인용 SSH(secure shell) 점프 호스트 등을 배치하지 마십시오. 해당 주소는 차단 목록(blocklist)에 오르게 되며, 그곳에서 실행 중인 다른 서비스들은 디버깅하기 어려운 방식으로 오작동하기 시작합니다. 단일 목적의 주소를 사용하면 불만 사항에 대한 답변도 간단해집니다. "이 주소는 Tor 출구 릴레이이며, 그 외의 용도로는 사용하지 않습니다"라고 답하면 됩니다.

Tor를 실행하기 전에 기본적인 보안 작업을 수행하십시오. 비밀번호 로그인을 비활성화하고 키 기반 SSH 인증만 허용하며, 공개할 포트만 허용하는 방화벽을 설정하십시오. VPS에서 SSH 보안 강화하기에서 첫 번째 부분을 다루며, ufw 방화벽 기초에서 두 번째 부분을 다룹니다. 출구 노드는 외부 세계에 정확히 두 개의 포트만 공개합니다. Tor 트래픽을 전달하는 ORPort와 출구 노드 공지 페이지를 위한 80번 포트입니다. 그 외의 모든 포트는 닫혀 있어야 합니다.

무인 업그레이드(unattended upgrades)를 활성화하십시오. 오래된 Tor 빌드를 사용하는 출구 노드는 해당 노드를 거치는 모든 사용자에게 문제가 됩니다.

sudo apt update && sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

로그 기록 기능을 추가하지 마십시오. 출구 노드를 나가는 평문 데이터를 캡처하는 것은 기술적으로는 쉽지만, 운영자가 절대 해서는 안 되는 일입니다. EFF Tor 법률 FAQ에서는 운영자에게 이를 수행하지 말라고 권고합니다. 미국 및 기타 국가의 도청 관련 법률에 따라 해당 트래픽을 검사하는 행위가 운영자에게 법적 책임을 지울 수 있기 때문입니다. Tor의 기본 설정인 notice 수준의 로그만 유지하고 그 이상은 기록하지 마십시오.

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

배포판 패키지는 버전이 뒤처집니다. 보안 패치가 릴리스되는 즉시 적용할 수 있도록 Tor Project의 공식 저장소를 사용하십시오. 2026년 8월 기준으로 현재 안정화 버전 시리즈는 0.4.9입니다.

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

lsb_release -cs이 출력한 코드네임으로 noble를 대체하여 /etc/apt/sources.list.d/tor.sources을 작성하십시오:

Types: deb deb-src
URIs: https://deb.torproject.org/torproject.org/
Suites: noble
Components: main
Signed-By: /usr/share/keyrings/deb.torproject.org-keyring.gpg

서명 키를 추가한 뒤 설치를 진행하십시오:

wget -qO- https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc | gpg --dearmor | sudo tee /usr/share/keyrings/deb.torproject.org-keyring.gpg >/dev/null
sudo apt update
sudo apt install -y tor deb.torproject.org-keyring
tor --version

deb.torproject.org-keyring 패키지는 키를 자동으로 최신 상태로 유지하므로, 키가 갱신되는 날에도 저장소 연결이 끊기지 않습니다. 만약 apt update에서 동일한 저장소가 두 번 설정되었다고 보고한다면, .list 파일과 .sources 파일 양쪽에 해당 저장소가 명시된 상태입니다. deb822 중복 소스 오류 문서에서 이를 해결하는 방법을 확인하십시오.

DNS: 출구 노드가 모든 사용자의 도메인 이름을 해석하도록 설정

출구 노드는 해당 노드를 통과하는 모든 회선의 이름 해석을 수행하므로, 리졸버는 타인의 도메인 이름 요청 스트림을 보게 됩니다. 이를 대형 공개 리졸버로 설정하면 전체 스트림이 단일 기업으로 넘어가게 되며, 이는 Tor가 출구 노드 운영자에게 지양하도록 권고하는 중앙 집중화에 해당합니다. 대신 서버에서 직접 검증 및 캐싱이 가능한 리졸버를 실행하십시오.

sudo apt install -y unbound bind9-dnsutils
sudo cp /etc/resolv.conf /etc/resolv.conf.backup
echo "nameserver 127.0.0.1" | sudo tee /etc/resolv.conf
sudo chattr +i /etc/resolv.conf
sudo systemctl enable --now unbound

chattr +i은 파일을 변경 불가능(immutable) 상태로 만듭니다. DHCP(dynamic host configuration protocol) 클라이언트와 resolvconf가 자체 일정에 따라 /etc/resolv.conf를 덮어쓰기 때문입니다. 이 설정을 하지 않으면 재부팅 시 이름 해석 설정이 다시 제공자의 리졸버로 돌아갈 수 있으며, 변경 사실을 알 수 있는 방법도 없습니다. Tor의 Debian 및 Ubuntu 지침은 각 네임 서버에 실제로 필요한 이름의 일부만 전송하는 쿼리 이름 최소화(query name minimisation) 기능도 활성화합니다.

server:
    qname-minimisation: yes

위 내용을 /etc/unbound/unbound.conf.d/ 아래의 파일에 저장한 뒤, 리졸버가 정상적으로 응답하는지 확인하십시오.

sudo systemctl restart unbound
dig +short example.com @127.0.0.1

응답에 주소가 포함되어 있다면 unbound가 정상적으로 작동하는 것입니다. 만약 address already in use 오류로 unbound가 시작되지 않는다면, 다른 프로세스가 53번 포트를 점유하고 있는 것입니다. sudo ss -lntup | grep :53를 실행하여 해당 포트를 점유 중인 프로세스를 확인하십시오. Ubuntu의 경우 systemd-resolved가 127.0.0.53에서 대기하므로, 127.0.0.1에서 실행되는 unbound와 충돌하지 않습니다.

출구 릴레이를 위한 torrc 설정

Debian 패키지는 /etc/tor/torrc 파일을 읽습니다. 다음은 출구 릴레이 운영과 관련된 전체 설정입니다.

Nickname     exampleExit01
ORPort       443
ExitRelay    1
SocksPort    0
ContactInfo  email:tor[]example.org abuse:abuse[]example.org url:https://example.org ciissversion:3
ReducedExitPolicy 1
Log          notice syslog

이 파일의 모든 줄은 필수적인 역할을 하므로 하나씩 확인하십시오.

ORPort 443는 다른 릴레이가 귀하의 서버에 연결하는 포트입니다. 443 포트를 사용하면 일반적이지 않은 포트를 차단하는 제한적인 네트워크 환경에서도 통신이 가능하므로, 기본값인 9001 포트보다 더 많은 사용자가 귀하의 릴레이에 접근할 수 있습니다. 이 서버에서 다른 서비스가 443 포트를 사용하지 않아야만 이 설정을 적용할 수 있으며, 이는 전용 IP 주소를 사용하는 것이 권장되는 이유 중 하나입니다.

SocksPort 0는 로컬 SOCKS 프록시 기능을 끕니다. 릴레이는 SOCKS 프록시가 필요 없으며, 공인 IP 주소에서 SOCKS 포트를 열어두면 개방형 프록시로 악용되어 수 시간 내에 공격 대상이 될 것입니다.

ExitRelay 1은 해당 노드를 출구 릴레이로 동작하게 만드는 설정입니다. 기본값에 의존하지 말고 명시적으로 설정하여, 설정 파일만 보고도 해당 서버의 역할을 분명히 알 수 있도록 하십시오.

ContactInfo은 누구나 읽을 수 있는 공개 디렉터리에 게시됩니다. 네트워크 도구가 파싱할 수 있도록 ContactInfo 정보 공유 사양 형식으로 작성하고, ciissversion:3을 포함하십시오. @ 대신 []를 사용하는 것은 주소 수집 봇의 동작을 늦추기 위한 해당 사양의 관례입니다. 악용 사례에 대한 메일이 이 주소로 전달되므로 매일 확인하는 메일함을 사용하십시오.

서버에서 IPv6가 정상적으로 작동한다면 IPv6 ORPort를 추가하고 IPv6 출구 기능을 활성화하십시오. 실제 사용이 불가능한 주소를 광고하는 릴레이는 자체 도달 가능성 테스트를 통과하지 못하므로, IPv6를 지원하지 않는 환경이라면 해당 설정을 생략하십시오.

ORPort   [2001:db8::1]:443
IPv6Exit 1

출구 정책: 각 포트별 허용 범위

출구 정책은 릴레이가 연결을 허용할 목적지 목록입니다. Tor는 이 목록을 위에서 아래로 읽으며, 가장 먼저 일치하는 규칙이 적용됩니다. ReducedExitPolicy 1은 웹, 메일 전송, 채팅, Git을 포함한 약 70개의 포트로 구성된 엄선된 목록을 선택하며, 민원이 가장 많이 발생하는 포트는 제외합니다. 이는 첫 출구 릴레이를 운영할 때 시작하기 가장 좋은 설정입니다.

이름으로 기억해 둘 가치가 있는 규칙이 두 가지 있습니다. ExitPolicyRejectPrivate는 기본적으로 활성화되어 있으며, 출구 릴레이가 사설 IP 대역이나 릴레이 자신의 주소로 연결되는 것을 차단합니다. 이는 출구 릴레이가 제공자의 내부 네트워크를 공격하는 상황을 방지합니다. 25번 포트(SMTP, Simple Mail Transfer Protocol)는 거부되어야 하며, 계속 거부 상태로 유지해야 합니다. 이 포트를 허용하면 릴레이가 스팸 발송지로 악용되어 며칠 내로 해당 IP 주소가 차단 목록에 오르게 됩니다.

출구 릴레이가 제 역할을 하려면 최소한 80번과 443번 포트는 허용해야 합니다. Tor의 출구 릴레이 문서에서도 이 최소 요건을 명시하고 있습니다. 만약 제공자가 축소된 정책보다 더 엄격한 제한을 요구한다면, 웹 전용 출구 릴레이로 운영하는 것만으로도 충분히 기여할 수 있습니다.

ExitPolicy accept *:80
ExitPolicy accept *:443
ExitPolicy reject *:*

목록의 마지막에는 reject *:*을 추가하여 정책을 완성하고, 이후에 다른 설정이 상속되지 않도록 합니다. 축소된 정책은 22번 포트(SSH)를 허용하는데, 이는 보통 무차별 대입 공격 신고의 원인이 됩니다. 따라서 관련 메일을 받고 싶지 않다면 나머지 규칙 위에 ExitPolicy reject *:22를 추가하십시오. 6881-6999 범위의 파일 공유 포트는 저작권 침해 통지의 주된 원인이지만, 축소된 정책에서는 이미 제외되어 있습니다.

정책 변경 사항은 릴레이가 새로운 디스크립터를 게시하고 디렉터리 서버에 전파된 이후에야 클라이언트에 반영됩니다. 따라서 변경 효과를 판단하기까지 몇 시간 정도 기다려야 합니다.

연락처 정보, 패밀리 키, 그리고 릴레이 등록

엑시트 릴레이를 등록한다는 것은 낯선 이가 검증할 수 있는 이름과 릴레이를 연결하는 것을 의미합니다. 이를 위해 두 가지 메커니즘이 함께 작동합니다.

첫 번째는 잘 알려진 파일입니다. 본인이 제어하는 도메인에 패밀리 식별 정보를 게시한 다음, ContactInfo에 해당 증명 정보를 명시하십시오:

ContactInfo email:tor[]example.org url:https://example.org proof:uri-familyid-ed25519 ciissversion:3

이 파일은 https://example.org/.well-known/tor-relay/ed25519-family-id.txt에 위치하며 패밀리 ID를 포함합니다. 이제 누구나 이 릴레이들을 운영한다고 주장하는 사람이 해당 도메인도 제어하고 있음을 확인할 수 있습니다. 이것이 일반 연락처 주소와 검증된 연락처 주소의 차이입니다.

두 번째는 패밀리 그 자체입니다. 하나 이상의 릴레이를 운영하는 경우, 클라이언트가 운영자의 릴레이 두 곳을 거쳐 회로를 구성하지 않도록 네트워크에 동일 운영자임을 알려야 합니다. 현재 tor는 0.4.9.2-alpha 버전 이상의 릴레이에서 Happy Families라고 불리는 패밀리 키를 통해 이를 수행합니다:

tor --keygen-family exampleFamily

이 명령은 exampleFamily.secret_family_key을 생성하고 FamilyId 라인을 출력합니다. 비밀 키 파일을 각 릴레이의 키 디렉터리(Debian 및 Ubuntu의 경우 /var/lib/tor/keys)로 복사하고, 파일 이름 끝에 .secret_family_key을 유지한 뒤, 출력된 FamilyId 라인을 각 torrc에 추가하고 tor를 다시 불러오십시오. tor 문서에서는 프로젝트 측에서 더 이상 필요하지 않다고 공지할 때까지 기존의 MyFamily 옵션에 모든 릴레이 지문을 나열해야 한다고 명시하고 있으므로, 두 설정 모두 구성하십시오. 각 릴레이의 지문은 /var/lib/tor/fingerprint에서 확인할 수 있습니다.

두 번째, 세 번째 서버부터는 운영 관리가 중요해지며, 여러 대의 Linux 서버를 동시에 관리하는 것은 다른 환경과 마찬가지로 여기서도 동일한 문제입니다. /var/lib/tor/keys는 반드시 서버 외부의 안전한 곳에 백업하십시오. 이 파일을 분실하면 릴레이는 낯선 존재로 인식되어, 모든 플래그와 평판을 처음부터 다시 쌓아야 합니다.

tor-relays 메일링 리스트도 구독하십시오. 운영자에게 영향을 미치는 변경 사항은 이곳에 가장 먼저 공지됩니다.

역방향 DNS와 80번 포트의 종료 공지

릴레이가 트래픽을 처리하기 전에 역방향 DNS 레코드를 설정하십시오. Tor의 종료 가이드라인은 tor-exit-01.example.org과 같은 형식으로 해당 서버가 무엇인지 알리도록 권장합니다. 이는 실용적인 이유 때문입니다. 낯선 주소가 로그에 나타나면 관리자는 가장 먼저 역방향 조회를 수행합니다. "tor-exit"가 포함된 이름은 관리자가 문의 메일을 보내기 전에 의문을 해소해주며, 이로 인해 발생할 수 있는 불만 사항을 사전에 방지할 수 있습니다. 호스팅 제공업체에 PTR(포인터) 레코드를 설정해달라고 요청하고, 본인의 측에서도 일치하는 정방향 레코드를 추가하십시오.

그다음 80번 포트에 동일한 내용을 알리는 공지 페이지를 제공하십시오. 구형 가이드에서는 Tor의 DirPortFrontPage 설정을 사용하지만, 이는 DirPort에 의존합니다. DirPort는 tor 0.4.6.5 버전부터 릴레이에서 더 이상 사용되지 않으므로, 대신 소형 웹 서버를 사용하십시오.

sudo apt install -y nginx
sudo install -d -m 755 /srv/tor-exit-notice

/srv/tor-exit-notice/index.html를 작성하십시오:

<!DOCTYPE html>
<html>
<head><title>This is a Tor exit relay</title></head>
<body>
<h1>This is a Tor exit relay</h1>
<p>Traffic from this address was sent by a user of the Tor network. It did not
come from the operator of this machine, and this machine keeps no record of
who sent it.</p>
<p>Operator: Example Org. Abuse reports: abuse@example.org. Every report gets a
reply from a person.</p>
<p>To check whether this address was a Tor exit at a given date and time:
https://metrics.torproject.org/exonerator.html</p>
</body>
</html>

다음 서버 블록을 /etc/nginx/sites-available/tor-exit-notice에 작성하십시오:

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name _;
    root /srv/tor-exit-notice;
    index index.html;
    access_log off;
}

이를 활성화하고 nginx의 기본 사이트를 제거한 뒤 결과를 확인하십시오:

sudo ln -sf /etc/nginx/sites-available/tor-exit-notice /etc/nginx/sites-enabled/tor-exit-notice
sudo rm -f /etc/nginx/sites-enabled/default
sudo nginx -t && sudo systemctl reload nginx
curl -s http://127.0.0.1/ | head -n 5

nginx -t가 syntax is ok 및 test is successful을 보고한다면 파일 구문 분석이 성공한 것입니다. curl는 공지 사항의 첫 줄을 출력해야 합니다. 만약 nginx의 환영 페이지가 출력된다면 기본 사이트가 여전히 활성화되어 있어 작성한 블록이 적용되지 않은 상태입니다.

서비스를 시작하고 로그를 확인합니다

sudo systemctl restart tor@default
sudo journalctl -u tor@default -n 50 --no-pager

몇 분 이내에 로그에 다른 릴레이가 귀하의 서버에 도달할 수 있음을 나타내는 줄이 표시되어야 합니다:

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

해당 줄이 나타나지 않는다면 ORPort에 도달할 수 없는 상태입니다. sudo ss -lntp | grep 443 명령으로 Tor가 수신 대기 중인지 확인한 다음, 다른 머신에서 nc -vz your.address.here 443 명령으로 포트를 테스트하십시오. VPS 앞단의 방화벽(사용자가 설정했거나 제공업체 제어판에서 설정된 방화벽)이 일반적인 원인입니다.

systemctl is-enabled tor 명령을 사용하여 재부팅 후에도 서비스가 다시 시작되는지 확인하십시오. 이 명령은 enabled를 출력해야 합니다.

릴레이는 시작 후 약 3시간이 지나면 선택한 닉네임으로 Relay Search에 나타납니다. 네트워크의 대역폭 측정 시스템이 귀하의 릴레이를 관찰해야 클라이언트가 높은 가중치를 부여하므로, 트래픽은 며칠에 걸쳐 서서히 증가합니다. 첫날에 거의 트래픽이 없는 새로운 엑시트 릴레이는 정상입니다.

남용 대응 플레이북과 메일의 형태

첫 번째 불만 사항이 접수되기 전에 플레이북을 작성하십시오. 보통 첫 번째 불만은 운영 첫 주에 들어옵니다. 이러한 메일의 대부분은 기계적으로 생성됩니다. Tor의 출구 노드 가이드라인에 따르면 자동화된 보고서가 전체의 약 80%를 차지하며, 표준화된 답변으로 나머지 대부분의 문제를 해결할 수 있습니다.

실제로 들어오는 메일의 내용은 다음과 같습니다. 누군가의 침입 탐지 시스템이 생성한 스캔 또는 무차별 대입 공격 보고서로, 귀하의 주소와 타임스탬프가 포함되어 있습니다. 파일 공유 포트를 허용하는 정책을 사용하는 경우 저작권 침해 통지가 올 수 있습니다. 사이트 운영자로부터 포럼이나 댓글 스팸 관련 불만이 접수되기도 합니다. 가끔 법 집행 기관으로부터 데이터 보존 요청이나 소환장이 오는 경우가 있는데, 이는 다른 범주에 속하며 템플릿을 찾기보다 변호사와 상담해야 하는 상황입니다.

답변은 짧으며, 거의 매번 동일합니다.

Hello,

Thank you for the report. The address 203.0.113.10 is a Tor exit relay,
operated by <your name> at <your organisation>. The connection you saw was
made by a user of the Tor network. It did not originate on this machine.

This relay keeps no record of which user made which connection, so I cannot
identify the sender and there are no logs for me to hand over.

You can confirm that this address was a Tor exit at the date and time in
question here: https://metrics.torproject.org/exonerator.html

If you would prefer to stop Tor traffic reaching your service, the current
list of exit addresses is published here:
https://check.torproject.org/torbulkexitlist

I read this mailbox personally and will answer any follow-up.

<your name>

이러한 대응을 효과적으로 만드는 네 가지 습관이 있습니다. 첫째, ContactInfo에 명시된 주소로 영업일 기준 1일 이내에 답변하고 본인의 이름을 서명으로 남기십시오. 둘째, 사용자를 식별해주겠다고 절대 약속하지 마십시오. 식별은 불가능하며, 이를 암시한 운영자는 나중에 그 약속을 어겨야 하는 상황에 처하게 됩니다. 셋째, 모든 답변을 하나의 폴더에 보관하여 동일한 사건에 대한 두 번째 메일이 오더라도 같은 답변을 보낼 수 있도록 하십시오. 넷째, 서비스 제공업체가 서비스 중단 경고가 포함된 불만 사항을 전달한 경우, 먼저 제공업체에 답변하고 그 다음에 신고자에게 답변하십시오.

답변의 핵심은 두 개의 링크가 담당합니다. ExoneraTor는 조사관이 실제로 궁금해하는 질문, 즉 '이 주소가 해당 시점에 Tor 출구 노드였는가'에 대한 답을 제공합니다. bulk exit list는 현재 출구 노드 주소를 줄당 하나씩 나열한 단순 목록으로, Tor를 차단하기로 결정한 사람들이 추측에 의존하지 않고 정확하게 차단할 수 있도록 돕습니다.

대역폭, 비용, 그리고 두 번째 릴레이

Exit 릴레이는 실제 트래픽을 처리합니다. 서버를 주문하기 전에 월간 데이터 전송량 한도를 결정하십시오. 또한 허용량을 초과했을 때 제공업체가 비용을 어떻게 청구하는지 확인해야 합니다. VPS의 실제 비용은 명시된 가격보다는 데이터 전송 허용량에 따라 결정되는 경우가 많기 때문입니다. Tor는 다음과 같은 설정을 통해 사용자의 비용 부담을 제어할 수 있습니다.

AccountingMax 4 TBytes
AccountingStart month 1 00:00
RelayBandwidthRate 20 MBytes
RelayBandwidthBurst 25 MBytes

AccountingMax은 설정한 회계 기간 동안 지정된 용량만큼의 트래픽을 전송하면 Tor를 최대 절전 모드로 전환하고, 다음 기간이 시작되면 다시 깨어납니다. 첫 달에는 제공업체의 자체 카운터와 수치를 비교하여 신뢰할 수 있는지 확인하십시오. 두 시스템이 계산하는 바이트 기준이 항상 일치하지는 않기 때문입니다. RelayBandwidthRate은 지속적인 전송 속도를 제한하며, 이는 업링크를 원활하게 유지하고 제공업체의 부담을 줄여줍니다.

두 번째 Exit 릴레이를 추가할 때는 첫 번째 릴레이와 같은 랙이 아닌 다른 네트워크에 배치하십시오. 다양성은 Exit 릴레이가 기여하는 핵심 요소이며, 같은 장소에 있는 두 대의 서버는 동시에 장애가 발생할 수 있습니다. 두 릴레이를 하나의 패밀리로 묶고, 동일한 검증된 연락처 정보를 게시하며, 두 릴레이 모두에 대한 문의 메일에 응답하십시오. 연락할 방법이 없는 Exit 릴레이는 익명의 문제로 취급됩니다. 반면 운영자가 당일에 응답하는 Exit 릴레이는 관리자가 존재하는 서버로 인식되며, 이것이 바로 우리가 지향하는 모습입니다.

FAQ

기존에 사용 중인 VPS에서 Tor exit node를 운영할 수 있습니까?

아니요, 이 부분은 엄격하게 제한해야 합니다. Exit node는 다른 서비스를 운영하지 않는 전용 IP 주소가 필요하며, 사전에 해당 제공업체와 exit 트래픽 허용 및 abuse 메일을 수정 없이 전달받기로 합의되어 있어야 합니다. 일반적인 VPS는 이미 다른 용도로 사용 중이며 다른 고객들과 IP 대역을 공유하므로 적합하지 않습니다. 현재 보유한 장비에서는 non-exit relay나 obfs4 bridge를 운영하십시오. 이는 네트워크에 실질적인 도움이 되며 민원 발생 소지가 거의 없고, 이미 비용을 지불 중인 서버 자원만으로 충분히 운영 가능합니다.

Tor exit relay는 얼마나 많은 abuse 메일을 받으며, 누가 이를 수신합니까?

이는 설정한 exit policy에 따라 다릅니다. ReducedExitPolicy 1를 적용하고 25번 포트를 차단하며 파일 공유 포트를 제외하면, 수신되는 메일의 대부분은 자동화된 스캔이나 무차별 대입 공격(brute-force) 보고서입니다. Tor의 exit 운영 지침에 따르면 자동화된 보고서가 전체의 약 80%를 차지합니다. 메일은 제공업체의 abuse 담당 부서가 전달하는 곳으로 발송되므로, 서버를 주문하기 전에 신고자의 주소를 그대로 유지한 채 메일을 전달해 주는지 확인해야 합니다. ContactInfo과 80번 포트의 공지 페이지에 동일한 연락처를 게시하고, 영업일 기준 1일 이내에 응답하십시오.

실명과 이메일 주소를 반드시 공개해야 합니까?

네. ContactInfo는 공개된 relay 디렉터리에 게시되어 누구나 다운로드할 수 있으며, 역방향 DNS 이름으로 해당 장비의 정체를 알 수 있고, 80번 포트의 공지 페이지에도 명시됩니다. 이러한 투명성은 설계의 일부이며 부작용이 아닙니다. 연락처가 작동하지 않는 exit node는 익명의 골칫거리로 취급되며, 일부 클라이언트는 연락처 정보가 없는 exit node를 차단하기도 합니다. proof:uri-familyid-ed25519와 /.well-known/tor-relay/ed25519-family-id.txt 파일을 본인이 관리하는 도메인에 추가하여, 단순히 기재된 정보가 아니라 검증 가능한 연락처임을 증명하십시오.

새로 구축한 exit relay에 트래픽이 거의 발생하지 않는 이유는 무엇입니까?

먼저 journalctl -u tor@default에 Self-testing indicates your ORPort is reachable from the outside. Excellent.이 포함되어 있는지 확인하십시오. 도달 가능성 테스트를 통과하지 못한 relay는 디렉터리에 게시되지 않아 트래픽이 전혀 발생하지 않습니다. 해당 설정이 정상이라면 보통은 시간이 해결해 줍니다. Relay는 시작 후 약 3시간이 지나야 Relay Search에 나타나며, 네트워크의 대역폭 측정 시스템이 해당 relay를 관찰하고 클라이언트가 의미 있는 트래픽을 보내기까지는 며칠이 소요됩니다. 또한, relay가 exit node로 인정받으려면 80번과 443번 포트를 허용하는 정책이 반드시 설정되어 있어야 합니다.