基础知识

通常，遇到任何安全问题，我们都需要从威胁模型开始。我们关注两种主要的攻击模式：
服务器学习用户的 IP 地址并使用它来识别他们或关联他们的活动。
本地网络学习用户要访问哪些服务器。
服务器使用从你的 IP 地址确定的明显地理位置来限制对某些类型的内容（足球、BBC 等）的访问。
当然，是否认为第三项是一种应该防御的攻击形式取决于个人观点。
防御威胁 (1) 和 (3) 的基本技术是通过某种匿名中继推送流量：
/2022-12-01/relay-basic.png
如上图所示，客户端连接到中继并告诉它在哪里连接。然后它将流量发送到中继，中继将其转发到服务器。中继用自己的 IP 地址替换客户端的 IP 地址，因此服务器只看到中继的地址。通常，中继将服务于相当多的客户端，因此服务器会发现很难区分哪个是哪个（k-匿名）。这个简单的版本清楚地解决了威胁 (1)，如果中继运营商允许您选择自己地理区域之外的 IP 地址，则威胁 (3)。为了防御威胁 (2)，您还需要对中继的流量进行加密，这样您网络上的攻击者就无法看到您正在连接到哪个服务器以及您发送给它的流量（有关更多信息，请参见此处这种形式的数据泄露）。理想情况下，您还可以对服务器端对端的流量进行加密（使用 TLS 或 QUIC），但这只是一般的好习惯，中继提供的隐私不需要。

中继选项

这种基本设计是每个中继系统的核心，但细节在重要方面有所不同。有三个主要的变化轴：

发生中继的网络层
网络中的跳数
商业模式

下面进行详细介绍：

网络层

第一个主要的变化点是发生中继的层。理解这一点需要一些关于 Internet 网络协议如何工作的背景知识。

IP

Internet 上最基本的协议就是所谓的 Internet 协议 (IP)。 IP是所谓的“分组交换”协议，这意味着基本单元是称为分组的自包含消息。一个数据包就像一个字母，它有一个源地址和一个目的地址。这意味着，在网络上发送 IP 数据包时，Internet 可以通过查看数据包自动将数据包路由到目标地址，而没有关于任何一台计算机的其他状态。简化的 IP 数据包如下所示：
/2022-12-01/IP-packet.png
数据包中的主要内容是从源传送到目的地的实际数据，也称为有效载荷。有效载荷是可变长度的，最大通常约为 1500 字节。数据包还有一个下一个协议字段，它告诉接收器如何解释有效负载（稍后会详细介绍）和一个长度字段，以便可以判断整个数据包有多长，包括可变长度的有效负载。
使用 IP 非常简单：您的计算机通过网络传输一个 IP 数据包，而 Internet 使用目标地址来确定将其路由到哪里。当有人想向您传输信息时，他们会做同样的事情。

TCP

如果您只想从一台机器向另一台机器发送一千左右字节，单个 IP 数据包可能没问题，但实际上这几乎不是您想要做的。特别是，想要发送比 1500 字节长得多的数据流（例如文件）是很常见的。在高层次上，这是通过将数据分解成一系列较小的块并在单个数据包中发送每个块来完成的。但当然，生活并非如此简单。例如：数据包可能会丢失，并且必须重新传输，以便接收者得到它们。
数据包可能会重新排序，接收方必须知道将它们放入的顺序。
一般来说，网络无法一次处理整个大文件，因此数据必须随着时间的推移逐渐（人群）传输。发送者必须有某种方法来确定适当的发送速率。
传输控制协议 (TCP) 负责处理这些问题。 TCP 的详细信息太复杂了，无法在这篇博文中介绍，但在高层次上，数据流被分解成段，每个段都有一个长度和一个序列号，它告诉你它在流中的位置.每个段都在一个 IP 数据包中发送。当接收器获得一个段时，它可以查看序列号以重建流，并能够检测数据包丢失的间隙。 TCP 还包括一个确认机制，在该机制中，接收者告诉发送者它收到了哪些段；这允许发送方重新传输丢失的数据包，并适当调整其发送速率。 [2] TCP 需要在两个端点之间建立状态；这种状态称为“TCP 连接”。
当然，除了 TCP 之外，还有其他协议可以在 IP 上运行（例如 UDP，后面会提到）。这就是为什么您需要 IP 中的“下一个协议”字段：告诉接收者 IP 有效负载中的协议是什么。

TLS

TCP 是一种非常古老的协议，与大多数较旧的 Internet 协议一样，它是在广泛使用加密之前设计的。从安全的角度来看，这显然是个坏消息，最终人们开始着手修复它。标准解决方案是通过传输层安全性 (TLS) 传输数据。 TLS 基本上在 TCP 连接之上提供了加密和经过身份验证的数据流的抽象。与 TCP 一样，您需要设置一些状态才能使用 TLS，这称为“TLS 连接”。我可以无休止地谈论 TLS，但我不会在这里这样做。

UDP和QUIC

应用程序本身不实现 TCP。相反，它内置在操作系统中，特别是在所谓的操作系统内核中，即始终运行并负责管理整个计算机的操作系统部分。客户端应用程序告诉操作系统创建到服务器的 TCP 连接，这会在客户端创建所谓的“套接字”。客户端将数据写入套接字，内核自动将其打包成 TCP 段并将其传输到另一端，负责重传、速率控制等。内核还从另一端读取 TCP 段并使其可用于要阅读的应用程序。通常，应用程序自己实现 TLS，或者更有可能使用一些现有的 TLS 库。

为什么不能编写自己的 TCP 堆栈？

显然，您可以编写自己的 TCP 堆栈（毕竟它只是软件），但问题是您无法安装它，因为在大多数操作系统上，普通应用程序不允许写入或接收原始 IP 数据报。这是在前加密时代曾经用于安全实施的对网络行为的众多限制之一。例如，曾经假设如果一个数据包来自一个给定的机器地址和一个给定的“端口号”（UDP/TCP 报头中的一个字段），它来自一个特权进程（一个拥有操作系统特权的进程） . 甚至还有一个基于此的远程登录系统，您可以在机器 A 上执行命令，无需验证即可在机器 B 上执行命令。我知道现在这听起来很荒谬，但这是从 80 年代初到 90 年代后期的情况，当时我们终于获得了正确的加密身份验证。
这很方便，因为应用程序不需要携带自己的 TCP 实现，但不方便的是它不灵活：假设应用程序想要对 TCP 进行一些更改以使其更高效？如果不更改操作系统，就无法做到这一点。相比之下，只需发布新版本的应用程序就可以轻松更改 TLS 行为。这在 2010 年代后期变得尤为突出，当时人们想要对 TCP 进行性能增强，但由于操作系统的运行速度不够快而无法做到。解决方案是发明一种可以完全在应用程序中实现的新协议：QUIC。
QUIC 有点像更高级的 TCP 版本和 TLS 加密的组合（事实上，它在内部使用了许多 TLS）。但是，由于它可以完全在应用程序中实现，因此可以非常迅速地进行更改。不幸的是，在大多数操作系统中，不允许应用程序直接写入 IP 数据包，因此 QUIC 运行在称为用户数据报协议 (UDP) 的协议上。 UDP 是一个非常简单的协议，它只允许应用程序通过 IP 发送单个数据单元（数据报）。因此，QUIC 在 UDP 上运行，而 UDP 在 IP 上运行。

协议栈

通常将其称为协议“堆栈”并在称为“层图”的图片中将其可视化，如下所示：
/2022-12-01/TCPIP-layer.png
我还在此图中绘制了哪些部分在应用程序中实现，哪些部分通常是操作系统的一部分。当应用程序想要写入数据时，它从堆栈顶部开始，数据向下移动到网络。当数据来自网络时，它会在堆栈中向上移动到应用程序。
就数据在网络上出现的方式而言，每一层都添加了自己的封装，通常在数据之前或之后。下图显示了两个示例。第一个是通过 TCP 发送的数据，在本例中是字符串“四分七年前”。 TCP 在自己的头中加上序号等，然后将其传递给 IP 层，IP 层在 IP 头中加上源地址和目的地址。第二个示例是通过 TLS 发送的相同数据。 TLS 层加密数据（由交叉影线显示）并添加自己的标头。然后它将它传递给 TCP，TCP 添加自己的标头等。接收过程反转这些操作。
/2022-12-01/tcp-tls-packets.png

命名数据块

您可能会注意到我一直在使用术语“数据包”、“记录”等。这些是不可互换的。网络中最烦人的问题之一是如何命名单个数据单元，如数据包（有时通常称为协议数据单元 (PDU)）。每个协议都有自己的术语，部分原因是由不同的人定义，部分原因是当您在协议栈的多个层工作时，谈论“IP 数据报”、“UDP 数据报”、等等。
以下是不同协议中 PDU 的名称表：

协议	名称
以太网	框架
IP	数据包（数据报）
UDP	数据报
TCP	段
TLS	记录
QUIC	数据包（包含”帧“的定义）
HTTP	信息
RTP	数据包（携带媒体帧）
OpenPGP	数据包
XMPP	节

重要的是要知道 TCP 和 TLS 提供数据流的抽象，而不是一组记录。这意味着应用程序只写入数据，TLS 堆栈或 TCP 堆栈将这些块合并为一个记录（数据包）或在方便时将它们分解。 TCP 堆栈甚至可能使用两个不同的帧两次发送相同的数据。例如，假设应用程序写了“Hello”，然后内核在一个数据包中发送它。当数据包在飞行中时，应用程序会写入“Again”。如果两个数据包都丢失了，并且内核必须重新传输它们，它可能会将它们写为单个 TCP 段（“HelloAgain”）。
在哪一层中继流量
以此为背景，我们准备讨论多样性的一大要点：我们在哪一层中继流量？有两个主要选项，至少用于中继加密流量。
中继IP层流量
中继应用层流量（即通过 UDP 或 TCP 传输的数据）
中继 IP 流量
以此为背景，我们准备讨论多样性的一大要点：我们在哪一层中继流量？有两个主要选项，至少用于中继加密流量。
在网络层 (IP) 加密流量是解决网络安全问题的明显方法之一，因为它具有重要的优势，即一旦设置它，它就会保护两个端点之间的所有通信。这方面的工作可以追溯到 1970 年代，但 IETF 于 1992 年开始以 IPsec 的名义为此目的对技术进行标准化。最初的想法实际上并不是我上面讨论的那种中继系统，而是您将加密相互通信的两台机器之间的流量。因此，例如，假设我的客户想要与您的服务器通信，我们将获取我们想要发送的 IP 数据包，对其进行加密，然后直接发送。
与我们上面讨论的协议一样，IPsec 是一种封装协议，这意味着要对从 A 到 B 的 IP 数据包进行加密，我们将整个原始数据包加密，然后将其填充到另一个 IP 数据包中，如下所示：
/2022-12-01/ipsec1.png
在我上面讨论的场景中，内部（加密的）IP 报头和外部（明文）IP 报头将具有相同的寻址信息，但当然可以让它们具有不同的寻址信息，这对于创建所谓的内容很有用虚拟专用网络 (VPN)。这里的激励想法是您有两个网络（比如来自同一家公司的两个办公室）并且您希望将它们连接起来，就好像它们在同一位置一样。在办公室里，你相信电线没有被篡改（这是在 WiFi 之前），所以你不会加密所有数据（我知道，这现在听起来很天真），所以你真正想要的只是一个连接办公室 1 和办公室 2 的电线。这种专用连接——以前称为“租用线路”——购买起来非常昂贵，而你实际拥有的是一个 Internet 连接，可以让你连接到每个人。但是，如果您对办公室 1 和办公室 2 之间的流量进行加密，那么您就可以模拟拥有自己的专用线路。因此虚拟专用网络。典型的拓扑结构如下所示：
/2022-12-01/enterprise-vpn.png
在这种情况下，您有两个办公室，每个办公室都有一个“VPN 网关”，它检测从办公室 1 到办公室 2 的流量并在发送之前对其进行加密。其他流量，比如 Facebook，保持不变。当数据包在远端 VPN 网关收到时，它只是删除封装并将它们丢弃在网络上。效果就好像只有一个网络而不是两个网络。
也可以在更简单的场景中部署这种东西，其中单个用户 VPN 进入他们的办公室网络，例如，如果您在酒店远程工作，如下图所示：
/2022-12-01/remote-access-vpn.png
这里的效果是你好像在办公室，但实际上你不在。但这带来了一个真正的问题，即远程用户的机器没有正确的 IP 地址：它有一个与用户的家庭或办公室相关联的 IP 地址（上图中的 192.0.2.1），但您希望它似乎在办公室，这意味着它必须有一个办公室 IP 地址（以 203.0.112 开头的地址）。
有两种主要的（主要）方法来完成这项工作。首先，VPN 网关告诉用户的设备它想要它拥有什么 IP 地址，然后用户的设备将其放入内部 IP 标头，同时让外部 IP 标头具有实际地址。例如，内部（加密的）IP 报头为 203.0.11.50，外部（明文）IP 报头为 192.0.2.1。另一种方法是让两个标头都具有用户的实际 IP 地址，并让 VPN 网关将该地址转换为办公室网络的适当本地地址（并在返回时以其他方式转换）。请注意，在这两种情况下，网关都需要做一些工作，在第一种情况下跟踪分配了哪些地址并强制客户端使用正确的地址，在第二种情况下进行转换。
有了这样的背景，我们终于可以得出我们开始的问题陈述，即隐藏用户行为。不出所料，您可以使用与远程访问相同的技术，不同之处在于 VPN 网关直接在 Internet 上，而不是在某些企业网络上，如下所示：
/2022-12-01/consumer-vpn.png
对于服务器来说，这看起来就像用户正在从 VPN 网关连接，无论 VPN 网关的 IP 地址是什么。客户端的本地网络只看到与 VPN 服务器的连接，但不知道数据最终去往何处。
在这里，我重点介绍了 IPsec，但使用哪种加密层协议来传输 IP 数据包并不重要：它们只是被封装和端到端传输。在实践中，人们看到 VPN 部署了多种传输协议，包括 DTLS、OpenVPN、WireGuard 和 QUIC。从用户的角度来看，这些协议的属性大体相同。大多数标有“VPN”的产品使用这些协议中的一种或多种来保护 IP 层的流量。
中继应用层流量
如上所述，在 IP 层保护流量的好处在于它保护了系统上的所有流量。然而，坏处是保护IP层流量需要操作系统的配合。这有几个不良后果：
你的代码不可在操作系统之间移植。
许多操作系统需要某种管理员访问权限才能安装或配置在 IP 层运行的东西。
你通常受限于操作系统为您提供的任何功能。例如，可能无法轻易保护某些流量而不保护其他类型的流量。
这些问题可以通过在应用层而不是 IP 层进行中继来解决。这可以完全在应用程序中实现，而无需触及操作系统；应用程序只是连接到中继（例如，通过 TCP）并将流量发送到中继（希望加密到服务器）。中继与服务器建立自己的传输层连接，并将应用层流量发送到服务器，如下所示。
/2022-12-01/application-relay.png
请注意，在此图中有两个 TCP 连接，一个在客户端和中继之间，一个在中继和服务器之间。客户端通过 TLS 连接到中继，然后在其之上创建到服务器的端到端 TLS 连接（当然你可以不加密你的数据到服务器，但不要那样做）。
这种设计的一大优势是它可以很容易地中继某些类型的流量而不是其他类型的流量。作为一个具体示例，请考虑安全浏览，它将有关用户浏览历史记录的信息泄露给安全浏览服务器。您可能想要代理安全浏览检查（这可以非常便宜地完成，因为没有太多流量）而不是一般浏览流量（它的数量要大得多，因此更昂贵）。这对浏览器来说很容易做到，因为它知道哪些流量是哪个，但对于 IP 层系统来说就更难了，它必须以某种方式区分不同类型的流量。这不一定是不可能的，但它的工作量要大得多。例如，如果安全浏览使用与 Google 其他部分不同的 IP 地址，那么您可以中继该流量，但如果它共享相同的 IP 地址，那么您也会对人们的搜索流量进行加密。
许多IP隐藏系统在应用层进行中继，包括Tor、Apple的iCloud Private Relay和Firefox Private Network。通常，像这样的系统被称为“代理”。 Apple 的系统很有趣，因为它主要通过连接 Apple 的更高级别的网络 API 在操作系统中实现。即便如此，它只适用于 Safari，不适用于其他应用程序。

多少跳？

无论采用何种中继技术，最终中继都需要将流量发送到服务器，这意味着它必须知道您要连接到哪个服务器。但这会产生一个新的隐私问题：您连接到中继，然后告诉它要连接到哪个服务器。这意味着虽然您已阻止服务器了解您的身份，但您仍然存在与中继本身有关的隐私问题。中继将有一些关于它如何处理这些信息的隐私政策（理想情况下，根本不保留日志），但这只是你必须信任他们的东西。更好的办法是拥有某种形式的技术保护。
这里提供技术保护的标准方法是有多层中继，如下图所示：
/2022-12-01/multi-hop-relay.png
它的工作方式是客户端连接到中继 1。然后它告诉中继 1 将其连接到中继 2。与我们的单跳系统一样，该数据通过加密通道发送到中继 1，并且本身加密到中继 2. 客户端然后通知中继 2 将其连接到服务器。因此，发送到服务器的数据由客户端以嵌套方式加密三次：一次发送到服务器，然后发送到中继 2，然后发送到中继 1。每个跃点都会剥离一层加密并将其传递到下一跃点。
结果是没有任何一个实体（客户端除外）可以同时看到用户的身份和它所连接的服务器的身份。这是每个人看到的：

实体	知识
中继1	客户端地址，中继2地址
中继2	中继 1 地址，服务器地址
服务器	中继 2 地址，服务器地址

请注意，如果两个中继勾结，它们可以一起发现客户端地址和服务器地址。然而，如果任何一个是诚实的，那么客户端的隐私应该受到保护，因为它们都不能轻易地与服务器串通来获悉此信息：中继 2 因为它不知道客户端的地址而中继 1 因为（希望）客户端连接到中继2 是它在此期间与中继 2 建立的众多连接之一。最后一部分的效果如何取决于系统的运行规模、客户端离开连接多长时间、它是否重用连接到中继 2 以连接到多个服务器等。
当然，为了让它发挥作用，中继需要由不同的实体来操作。否则就无法保证不串通。这包括不在同一云服务提供商（例如 AWS）上运行。有时您会听说多跳 VPN，但如果同一家公司提供两个 VPN 服务器，那么这并没有多大帮助。 iCloud Private Relay 的一个不错的功能是您的帐户是在 Apple 上的，但他们会安排与不同提供商的多个跃点，因此您无需担心细节。
多跳的一个重要限制是它会对性能产生负面影响。通常，运行 Internet 的路由算法会尝试在两个位置之间找到合理有效的路由，因此您应该期望，如果不是在点 A 和点 B 之间路由，而是从 A 路由到 C 再到 B，那么这会稍微慢一些（你会经常听到人们使用术语三角不等式作为它的简写）。您执行的跃点越多，对性能产生某种影响的可能性就越大。这不是一个精确的效果，但总的来说，您应该会产生一些影响。
iCloud Private Relay 是一个双跳网络，第一跳由 Apple 运营，第二跳是 Apple 签约的大型提供商（主要是 Cloudflare 或 Akamai 等内容交付网络 (CDN)）。 Apple 和这些 CDN 都具有快速连接和良好的地理分布，旨在确保高性能。 Tor 使用三跳，一个“保护节点”，一个“中间中继”和一个“出口节点”。如下所述，Tor 中继实际上是志愿服务，因此性能在实践中各不相同。

商业模式

典型的 VPN 有一个简单的商业模式：您向 VPN 提供商付费，然后在连接时向他们进行身份验证（例如，使用密码）。这不利于保护隐私，因为他们知道您的姓名、联系信息和信用卡号码。另一方面，如上所述，他们已经知道您的 IP 地址以及您要去的站点，因此不清楚这会使事情变得更糟。
但是，对于专用中继，这会产生一个真正的问题：第一跳中继并没有那么糟糕，因为它无论如何都会获取您的 IP 地址，但是如果您使用您的身份向第二个中继进行身份验证，那么您就毁了一切，并且您还不如回到单跳系统。为了解决这个问题，Apple 使用通过盲签名生成的匿名凭证来向代理进行身份验证，如下所示：
/2022-12-01/anonymous-proxy.png
简而言之，它的工作方式是客户端连接到 Apple 并使用其 iCloud 帐户对其进行身份验证。然后，Apple 会颁发一个不包含用户身份的匿名凭证。可以将此凭证提供给中继以授权使用该服务。为了防止 Apple 将这两个活动联系起来，当 Apple 生成凭证时，凭证会被屏蔽（本质上是加密的），然后客户端在将其发送到中继之前将其解除屏蔽（有关此类凭证如何工作的更多详细信息，请参见此处） .这种设计允许代理知道您有权使用该服务，但不知道您是谁。
Tor 不同于其中任何一个，因为它是一项免费服务，由社区成员运营（您可以向运行中继的人捐款）。这会产生一些不可预测的性能后果，因为服务水平协议 (SLA) 的方式确实不多。这也使得评估实际的隐私保证有些困难，因为某些 Tor 节点可能由您不信任的人或恶意的人运行。显然，使用 iCloud Private Relay，你必须自己判断你对 Apple 及其合作伙伴的信任程度，但至少你对他们是谁有一些了解。

最后的想法和总结

IP 地址是一个重要且高效的跟踪向量，如果您想私下浏览，您需要做一些事情来隐藏您的 IP，这主要意味着中继。只要您的提供商不与服务器勾结，任何中继系统都会向服务器隐藏您的身份。任何一跳系统都必然意味着您信任提供商不会跟踪您的行为并且不会与服务器串通。根据您对本地网络及其隐私政策的看法，单跳系统可能是也可能不是改进。多跳系统具有更好的隐私故事，因为单个中继的不当行为不足以损害您的隐私。
系统工作方式的技术细节（IP 与应用层，主要是）对隐私来说并不重要，但对功能很重要，应用层系统更灵活，但对您设备上的其他应用程序的覆盖范围较小。此外，我所知道的所有多跳系统都在应用层，所以如果你想要一个多跳系统，你可能会使用应用层系统。
最后，重要的是要知道，即使是最好的系统也只能提供有限的保护。拥有完整网络视图的攻击者通常可以进行足够的流量分析以确定流量的每一端都有谁。幸运的是，我们大多数人不需要担心这个强大的攻击者。

原文作者:Eric Rescorla
原文标题：How to hide your IP address:A field guide to VPNs, proxies, and traffic relaying
原文地址：https://educatedguesswork.org/posts/traffic-relaying/

如何隐藏 IP 地址