Владельцам узлов

  • Не используйте пакеты из репозиториев Ubuntu. Они не всегда корректно обновляются. С ними вы будете пропускать важные обновления, обеспечивающие стабильность и защиту.
  • Определите версию Ubuntu с помощью такой команды:
     ‪$ lsb_release -c
  • Работая с правами суперпользователя, добавьте следующие строки в файл "/etc/apt/sources.list". Замените "version" на версию Ubuntu, определенную ранее:
     deb https://deb.torproject.org/torproject.org version main
 deb-src https://deb.torproject.org/torproject.org version main
  • Добавьте GPG-ключ для подписи пакетов:
     ‪$ curl https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc | sudo apt-key add -
  • Установите Tor и проверьте подписи:
     ‪$ sudo apt-get update
 ‪$ sudo apt-get install tor deb.torproject.org-keyring

Простыми словами:

  • Есть главный идентификационный секретный ключ ed25519 – файл с названием "ed25519_master_id_secret_key". Это самый важный ключ. Убедитесь, что сделали резервную копию и храните ее в надёжном месте. Этот файл уязвим и нуждается в защите. Tor может его для вас зашифровать, если вы создадите ключ вручную и в ответ на запрос укажете пароль.
  • Для использования в Tor генерируется среднесрочный подписывающий ключ с названием "ed25519_signing_secret_key". Кроме того, создается сертификат "ed25519_signing_cert". Он подписан главным идентификационным секретным ключом и подтверждает, что среднесрочный подписывающий ключ актуален в определённый промежуток времени. По умолчанию этот промежуток – 30 дней, но его можно настроить в файле "torrc" с помощью параметра "SigningKeyLifetime N days|weeks|months".
  • There is also a primary public key named "ed25519_master_id_public_key", which is the actual identity of the relay advertised in the network. Этот ключ не нуждается в защите. Его можно вычислить, зная "ed5519_master_id_secret_key".

Tor нужен доступ только к среднесрочному ключу подписи и сертификату в пределах их срока действия. Таким образом, главный секретный идентификационный ключ узла Tor может храниться вне папки "DataDirectory/keys", например, на съёмном носителе или на другом компьютере. Вам придется вручную обновить среднесрочный ключ подписи и сертификат до истечения их срока действия, в противном случае процесс Tor на узле завершится по его истечении.

Эта опция не является обязательной. Вы можете использовать её по необходимости. Если вы предпочитаете, чтобы ваш узел работал продолжительное время без регулярного ручного обновления среднесрочного подписывающего ключа, лучше оставить главный секретный идентификационный ключ узла в папке "DataDirectory/keys". Просто сделайте резервную копию этого ключа на случай переустановки. Если вы хотите использовать эту опцию, вам может пригодиться наше подробное руководство.

Tor has partial support for IPv6 and we encourage every relay operator to enable IPv6 functionality in their torrc configuration files when IPv6 connectivity is available. В настоящее время Tor требует для своих узлов адреса IPv4. Вы не можете организовать узел Tor только с IPv6.

Чаще всего байт на входе в узел Tor означает и байт на выходе. Но есть несколько исключений.

Если у вас открыт DirPort, клиенты Tor будут скачивать с вашего узла копию директории. Присылаемый запрос крошечный (HTTP GET), а ответ довольно большой. Из-за этой разницы, в основном, и образуется расхождение между числом принятых и переданных байтов.

У операторов выходных узлов есть еще одно небольшое исключение. Иногда вы получаете совсем немного данных (например, для мессенджера или SSH) и упаковываете их в полноразмерный 512-байтовый пакет для передачи через сеть Tor.

Мы хотим, чтобы организация узла Tor была простой и удобной:

  • Ничего, если узел иногда оказывается офлайн. Управляющие узлы быстро замечают эту проблему и перестают использовать ваш узел. Постарайтесь, чтобы это не происходило слишком часто. Ведь любое соединение, которое использовало ваш узел в момент выхода его из строя, прервётся.
  • У каждого узла Tor есть политика исходящего трафика. В ней определяется, какие типы исходящих соединений разрешены (или не разрешены) для этого узла. Если вы не хотите, чтобы люди могли использовать ваш узел как выходной, настройте эту политику так, чтобы разрешать только подключения к другим узлам Tor.
  • Ваш узел в пассивном режиме будет оценивать и анонсировать вашу недавнюю пропускную способность. Узлы с высокой пропускной способностью привлекают больше пользователей, чем узлы с низкой пропускной способностью. Но последние тоже полезны.

Значения параметров AccountingMax и BandwidthRate применяются к функциям как узла Tor, так и клиента. Как только Tor впадет в спячку (гибернацию), вы можете остаться с неработающим браузером. В журнале появится такая запись:

Достигнут мягкий предел пропускной способности; приступаем к гибернации.
Новые подключения не допускаются

Решение вопроса – запускать два процесса Tor: один для узла, второй клиентский, и у каждого свои настройки. Один из способов сделать это (если вы начали с настройки рабочего Tor-узла):

  • В файле "torrc" узла Tor просто установите SocksPort на 0.
  • Создайте новый клиентский файл "torrc" из "torrc.sample" и убедитесь, что он использует другой лог-файл узла. Например, "torrc.client" и "torrc.relay".
  • Измените клиент Tor и стартовые скрипты узла; включите -f /path/to/correct/torrc.
  • В Linux/BSD/mac OS X изменение стартовых скриптов на Tor.client и Tor.relay может упростить разделение настроек.

Мы ищем людей с относительно стабильным интернетом, готовых поделиться как минимум 10 Mбитi/с в обе стороны. Если это вы, пожалуйста, подумайте о том, чтобы поддерживать у себя узел Tor.

Даже если у вас нет этих 10 Мбит/с, вы можете помочь сети Tor, если станете поддерживать у себя мост Tor с obfs4. В этом случае понадобится минимум 1 Мбит/с в обе стороны.

См. инструкции по настройке проброса портов в вашем маршрутизаторе.

Если ваш узел запущен во внутренней сети, вам потребуется настроить проброс портов. Forwarding TCP connections is system dependent but the firewalled-clients FAQ entry offers some examples on how to do this.

Например, так можно настроить брандмауэр GNU/Linux на базе iptables:

/sbin/iptables -A INPUT -i eth0 -p tcp --destination-port 9001 -j ACCEPT

Вам может потребоваться изменить "eth0", если у вас несколько внешних сетевых интерфейсов (подключенных к интернету). Скорее всего, у вас он только один (за исключением интерфейса loopback), и определить его должно быть не слишком сложно.

BridgeDB implements four mechanisms to distribute bridges: HTTPS, Moat, Email, and Reserved. Bridge operators can check which mechanism their bridge is using, on the Relay Search. Enter the bridge's <HASHED FINGERPRINT> in the form and click "Search".

Operators can also choose which distribution method their bridge uses. To change the method, modify the BridgeDistribution setting in the torrc file to one of these: https, moat, email, none, any.

Read more on the Bridges post-install guide.

Да, при определённых атаках.

Простой пример: у самого злоумышленника есть несколько узлов Tor. Злоумышленник увидит, что трафик исходит от вас, но не сможет узнать, появился ли этот трафик на вашем компьютере или вы просто посредник.

В некоторых случаях это не работает. Например, если злоумышленник имеет возможность отслеживать весь ваш входящий и исходящий трафик. В этом случае ему нетрудно выяснить, какие данные вы просто передаёте, а какие изначально ваши. (В этом случае адреса назначения все еще скрыты от злоумышленника, если только злоумышленник также не отслеживает их. Ваша ситуация не лучше, чем если бы вы были обычным клиентом).

Поддержка узла Tor имеет свои минусы. Во-первых, у нас всего несколько сотен узлов. Если вы поддерживаете один из них, это может навести злоумышленника на мысль о том, что анонимность имеет для вас большое значение. Во-вторых, есть менее явные виды атак, недостаточно исследованные, которые используют знание того, что вы поддерживает узел Tor. Например, злоумышленник может следить за тем, пересылаете ли вы трафик, даже без доступа к вашей сети. Он будет перенаправлять трафик на ваш узел и отмечать изменения во времени прохождения пакетов данных.

Чего тут больше – плюсов или минусов – сказать трудно. Многое зависит от того, какие типы атак волнуют вас сильнее. Для большинства пользователей поддержка узла Tor – разумный ход.

Теперь ваш узел входной (сторожевой). В других качествах его будут использовать меньше. Но клиенты не будут спешить сменить свои текущие сторожевые узлы на ваш. Подробнее об этом можно прочесть в блоге или в статье Changing of the Guards: A Framework for Understanding and Improving Entry Guard Selection in Tor.

Если вы поддерживаете выходной узел, некоторые сервисы, к которым пользователи подключаются через вас, будут запрашивать обратное соединение, чтоб собрать больше информации. Например, сервер чата IRC подключается к порту identd, чтобы узнать, какой пользователь устанавливает соединение. (У IRC в данном случае ничего не получится, потому что у Tor просто нет этой информации). Кроме того, пользователи вашего выходного узла могут привлечь внимание других пользователей IRC, сайта и прочих, кто хотел бы узнать побольше об узле, с которого они подключаются.

Те, кто сканирует интернет в поисках открытых прокси-серверов, могут заметить, что иногда узлы Tor открывают свой SocksPort всему миру. Мы рекомендуем ограничить доступ к SocksPort локальной сетью.

В любом случае нужно выполнять обновления безопасности. Другие идеи о безопасности узлов Tor изложены в этой статье.

On relay search we show an amber dot next to the relay nickname when this is overloaded. This means that one or many of the following load metrics have been triggered:

Note that if a relay reaches an overloaded state we show it for 72 hours after the relay has recovered.

If you notice that your relay is overloaded please:

  1. Check https://status.torproject.org/ for any known issues in the "Tor network" category.

  2. Consider tuning sysctl for your system for network, memory and CPU load.

  3. Consider enabling MetricsPort to understand what is happening.

Tuning sysctl for network, memory and CPU load

TCP port exhaustion

If you are experiencing TCP port exhaustion consider expanding your local port range. You can do that with

‪# sysctl -w net.ipv4.ip_local_port_range="15000 64000"

или

‪# echo 15000 64000 > /proc/sys/net/ipv4/ip_local_port_range

DNS timeout

If you are experiencing DNS timeout, you should investigate if this is a network or a resolver issue.

In Linux in resolve.conf there is an option to set a timeout:

timeout:n
  Sets  the  amount of time the resolver will wait for a response from a remote
  name server before retrying the query via a different name server.
  This may not be the total time taken by any resolver API call and there is no guarantee
  that a single resolver API call maps to a single timeout.
  Measured in seconds, the default is RES_TIMEOUT (currently 5, see <resolv.h>).
  The value for this option is silently capped to 30.

Check $ man resolve.conf for more information.

MetricsPort

Consider enabling MetricsPort to understand what is happening.

MetricsPort data for relays has been introduced since version >= 0.4.7.1-alpha, while the overload data has been added to the relay descriptors since 0.4.6+.

It's important to understand that exposing the tor MetricsPort publicly is dangerous for the Tor network users.

Please take extra precaution and care when opening this port, and close it when you are done debugging. Set a very strict access policy with MetricsPortPolicy and consider using your operating systems firewall features for defense in depth.

Here is an example of what output enabling MetricsPort will produce:

‪# HELP tor_relay_load_onionskins_total Total number of onionskins handled
‪# TYPE tor_relay_load_onionskins_total counter
tor_relay_load_onionskins_total{type="tap",action="processed"} 0
tor_relay_load_onionskins_total{type="tap",action="dropped"} 0
tor_relay_load_onionskins_total{type="fast",action="processed"} 0
tor_relay_load_onionskins_total{type="fast",action="dropped"} 0
tor_relay_load_onionskins_total{type="ntor",action="processed"} 0
tor_relay_load_onionskins_total{type="ntor",action="dropped"} 0
‪# HELP tor_relay_exit_dns_query_total Total number of DNS queries done by this relay
‪# TYPE tor_relay_exit_dns_query_total counter
tor_relay_exit_dns_query_total{record="A"} 0
tor_relay_exit_dns_query_total{record="PTR"} 0
tor_relay_exit_dns_query_total{record="AAAA"} 0
‪# HELP tor_relay_exit_dns_error_total Total number of DNS errors encountered by this relay
‪# TYPE tor_relay_exit_dns_error_total counter
tor_relay_exit_dns_error_total{record="A",reason="success"} 0
tor_relay_exit_dns_error_total{record="A",reason="format"} 0
tor_relay_exit_dns_error_total{record="A",reason="serverfailed"} 0
tor_relay_exit_dns_error_total{record="A",reason="notexist"} 0
tor_relay_exit_dns_error_total{record="A",reason="notimpl"} 0
tor_relay_exit_dns_error_total{record="A",reason="refused"} 0
tor_relay_exit_dns_error_total{record="A",reason="truncated"} 0
tor_relay_exit_dns_error_total{record="A",reason="unknown"} 0
tor_relay_exit_dns_error_total{record="A",reason="timeout"} 0
tor_relay_exit_dns_error_total{record="A",reason="shutdown"} 0
tor_relay_exit_dns_error_total{record="A",reason="cancel"} 0
tor_relay_exit_dns_error_total{record="A",reason="nodata"} 0
tor_relay_exit_dns_error_total{record="PTR",reason="success"} 0
tor_relay_exit_dns_error_total{record="PTR",reason="format"} 0
tor_relay_exit_dns_error_total{record="PTR",reason="serverfailed"} 0
tor_relay_exit_dns_error_total{record="PTR",reason="notexist"} 0
tor_relay_exit_dns_error_total{record="PTR",reason="notimpl"} 0
tor_relay_exit_dns_error_total{record="PTR",reason="refused"} 0
tor_relay_exit_dns_error_total{record="PTR",reason="truncated"} 0
tor_relay_exit_dns_error_total{record="PTR",reason="unknown"} 0
tor_relay_exit_dns_error_total{record="PTR",reason="timeout"} 0
tor_relay_exit_dns_error_total{record="PTR",reason="shutdown"} 0
tor_relay_exit_dns_error_total{record="PTR",reason="cancel"} 0
tor_relay_exit_dns_error_total{record="PTR",reason="nodata"} 0
tor_relay_exit_dns_error_total{record="AAAA",reason="success"} 0
tor_relay_exit_dns_error_total{record="AAAA",reason="format"} 0
tor_relay_exit_dns_error_total{record="AAAA",reason="serverfailed"} 0
tor_relay_exit_dns_error_total{record="AAAA",reason="notexist"} 0
tor_relay_exit_dns_error_total{record="AAAA",reason="notimpl"} 0
tor_relay_exit_dns_error_total{record="AAAA",reason="refused"} 0
tor_relay_exit_dns_error_total{record="AAAA",reason="truncated"} 0
tor_relay_exit_dns_error_total{record="AAAA",reason="unknown"} 0
tor_relay_exit_dns_error_total{record="AAAA",reason="timeout"} 0
tor_relay_exit_dns_error_total{record="AAAA",reason="shutdown"} 0
tor_relay_exit_dns_error_total{record="AAAA",reason="cancel"} 0
tor_relay_exit_dns_error_total{record="AAAA",reason="nodata"} 0
‪# HELP tor_relay_load_tcp_exhaustion_total Total number of times we ran out of TCP ports
‪# TYPE tor_relay_load_tcp_exhaustion_total counter
tor_relay_load_tcp_exhaustion_total 0
‪# HELP tor_relay_load_socket_total Total number of sockets
‪# TYPE tor_relay_load_socket_total gauge
tor_relay_load_socket_total{state="opened"} 135
tor_relay_load_socket_total 1048544
‪# HELP tor_relay_load_oom_bytes_total Total number of bytes the OOM has freed by subsystem
‪# TYPE tor_relay_load_oom_bytes_total counter
tor_relay_load_oom_bytes_total{subsys="cell"} 0
tor_relay_load_oom_bytes_total{subsys="dns"} 0
tor_relay_load_oom_bytes_total{subsys="geoip"} 0
tor_relay_load_oom_bytes_total{subsys="hsdir"} 0
‪# HELP tor_relay_load_global_rate_limit_reached_total Total number of global connection bucket limit reached
‪# TYPE tor_relay_load_global_rate_limit_reached_total counter
tor_relay_load_global_rate_limit_reached_total{side="read"} 0
tor_relay_load_global_rate_limit_reached_total{side="write"} 0

Let's find out what some of these lines actually mean:

tor_relay_load_onionskins_total{type="ntor",action="dropped"} 0

When a relay starts seeing "dropped", it is a CPU/RAM problem usually.

Tor is sadly single threaded except for when the "onion skins" are processed. The "onion skins" are the cryptographic work that needs to be done on the famous "onion layers" in every circuits.

When tor processes the layers we use a thread pool and outsource all of that work to that pool. It can happen that this pool starts dropping work due to memory or CPU pressure and this will trigger an overload state.

If your server is running at capacity this will likely be triggered.

‪tor_relay_exit_dns_error_total{...}

Any counter in the "*_dns_error_total" realm indicates a DNS problem.

DNS timeouts issues only apply to Exit nodes. If tor starts noticing DNS timeouts, you'll get the overload flag. This might not be because your relay is overloaded in terms of resources but it signals a problem on the network.

DNS timeouts at the Exits are a huge UX problem for tor users. Therefore Exit operators really need to address these issues to help the network.

‪tor_relay_load_oom_bytes_total{...}

An Out-Of-Memory invocation indicates a RAM problem. The relay might need more RAM or it is leaking memory. If you noticed that the tor process is leaking memory, please report the issue either via Tor gitLab or sending an email to the tor-relays mailing list.

Tor has its own OOM handler and it is invoked when 75%, of the total memory tor thinks is available, is reached. Thus, let say tor thinks it can use 2GB in total then at 1.5GB of memory usage, it will start freeing memory. That is considered an overload state.

To estimate the amount of memory it has available, when tor starts, it will use MaxMemInQueues or, if not set, will look at the total RAM available on the system and apply this algorithm:

    if RAM >= 8GB {
      memory = RAM * 40%
    } else {
      memory = RAM * 75%
    }
    /* Capped. */
    memory = min(memory, 8GB) -> [8GB on 64bit and 2GB on 32bit)
    /* Minimum value. */
    memory = max(250MB, memory)

To avoid an overloaded state we recommend to run a relay above 2GB of RAM on 64bit. 4GB is advised, although of course it doesn't hurt to add more RAM if you can.

One might notice that tor could be called by the OS OOM handler itself. Because tor takes the total memory on the system when it starts, if the overall system has many other applications running using RAM, it ends up eating too much memory. In this case the OS could OOM tor, without tor even noticing memory pressure.

tor_relay_load_socket_total

These lines indicate the relay is running out of sockets. The solution is to increase ulimit -n for the tor process.

tor_relay_load_tcp_exhaustion_total

These lines indicate the relay is running out of TCP ports.

Try to tune sysctl as described above.

tor_relay_load_global_rate_limit_reached_total

If this counter is incremented by some noticeable value over a short period of time, the relay is congested. It is likely being used as a Guard by a big onion service or for an ongoing DDoS on the network.

If your relay is still overloaded and you don't know why, please get in touch with network-report@torproject.org. You can encrypt your email using network-report OpenPGP key.

Настройки статистики в torrc-файле позволяют вам указать максимальное число байтов, которые ваш узел обрабатывает в конкретный промежуток времени.

    AccountingStart day week month [день недели] ЧЧ:ММ

Это настройка времени обнуления счётчика. Например, так ограничивается количество переданных за неделю байт (со сбросом счётчика в 10:00 по средам):

    AccountingStart week 3 10:00
    AccountingMax 500 GBytes

Так настраивается максимум передаваемых узлом данных за учётный период. (Так же ограничены принимаемые данные). Когда наступает время сброса в соответствии с AccountingStart, счётчики, соответствующие AccountingMax, обнуляются.

Пример. Допустим, вы хотите разрешить 50 Гб трафика ежедневно в каждом направлении, и чтобы статистика обнулялась каждый полдень:

    AccountingStart day 12:00
    AccountingMax 50 GBytes

Обратите внимание: ваш узел не вернётся из спячки одновременно с началом учётного периода. Он отметит скорость исчерпания лимита в прошлом периоде и выберет случайный момент для пробуждения в новом интервале. Так мы избегаем ситуации, когда сотни узлов оказались бы в рабочем состоянии в начале месяца, и ни одного узла – в конце месяца.

Если вы можете выделить Tor лишь малый объём трафика по сравнению со скоростью вашего подключения, рекомендуем установить учётный период длиной в сутки. Так вы не окажетесь в ситуации с израсходованным трафиком в первый же день. Просто поделите месячный объем на 30. Возможно, вы также захотите ограничить пропускную способность для более равномерного распределения вашего вклада на протяжении суток. Если вы хотите выделить по X Гб на прием и на передачу, можете установить параметр RelayBandwidthRate равным 20*X Kб. Допустим, вы хотите выделить 50 Гб на приём и столько же на передачу. Попробуйте установить RelayBandwidthRate равным 1000 Kб. Так ваш узел будет каждый день приносить пользу по меньшей мере полсуток.

    AccountingStart day 0:00
    AccountingMax 50 GBytes
    RelayBandwidthRate 1000 KBytes
    RelayBandwidthBurst 5000 KBytes # allow higher bursts but maintain average

Отлично. Именно поэтому мы реализовали политики исходящего трафика.

У каждого узла Tor есть политика исходящего трафика. Она определяет допустимые соединения от лица этого узла. Политики исходящего трафика влияют на клиентов Tor через директорию. Если конечное назначение, выбранное клиентом, запрещено в политике исходящего трафика узла, такой узел автоматически не будет предлагаться. Так владелец каждого узла может сам определять, с какими сервисами и сетями разрешать соединения. Если вы используете политику исходящего трафика по умолчанию, прочтите на нашем сайте о возможных проблемах. Мы также рекомендуем советы Майка Перри (Mike Perry) о том, как поддерживать выходной узел с минимальными рисками.

Политика исходящего трафика по умолчанию разрешает доступ ко многим популярным сервисам (например, просматривать интернет-страницы). Она ограничивает доступ к некоторым сервисам, где выше вероятность возникновения проблем (например, к электронной почте), а также к создающим недопустимо большую нагрузку на сеть Tor (например, к обычным портам файлообменных сервисов). Вы можете изменить политику исходящего трафика в файле torrc. If you want to avoid most if not all abuse potential, set it to "reject *:*". Эта настройка позволит вашему узлу передавать трафик внутри сети Tor, но не разрешит соединяться с внешними сайтами и другими сервисами.

Если вы разрешаете исходящие соединения, убедитесь, что ваш компьютер может корректно преобразовывать имена в IP-адреса. Если какие-либо ресурсы недоступны с вашего компьютера (например, вы ограничены брандмауэром или контентным фильтром), пожалуйста, явным образом укажите эти ресурсы в строчках "reject" вашей политики исходящего трафика. В противном случае пользователи Tor также не смогут пользоваться ими.

Если ваш узел относительно новый, дайте ему время. Tor эвристически выбирает узлы для использования на основе данных контролирующих узлов. На контролирующих узлах собирается информация о пропускной способности вашего узла. Контролирующий узел направляет на ваш узел больше трафика, пока его загрузка не станет оптимальной. О том, как действует новый узел, подробно рассказано в нашем блоге. Если ваш узел действует уже какое-то время, а проблемы остаются, попросите совет в списке "tor-relays".

Прекрасно. Если вы станете поддерживать сразу несколько узлов, чтобы помочь сети, мы будем очень рады. Но, пожалуйста, не включайте несколько десятков узлов в рамках одной сети. Всё-таки ключевые характеристики Tor (помимо прочих) – распределённость и разнообразие.

Если вы решили поддерживать более одного узла, пожалуйста, используйте опцию "MyFamily" в "torrc" для каждого узла. Перечислите ваши узлы через запятую:

MyFamily $fingerprint1,$fingerprint2,$fingerprint3

Здесь каждый fingerprint – 40-значный идентификационный отпечаток (без пробелов).

Таким образом клиенты Tor будут стараться использовать в каждой своей цепочке не более одного из ваших узлов. Следует использовать опцию MyFamily, если у вас есть административный контроль над компьютерами или сетью, даже если эти компьютеры географически находятся в разных местах.

The default open ports are listed below but keep in mind that, any port or ports can be opened by the relay operator by configuring it in torrc or modifying the source code. The default according to src/or/policies.c (line 85 and line 1901) from the source code release release-0.4.6:

reject 0.0.0.0/8
reject 169.254.0.0/16
reject 127.0.0.0/8
reject 192.168.0.0/16
reject 10.0.0.0/8
reject 172.16.0.0/12

reject *:25
reject *:119
reject *:135-139
reject *:445
reject *:563
reject *:1214
reject *:4661-4666
reject *:6346-6429
reject *:6699
reject *:6881-6999
accept *:*

Tor узнает свой IP-адрес, запрашивая у компьютера имя хоста и определяя IP по нему. Нередко бывает, что у людей в файле /etc/hosts хранятся старые записи, которые указывают на старые IP-адреса.

Если это не работает, вам нужно использовать опцию настройки "Address" и указать желаемый IP-адрес вручную. Если компьютер находится за NAT и имеет только внутренний IP-адрес, см. рекомендации в этом разделе относительно динамических IP-адресов.

Кроме того, если у вас много адресов, можете настроить "OutboundBindAddress", чтобы исходящие соединения были с того IP-адреса, который вы хотите "показывать миру".

Почему изменяется нагрузка на узел

Tor управляет пропускной способностью по всей сети. Это обеспечивает умеренную работу для большинства узлов. Но цели Tor отличаются от таких протоколов, как BitTorrent. Tor нужны веб-страницы с низкой задержкой, что требует быстрых соединений с запасом прочности. BitTorrent нужны массовые загрузки, что требует использования всей пропускной способности.

Мы работаем над новым сканером пропускной способности, который легче понять и поддерживать. Он будет обеспечивать диагностику для узлов, которые не измеряются, и узлов, которые имеют низкие показатели.

Зачем Tor нужны сканеры пропускной способности?

Большинство провайдеров сообщают вам максимальную скорость вашего локального соединения. Но у Tor есть пользователи по всему миру, и они подключаются к одному или двум узлам Guard случайным образом. Поэтому нам нужно знать, насколько хорошо каждый узел может соединиться со всем миром.

Таким образом, даже если все операторы узлов установят свою рекламируемую пропускную способность на свою локальную скорость соединения, нам все равно понадобится полномочия управления пропускной способностью для балансировки нагрузки между различными частями Интернета.

Что такое нормальная нагрузка на узел?

Для большинства узлов нормальная загрузка составляет 30%-80% от их мощности. Это хорошо для клиентов: перегруженный узел имеет высокую задержку. (Мы хотим, чтобы узлов было достаточно для загрузки каждого узла на 10%. Тогда Tor будет почти таким же быстрым, как и более широкий Интернет).

Иногда узел работает медленно, потому что его процессор медленный или его соединения ограничены. В других случаях это медленная сеть: узел имеет плохой пиринг с большинством других узлов tor, или слишком большое расстояние до узла.

Определение причины ограничения узла

У замедления узла может быть много причин. Вот как их определить.

Системные ограничения

  • Проверьте использование RAM, процессора и дескриптора порта/файла на вашем узле

Tor регистрирует некоторые из них при запуске. Другие можно просмотреть с помощью популярных или аналогичных инструментов.

Ограничения провайдера

  • Проверьте пиринг в Интернете (пропускная способность, задержка) от вашего поставщика узла к другим узлам. Узлы, проходящие через Comcast, временами были медленными. Узлы за пределами Северной Америки и Западной Европы обычно медленнее.

Ограничения сети Tor

Relay bandwidth can be limited by a relay's own observed bandwidth, or by the directory authorities' measured bandwidth. Here's how to find out which measurement is limiting your relay:

  • Check each of the votes for your relay on consensus-health (large page), and check the median. If your relay is not marked Running by some directory authorities:
    • Does it have the wrong IPv4 or IPv6 address?
    • Is its IPv4 or IPv6 address unreachable from some networks?
    • Are there more than 2 relays on its IPv4 address?

Otherwise, check your relay's observed bandwidth and bandwidth rate (limit). Look up your relay on Metrics. Then mouse over the bandwidth heading to see the observed bandwidth and relay bandwidth rate.

Here is some more detail and some examples: Drop in consensus weight and Rampup speed of Exit relay.

How to fix it

The smallest of these figures is limiting the bandwidth allocated to the relay.

  • If it's the bandwidth rate, increase the BandwidthRate/Burst or RelayBandwidthRate/Burst in your torrc.
  • If it's the observed bandwidth, your relay won't ask for more bandwidth until it sees itself getting faster. You need to work out why it is slow.
  • If it's the median measured bandwidth, your relay looks slow from a majority of bandwidth authorities. You need to work out why they measure it slow.

Doing Your Own Relay Measurements

If your relay thinks it is slow, or the bandwidth authorities think it is slow, you can test the bandwidth yourself:

  • Run a test using tor to see how fast tor can get on your network/CPU.
  • Run a test using tor and chutney to find out how fast tor can get on your CPU. Keep increasing the data volume until the bandwidth stops increasing.

  • Выходные узлы. Однако поддержка такого узла сопряжена с наибольшей публичностью и рисками (в частности, вы не должны запускать их из дома).
  • Если вы предпочитаете минимум усилий для запуска, попробуйте организовать быстрый входной узел.
  • Или мост.

В файле torrc можно указать следующие две опции:

BandwidthRate – максимальная выделяемая полоса пропускания (в байтах в секунду). Например, вы можете установить "BandwidthRate 10 MBytes" для 10 мегабайт в секунду (быстрый интернет) или "BandwidthRate 500 KBytes" для 500 килобайт в секунду (неплохое кабельное подключение). Минимальное значение BandwidthRate – 75 килобайт/с.

BandwidthBurst – пул байтов, который используется в случае кратковременного пика трафика выше BandwidthRate. При этом в среднем полоса пропускания на продолжительном отрезке времени остается ниже BandwidthRate. Низкое значение Rate при высоком Burst обеспечивает соблюдение ограничения "в среднем", при этом пропуская пиковые объёмы трафика, если средние значения не достигали лимита в последнее время. Например, если вы установите "BandwidthBurst 500 KBytes" и используете то же самое значение для BandwidthRate, то вы никогда не будете использовать более 500 килобайт в секунду. Если же вы установите BandwidthBurst выше (например, "5 MBytes"), это позволит пропустить больший поток, пока пул не будет исчерпан.

Если у вас ассимметричное соединение с интернетом (исходящий канал меньше входящего), например, кабельный модем, вам лучше сделать BandwidthRate меньше меньшего (обычно меньше ширины исходящего канала). Иначе может случиться, что вы будете терять много пакетов данных в моменты максимальной нагрузки на канал. Возможно, стоит поэкспериментировать с разными значениями и опытным путем определить, какие настройки обеспечат комфортное подключение. Затем укажите BandwidthBurst равным BandwidthRate.

Если узел Tor находится на компьютере Linux, у владельца есть еще один вариант. Он может установить низкий приоритет трафика Tor по сравнению с остальным трафиком на компьютере. Таким образом увеличение загрузки канала Tor не скажется на личном трафике владельца. A script to do this can be found in the Tor source distribution's contrib directory.

Также, у Tor есть опции спячки (гибернации): с их помощью вы можете ограничить объем передачи данных через Tor за отрезок времени (например 100 гигабайт в месяц). Они описаны ниже.

Обратите внимание, что BandwidthRate и BandwidthBurst указываются в байтах, а не битах.

Нет. Если правоохранительные органы проявят интерес к трафику вашего выходного узла, это может привести к изъятию компьютера. Поэтому лучше не держать выходной узел дома (и не использовать домашнее подключение к интернету).

Лучше подумайте о том, чтобы разместить выходной узел на сервере компании, которая симпатизирует Tor. Обеспечьте для своего выходного узла отдельный IP-адрес. Не пропускайте через узел собственный трафик. Разумеется, лучше воздержаться от хранения любой важной или личной информации на компьютере, где поддерживается выходной узел.

Все исходящие соединения должны быть разрешены. Каждый узел должен иметь возможность связаться с любым другим узлом.

Операторы узлов Tor во многих юрисдикциях защищены теми же общими законами о коммуникациях, которые снимают с провайдеров доступа к интернету ответственность за информацию третьих лиц, передаваемую через их сети. Выходные узлы, которые фильтруют трафик, скорее всего, не подпадают под такую защиту.

Tor выступает за свободный доступ к сети без какого-либо вмешательства. Выходные узлы не должны фильтровать трафик, который проходит через них в интернет. Выходные узлы, уличенные в фильтрации трафика, получают флаг BadExit.

Когда выходной узел неверно настроен или в руках злоумышленников, ему присваивается флаг BadExit. Для Tor это значит "не пропускать трафик через этот узел". Иначе говоря, узлы с таким флагом перестают действовать. Если вашему узлу присвоен этот флаг, значит, мы обнаружили проблему или подозрительную активность, когда наблюдали за трафиком, проходящим через ваш узел, и не смогли с вами связаться. Чтобы решить вопрос, пожалуйста, свяжитесь с теми, кто у нас занимается плохими узлами.

Tor вполне работает с динамическими IP-адресами узлов. Оставьте строчку "Адрес" в torrc пустой, и Tor самостоятельно определит адрес.

Когда обновляете узел Tor или перемещаете его на другой компьютер, весьма важно сохранить те же идентификационные ключи (они хранятся в вашей папке данных DataDirectory, "keys/ed25519_master_id_secret_key" и "keys/secret_id_key"). Рекомендуется делать резервные копии идентификационных ключей, чтобы вы могли восстановить узел в будущем, и репутация узла осталась бы с ним.

Таким образом, если вы будете обновлять свой узел Tor и сохраните прежние torrc и DataDirectory, то обновление пройдет без осложнений, и ваш узел будет использовать тот же ключ. Если необходимо сменить DataDirectory, позаботьтесь о том, чтобы скопировать свои прежние keys/ed25519_master_id_secret_key и keys/secret_id_key.

Обратите внимание: начиная с версии Tor 0.2.7 мы используем новое поколение идентификационных ключей узлов Tor, основанное на эллиптической криптографии с кривой ed25519. В конце концов они заменят старые идентификационные ключи на базе RSA, но это случится не сразу: важно обеспечить совместимость с более старыми версиями. До тех пор у каждого узла будет как идентификационный ключ, основанный на ed25519 (в файле keys/ed25519_master_id_secret_key), так и ключ RSA (в файле keys/secret_id_key). Вам следует сделать резервные копии обоих ключей на случай восстановления узла, смены настройки DataDirectory или переноса узла на новый компьютер.

Ваш узел Tor использует больше памяти, чем вам бы хотелось? Вот почему это может происходить:

  • Если вы используете Linux, вероятны проблемы фрагментации памяти в реализации функции "malloc" в библиотеке "glibc". Иными словами, когда Tor освобождает память для системы, кусочки памяти настолько фрагментированы, что их сложно использовать повторно. Архив исходных кодов Tor поставляется с реализаций функции "malloc" из OpenBSD. В ней меньше проблем с фрагментацией, но выше нагрузка на процессор. Можно указать Tor использовать эту реализацию функции "malloc" следующим образом: ./configure --enable-openbsd-malloc.
  • Если у вас быстрый узел (много открытых TLS-соединений), вы наверняка теряете много памяти на внутренние буферы библиотеки OpenSSL (по 38+ Кб на соединение). Мы изменили OpenSSL, чтобы библиотека активнее освобождала неиспользуемые буферы. Если вы используете OpenSSL 1.0.0 или более позднюю версию, процесс сборки Tor автоматически использует эту возможность.
  • Если потребление памяти по-прежнему велико, попробуйте уменьшить пропускную способность, анонсируемую вашим узлом. Анонс меньшей пропускной способности привлечёт меньше пользователей. Узел не так сильно будет потреблять память. Подробнее опция MaxAdvertisedBandwidth описана в руководстве.

Быстрые узлы Tor обычно потребляют довольно много памяти. Быстрый выходной узел вполне может требовать 500-1000 Мб памяти.

Если вы пользователь Debian или Ubuntu, лучше установить Tor из репозитория Tor Project.

  • Настройка ulimit -n устанавливается в 32768; этого достаточно для поддержания всех необходимых Tor-соединений.
  • Для Tor создается выделенный пользователь. Поэтому Tor не нужно запускаться в режиме суперпользователя (root).
  • Tor добавляется в автозагрузку соответствующим init-скриптом.
  • Tor запускается с опцией --verify-config. Так отлавливается большинство опечаток в конфигурационном файле.
  • Tor может начать c привилегированных портов, а потом сбрасывать привилегии.

You can run a relay in Windows following this tutorials:

You should only run a Windows relay if you can run it 24/7. If you are unable to guarantee that, Snowflake is a better way to contribute your resources to the Tor network.