操作托尔继电器

在看着社会在舒适的隔离中崩溃后，我感到无聊。因此，我选择了操作托尔接力。最初，我想运营一个出口节点，因为它看起来更令人兴奋，我将成为Tor网络和透明网之间的屏障的一部分，但被执法部门踢开我的门或处理数以千计的法律通知的前景让我望而却步。取而代之的是，我选择了运营一个中间中继节点，因为任何法律后果的风险都很低，而且我仍然可以为ToR网络做出贡献。

我将讨论操作中间中继背后的过程(要了解ToR协议本身，请参阅简要概述并与传统代理进行比较)。如果您想自己操作继电器，请参考官方的继电器指南。

作为数据分析和服务器管理的项目，操作ToR中继比预期的要简单-我建议您操作自己的中继。

ToR项目维护一份ISP列表，详细说明允许的ToR相关行为和任何其他评论。我选择使用OVH，因为它以合理的价格提供可接受的网络连接。一旦VPS可用，我就进行身份验证，然后开始设置中继。经过一些管理上的麻烦(例如，保护VPS、配置tor等)，我有了一个可以工作的ToR中继。

root@vps-e0d4d314：~#systemctl status tor@default [email protected]为加载的TCP匿名覆盖网络：已加载(/lib/systemd/system/[email protected]；静态；供应商预设：启用)ACTIVE：ACTIVE：ACTIVE(运行)自星期六2020-06-06 19：09：50 UTC；19分钟前主PID：7542(Tor)cgroup：/system.slice/system-tor.slice/[email protected]└─7542/usr/bin/tor--默认值-torrc/usr/share/tor/tor-service-default-torrc-f/etc/tor/torrc--RunAsDaemon 0。

适当地保护服务器非常重要，因为它将为数千个来往于未知主机的连接提供服务。中继是一个有价值的目标，因为它可以协助相关攻击。

2020年6月6日：中继开始其“未测量阶段”(在新中继的生命周期中描述)，其带宽和稳定性由网络验证。第一阶段将持续几天，需要几个星期的时间才能充分利用接力。然而，这次接力已经被记录在托尔地图集上。

为了改进中继维护，我安装了NYX，它允许实时观察各种中继属性(带宽、连接数量、内存开销等)。在torrc中摆弄CookieAuthentication之后：

然后，我可以查看Nyx仪表板，其中显示了几个中继度量和属性。

尼克斯说，中继传输的速度高达420bps！低带宽是在此阶段应用20KB上限的结果。另外，中继引导阶段记录在日志中。

│19：09：52[通知]自举100%(完成)：完成│19：09：51[通知]自举95%(电路_CREATE)：建立ToR电路│19：09：51[通知]自举90%(AP_HANDSHAK_DONE)：通过中继完成握手以构建电路│19：09：51[通知]自举75%(│_DIINFO)：已加载足够的目录信息来构建电路│19：09：51[通知]自举。│19：09：51[通知]启动14%(握手)：与中继握手│19：09：51[通知]启动10%(CONN_DONE)：已连接到中继.│19：09：51[通知]启动5%(CONN)：正在连接到中继.│19：09：47[通知]启动0%(正在启动)：正在启动。

在自举过程中，中继构建四个电路来估计带宽。查看Connections页面确认有多个活动连接。

2020年6月7日：在第二天，带宽从20KB上限(下降700Kbps，上升500Kbps)增加。在未测量阶段，将该继电器与其他预期的继电器进行比较，并通过bwauths进行测量。在TOR日志中有其他自检的证据。

在撰写本文时，中继通告的带宽为1.98MiB/s，并且分别支持大约1000个输入/出站活动连接。快速旗帜的分配证明了该中继与其他预期的中继进行了积极的比较。

“快速”-如果路由器处于活动状态，则为“快速”，并且其带宽处于已知活动路由器的前7/8，或者至少为100kb/s。

我在这个阶段相当困惑，未测量的阶段应该持续几天，并设定20kbps的带宽上限。然而，中继的路由速度超过20kbps，正常运行时间约为24小时。合理地说，我认为每个单独的连接都被限制在20kbps，但是成千上万的bwauths同时评估中继(如果我弄错了，请告诉我)。

2020年6月10日：未测量阶段于6月9日结束-删除了未测量的共识值就是明证。

当“带宽=”值不是基于该中继的3个或更多个测量的阈值时，“未测量=1”值被包括在用方法17或更高版本生成的共识中。

在远程测量阶段，与其他中继相比，中继开始逐渐收到更好的带宽估计。为了记录更好的带宽估计，中继参与了推送流量的ToR电路。通过中继的通信量随着估计带宽的增加而增加。因此，中间中继概率从0.0074%(6月9日)增加到0.0176%，通告带宽为4.86MiB/s。

我选择向中继添加IPv6支持，这将使中继更容易访问(特别是如果它要成为入口警卫的话)。要启用IPv6支持，将以下行添加到torrc：

要使更改生效，必须重新启动TOR服务。重新启动tor服务是删除虚假联系信息的好时机(这毫无意义，而且让我很恼火)。几个小时后，中继分配了ReachableIPv6标志，以确认已成功添加IPv6支持。

对于纵向流量观察，我安排vnstati使用systemd每周生成VPS流量摘要(注意：UnattenddedUpgrades执行时会出现峰值)。计划的脚本如下所示。

#！/bin/bash如果[[$(id-u)！=999]]；则echo"；NOT vnstati-sched，正在退出."；exit 1 fi script_name=$(basename--"；$0"；)output=$(date+%Y-%m-%d)mkdir$output CD$outputwnstati-d-i ens3-o"；${output}_daily.p.。vnstati-vs-i ens3-o"；${output}_Summary y.png"；

我曾想过要为tor设置一个单独的接口，以便提供更准确的带宽统计数据，但为了稍微改进一下，所需的努力让我望而却步。在撰写本文时，中继分别在5000个输入/输出连接上进行大约30 Mbps的中继。

“稳定”-如果路由器处于活动状态，并且其加权MTBF至少是已知活动路由器的中位数，或者其加权MTBF至少对应于7天，则该路由器是“稳定”的。如果路由器运行的ToR版本会愚蠢地丢弃电路，则路由器永远不会称为稳定路由器。(0.1.1.10-alpha到0.1.1.16-rc在这种情况下是愚蠢的。)。

稳定标志是使用第二个定义指定的，因为中继从6月6日至5日19：00才开始在线。中间中继概率增加到0.0443%，业务量也增加。中继处理的连接数量与6月10日相似(入站2368个，出站3033个)。可以通过以下命令查看是否有任何警卫中继正在使用IPv6。

root@vps-e0d4d314：~#ss-H6状态已建立"；(SPORT=：HTTP或SPORT=：HTTPS)"；|wc-l 6。

2020年6月13日：随着中间中继概率增加到0.0538，中继通告的带宽增加到12.12MiB/s(15.63MiB/s突发)。此外，中继器被分配了HSDir标志，该标志允许中继器成为洋葱服务的某种DNS服务器。

“HSDir”-如果路由器存储和提供v2隐藏服务描述符，具有稳定和快速标志，并且权威机构认为它至少已启动96小时(或MinUptimeHidServDirectoryV2的当前值)，则该路由器是v2隐藏服务目录。

此外，接力赛还被分配了卫兵旗帜。保护状态允许TOR客户端通过中继进入ToR网络，并用信号通知保护阶段的开始。

“防护”-如果满足以下所有条件，则路由器可能是防护：

它的加权部分正常运行时间至少是“熟悉的”活动路由器的中位数，

带宽至少为AuthDirGuardBWGuarante值(如果设置，默认为2MB)，或者带宽在最快的25%的中继中。

它符合V2Dir标志，如下所述(此约束是在0.3.3.x中添加的，因为在0.3.0.x中，客户端开始避免也没有V2Dir标志的保护)。

在守卫中继阶段：随着守卫概率的增加，中继的中间概率将下降，并且所有客户端都停止使用该中继作为中间中继。因此，在分配守卫旗帜后，8小时内中等概率下降到0.0437%，而守卫概率增加到0.0073%。但是，连接数量没有立即下降-我怀疑现有连接没有受到影响。预计在接下来的几周里，通过中继的通信量将会下降，直到下一次警卫轮换。此外，我预计IPv6连接的数量会增加，因为与TOR客户端相比，中继不太可能被限制性防火墙所征服。

然而，中继对透明网的暴露增加了，因为客户端将直接连接到中继本身，而不是通过代理中继。预计暴露的增加会增加针对中继的攻击数量-将我自己的隐私置于危险之中-所以我会定期检查ail2ban日志和tor日志中的恶意活动。应该注意的是，在最初的管理工作中，我将持久iptables规则设置为只允许22(Ssh)、80(Tor Dirport)和443(Tor Orport)。如果您自己操作中继，我强烈建议您花时间保护您的主机。

2020年6月14日：通告带宽增至12.13MiB/s，中概率降至0.0236%，防护概率升至0.0337%。自13日以来，与接力的连接数量没有明显变化。

距离接力首次上线已经9天了，vnstati在上周制作了一份交通摘要。当中继经过多个阶段时，本地数据和远程共识数据提供了检查流量行为和共识值的机会。首先，检查网络共识值，因为它们(相对于网络)是中继业务的因果关系。

最右边的图表，网络共识可视化，清楚地显示了每个中继阶段。在6月6日(未在最左边列出)到6月9日之间，流量非常少，在6月8日的某个时候，中继似乎开始了远程测量阶段。中继限制在<；700 Kib/s。

遥测阶段，中继率明显增加，6月14日达到最大值0.0538。此外，随着相对于通告的带宽测量和确认中继带宽，网络共识权重增加。在远程测量阶段，中等概率的增加多少是线性的，并且与读/写字节的突然增加成正相关。在远程测量阶段，继电器在4-5天的远程测量期内从659.2 KiB/s增加到5.877 MiB/s(增加了892%)。

在过去的24小时内，接力已经开始了守卫阶段。正如预期的那样，守卫概率在4小时内迅速增加到0.0334%，从0.0000%增加到0.0000%。守卫概率的增加与中等概率负相关。中继通信量没有明显变化。

从6月6日开始，此次接力共转移了3.9TB，但12日至14日期间，共转移了2.76TB。交通量的增加与中概率的快速增加不谋而合。看一看日线图，流量的增量增长是显而易见的。每小时交通测量显示交通高峰在11：00-15：00(协调世界时)，需要更长时间的分析才能建立交通时间表。

这就是跑接力赛的有趣部分。下一阶段将成为一支稳定的卫兵，但这将需要几个月的时间。在该时间段内，中间概率将下降，有利于保护概率，并且中继将接收更多直接连接。同时，出于我自己的好奇心，接力将继续收集信息，我希望这篇帖子很有趣。