三思屋

博文

目前显示的是标签为“技术”的博文

Win11家庭版无需重装，通过更换Key升级到专业版(Windows 11)

发布于五月 07, 2025

Win11(Windows 11)家庭版可以通过更换密钥(Key)的方式无缝升级到Win11专业版操作方法如下：先断网输入产品密钥(Key)，更新时自动重启电脑。 W269N-WFGWX-YVC9B-4J6C9-T83GX 重启电脑后显示已经更新到Win11专业版，待激活状态。改用其他正规途径获得的密钥或KMS激活方式激活系统即可。参考资料： https://learn.microsoft.com/zh-cn/windows-server/get-started/kms-client-activation-keys https://support.microsoft.com/zh-cn/windo…

阅读全文

常用的国内外延迟测速链接（generate_204）

发布于五月 07, 2025

以下是一些常用的国内外延迟测速链接，通常返回204状态码（generate_204）服务提供者链接大陆体验境外体验 Google http://www.gstatic.com/generate_204 5 10 Google http://www.google-analytics.com/generate_204 6 4 Google http://www.google.com/generate_204 0 10 Google http://connectivitycheck.gstatic.com/generate_204 4 10 Apple http://captive.apple.com 3 10 Apple http://w…

阅读全文

Serv00进入伪root模式的方法

发布于十二月 12, 2024

Serv00默认提供的是用户级的权限，无法使用系统级的操作，例如pkg install安装应用。而这里提供一种进入伪root模式的方法，其原理是内建一个虚拟的环境，在该环境中以root身份运行 git clone https://github.com/nrootconauto/MrChrootBSD.git cd MrChrootBSD wget https://download.freebsd.org/releases/amd64/14.1-RELEASE/base.txz wget https://download.freebsd.org/releases/amd64/14.1-RELEA…

阅读全文

如何快速手工测试VPS上行和下行速度

发布于十一月 26, 2024

通常对于一台Linux服务器有各种测试脚本用于测试其性能，参数，网络，但是对于服务器到本地的上行和下行速度，最简单的还是通过上传下载来测试。测试服务器下行速度这里通过下载100M大小的测试文件来测试服务器的下行速度 wget -O /tmp/100m.test "https://speed.cloudflare.com/__down?during=download&bytes=100000000" 测试服务器上行速度这里通过设置nginx配置，然后在浏览器中直接下载刚刚测速的100M测试文件，来测试服务器的上行速度修改Nginx配置，在合适的位置添加： location…

阅读全文

解决Ubuntu桌面上Free Download Manager无法打开的问题

发布于十一月 01, 2024

在 Ubuntu Desktop 24.04 LTS 上安装 Free Download Manager 后，点击其图标时程序无法打开。这个问题通常与 Ubuntu 系统更新后的兼容性有关。新的 Ubuntu 更新可能会影响 Free Download Manager 的某些安全功能，例如 SSL 和 TLS。解决方法是安装 `libxcb-cursor0`。请在终端中运行以下命令： sudo apt install libxcb-cursor0

阅读全文

使用 Nginx 状态码 444 提升 HTTPS 服务安全性，屏蔽 HTTP 497 访问提示

发布于十月 31, 2024

网络安全至关重要，特别是在提供 HTTPS 服务时。本文介绍如何使用 Nginx 的状态码 444 来防止未授权访问和潜在安全问题。&nbsp;<img src="https://nginx.org/img/nginx_logo.png" />444 是 Nginx 特有的状态码，用于强制关闭客户端连接，不返回任何响应，有效拒绝了不合法请求，避免信息泄露。在提供 HTTPS 私密服务时，非法用户可能尝试探测端口，这不仅浪费资源，还可能带来安全风险。通过 Nginx 配置状态码 444，可以隐藏服务存在，保护隐私。 &nbsp; 下面是使用状态码 444 保护 HTTPS 服务的基本 Nginx 配置： server { &nbsp;&nbsp;&nbsp; listen 443 ssl default_server; &nbsp;&nbsp;&nbsp; server_name _; &nbsp; &nbsp;&nbsp;&nbsp; ssl_certificate /path/to/your/certificate.crt; &nbsp;&nbsp;&nbsp; ssl_certificate_key /path/to/your/private.key; &nbsp; &nbsp;&nbsp;&nbsp; location / { &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; return 444; &nbsp;&nbsp;&nbsp; } &nbsp; &nbsp;&nbsp;&nbsp; error_page 497 = @close; &nbsp;&nbsp;&nbsp; location @close { &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; return 444; &nbsp;&nbsp;&nbsp; } } 其中 <ul style="text-align: left;"><li>listen 443 ssl;：监听 443 端口，启用 SSL。 </li><li>location / { return 444; }：根路径请求直接返回 444，拒绝访问。 </li><li>error_page 497 = @close;：HTTP 访问 HTTPS 端口时重定向到 @close。 </li><li>location @close { return 444; }：497 错误时返回 444，关闭连接。 </li></ul>使用 Nginx 状态码 444 是保护 HTTPS 服务的方法，有以下好处： &nbsp; 1. 隐蔽性：状态码 444 使非法用户无法探测服务，减少自动扫描和攻击风险。 2. 资源节约：拒绝不必要请求，避免性能下降。 3. 安全性提升：限制访问，只允许授权用户连接，降低安全威胁。 &nbsp; 这种方法可以隐藏服务存在，节省资源，增强安全性。

网络安全至关重要，特别是在提供 HTTPS 服务时。本文介绍如何使用 Nginx 的状态码 444 来防止未授权访问和潜在安全问题。 444 是 Nginx 特有的状态码，用于强制关闭客户端连接，不返回任何响应，有效拒绝了不合法请求，避免信息泄露。在提供 HTTPS 私密服务时，非法用户可能尝试探测端口，这不仅浪费资源，还可能带来安全风险。通过 Nginx 配置状态码 444，可以隐藏服务存在，保护隐私。下面是使用状态码 444 保护 HTTPS 服务的基本 Nginx 配置： server { listen 443 ssl default_server; server_n…

阅读全文

Fake Login - 在Linux(Debian)中显示虚假的Windows登录屏幕

发布于十月 30, 2024

为了抵御潜在的黑客入侵和未授权访问，我们可以通过在黑客或未授权用户面前展示一个伪装的Windows登录界面，不仅能够迷惑他们，还能减少系统被监控的风险。这种策略为保护敏感信息和预防潜在攻击提供了一种有效的防护手段。<img src="https://pentestlab.blog/wp-content/uploads/2020/02/input-prompt-fakelogonscreen-windows.png" />本文将指导您如何利用一个简易脚本`fake_login.sh`来创建一个伪装的Windows登录界面，以此降低系统被黑客监控的风险。 <h2 style="text-align: left;">伪装登录（Fake Login）简介</h2>伪装登录是一种通过展示图像来欺骗用户或潜在攻击者的技术，使他们误以为自己正在面对Windows的登录界面。这种方法不仅能够提高系统的安全性，还能有效保护敏感数据不被轻易获取。 <h3 style="text-align: left;">准备</h3>在开始之前，请确保您的系统中已经安装了`fbi`（framebuffer image viewer），这是一个在Linux framebuffer上显示图像的工具。您可以通过以下命令来安装它： <div style="margin-left: 40px; text-align: left;">sudo apt-get install fbi </div><h3 style="text-align: left;">脚本编写</h3>下面，我们将编写一个名为`fake_login.sh`的脚本，用于展示伪装的Windows登录界面图像。 <div style="margin-left: 40px; text-align: left;">#!/bin/bash</div><div style="margin-left: 40px; text-align: left;">if pgrep -x "fbi" &gt; /dev/null; then &nbsp;&nbsp;&nbsp; echo "fbi is already running. Exiting." &nbsp;&nbsp;&nbsp; exit 1 fi fbi -a -noverbose -T 1 input-prompt-fakelogonscreen-windows.png </div><ul style="text-align: left;"><li>-a：自动调整图像以适应屏幕大小。</li><li>-noverbose：关闭冗余输出。</li><li>-T 1：指定要使用的虚拟终端，通常是1。</li></ul> 请确保将input-prompt-fakelogonscreen-windows.png替换为您准备的伪装图像的实际路径。 <h3 style="text-align: left;">设置为开机自启</h3>为了使脚本在系统启动时自动运行，您可以将其添加到启动项中。一种常见的做法是将脚本放置在/etc/init.d/目录下，并设置为开机启动。 1. 将脚本复制到/etc/init.d/目录：sudo cp fake_login.sh /etc/init.d/ 2. 为脚本添加执行权限： sudo chmod +x /etc/init.d/fake_login.sh 3. 使用`update-rc.d`命令将脚本添加到启动项：sudo update-rc.d fake_login.sh defaults <h3 style="text-align: left;">手动运行</h3>在首次设置后，您可能需要手动运行一次脚本以验证设置是否正确。之后，每次系统启动时，伪装的登录界面将自动显示。

为了抵御潜在的黑客入侵和未授权访问，我们可以通过在黑客或未授权用户面前展示一个伪装的Windows登录界面，不仅能够迷惑他们，还能减少系统被监控的风险。这种策略为保护敏感信息和预防潜在攻击提供了一种有效的防护手段。本文将指导您如何利用一个简易脚本`fake_login.sh`来创建一个伪装的Windows登录界面，以此降低系统被黑客监控的风险。伪装登录（Fake Login）简介伪装登录是一种通过展示图像来欺骗用户或潜在攻击者的技术，使他们误以为自己正在面对Windows的登录界面。这种方法不仅能够提高系统的安全性，还能有效保护敏感数据不被轻易获取。准备在开始之前，请确保您的系统中已经安装了…

阅读全文

Debian 12上使用Nginx代理TCP流量，并配置IPv6白名单访问控制

发布于四月 19, 2024

在部署基于 TCP 的应用程序（如数据库服务）时，安全性和访问控制是常见的需求之一。有时候只希望特定白名单的IPv6地址访问特定的端口。使用 Nginx 作为 TCP 代理，可以实现高效灵活的流量管理。本文记录了如何在 Debian 12 上使用 Nginx 来实现 TCP 流量代理和 IPv6 白名单控制。准备环境系统: Debian 12。 Nginx 版本: 确保安装的 Nginx 版本支持 stream 模块。使用 nginx -V 检查是否包含 --with-stream=dynamic。权限: 访问和编辑配置文件通常需要 root 权限。安装 Nginx 和 Stream 模块如…

阅读全文

使用AdGuard的公共dns屏蔽广告

发布于四月 04, 2024

AdGuard是一系列用于网页浏览器及跨平台内容过滤的广告拦截和隐私保护软件、开放源代码和共享软件的浏览器扩展程序产品，AdGuard允许用户使用阻止广告等页面元素的显示，借此保护用户免受不必要的广告、弹出窗口、视频、文字、横幅、跟踪、淫秽内容、恶意网站及软件和网络钓鱼的危害。而除了安装并使用AdGuard软件以外，最快捷的方式就是使用它的公共DNS服务。在操作系统的dns设置中，可以设置以下公共DNS，实现屏蔽广告： 94.140.14.14 94.140.15.15 ipv6用户可以同时设置： 2a10:50c0::ad1:ff 2a10:50c0::ad2:ff 也可以在浏览器的设置中，使用DN…

阅读全文

利用cgroup对docker进行全局资源限制(CPU, 内存, IO读写等限制)

发布于三月 19, 2024

我们购买的VPS一般资源属于共享的，商家往往会在TOS说明，禁止长期占用资源，超过百分之多少会进行停机处理等。而我们运行服务时，可以先自行对资源进行合理限制，防止程序异常占用资源导致被商家停机。<div> </div><div><img src="https://img.123455.xyz/s1/2024/03/6a67689760689694639a656669696368916b946593.jpg" /><div> </div><div>使用docker部署服务时，通常可以在docker run后面加上--cpus等参数对单个服务进行资源限制，而随着服务部署的越来越多，每个服务的限制往往略显麻烦。</div><div> </div><div>这时候可以考虑使用全局资源限制，即针对所有docker服务，限制总体的资源占用。具体操作如下：</div><div> </div><div>编写systemd配置：</div><div> </div><blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;"><div><div>cat &lt;&lt; EOF &gt; /etc/systemd/system/limit-docker.slice</div></div><div><div>[Unit]</div></div><div><div>Description=Slice with IOBandwidthLimit and CPUQuota for docker</div></div><div><div>Before=slices.target</div></div><div><div> </div></div><div><div>[Slice]</div></div><div><div>CPUQuota=300%</div></div><div><div>MemoryMax=4G</div></div><div><div>IOReadBandwidthMax=/dev/vda3 1000M</div></div><div><div>IOWriteBandwidthMax=/dev/vda3 500M</div></div><div><div>EOF</div></div></blockquote><div> </div><div>值得注意的是，上面的配置需要根据实际情况修改（不可直接复制粘贴使用）</div><div><ul style="text-align: left;"><li>配置中的CPUQUota=300%，表示使用3个核心的CPU。</li><li>MemoryMax=4G，表示最大限制使用4G内存，超出会中止服务。</li><li>IOReadBandwidthMax和IOWriteBandwidthMax分别表示限制磁盘读和写的速度为1G/s和500M/s，针对的磁盘设置为/dev/vda3</li></ul></div><div>编辑docker配置文件 /etc/docker/daemon.json ，加入上面的配置：</div><div> </div><blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;"><div><div>{</div></div><div><div>&nbsp; &nbsp; "cgroup-parent": "limit-docker.slice"</div></div><div><div>}</div></div></blockquote><div> </div><div>使配置生效：</div><div> </div><blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;"><div><div>systemctl daemon-reload</div></div><div><div>systemctl restart docker</div></div></blockquote><div> </div><div> </div></div>

我们购买的VPS一般资源属于共享的，商家往往会在TOS说明，禁止长期占用资源，超过百分之多少会进行停机处理等。而我们运行服务时，可以先自行对资源进行合理限制，防止程序异常占用资源导致被商家停机。使用docker部署服务时，通常可以在docker run后面加上--cpus等参数对单个服务进行资源限制，而随着服务部署的越来越多，每个服务的限制往往略显麻烦。这时候可以考虑使用全局资源限制，即针对所有docker服务，限制总体的资源占用。具体操作如下：编写systemd配置： cat << EOF > /etc/systemd/system/limit-docker.slice [U…

阅读全文

Linux下加密虚拟分区并挂载文件夹使用

发布于一月 30, 2024

在linux下，为了保护磁盘上的数据安全，可以使用cryptsetup工具对磁盘进行加密。这里演示了如何创建一个加密分区文件enc，同时挂载到指定文件夹下使用的步骤。<img src="https://www.micronicsindia.com/wp-content/uploads/2022/10/Screenshot_1.jpg" /><h2 style="text-align: left;">初始化</h2><div>首选系统需要安装 cryptsetup 工具，然后按下面的步骤初始化加密的虚拟分区文件，并进行首次挂载</div><blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;">fallocate -l 10G enccryptsetup -c aes-xts-plain64 -s 512 -h sha512 -i 5000 luksFormat enccryptsetup open enc myencmkfs.ext4 /dev/mapper/myencmount /dev/mapper/myenc /home</blockquote> <h2 style="text-align: left;">卸载</h2><div>结束使用后先卸载目录映射，然后关闭加密。</div><blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;">umount /homecryptsetup close myenc</blockquote> <h2 style="text-align: left;">重新挂载</h2><div>下次需要使用时，先解开加密，然后挂载。</div><blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;">cryptsetup open enc myencmount /dev/mapper/myenc /home</blockquote>&nbsp;<h2 style="text-align: left;">设置开机自动挂载</h2><div>为了设置开机自动挂载，需要先生成一个密钥文件</div><div> </div><blockquote style="border: none; margin: 0 0 0 40px; padding: 0px;"><div style="text-align: left;">dd if=/dev/urandom of=/root/encpass bs=512 count=4 &amp;&amp; chmod 400 /root/encpass</div></blockquote><div> </div><div>接着将这个密钥文件加入已经存在的加密分区中</div><div> </div><blockquote style="border: none; margin: 0 0 0 40px; padding: 0px;"><div style="text-align: left;">cryptsetup luksAddKey enc /root/encpass</div></blockquote><div> </div><div>完成后，编辑/etc/fstab，加入</div><div> </div><blockquote style="border: none; margin: 0 0 0 40px; padding: 0px;"><div style="text-align: left;">/dev/mapper/myenc /home ext4 defaults 0 0</div></blockquote><div> </div><div>接着编辑/etc/crypttab，加入</div><div> </div><blockquote style="border: none; margin: 0 0 0 40px; padding: 0px;"><div style="text-align: left;">myenc /root/enc&nbsp;/root/encpass</div></blockquote><div> </div><div>保存重启即可</div><div> </div>

在linux下，为了保护磁盘上的数据安全，可以使用cryptsetup工具对磁盘进行加密。这里演示了如何创建一个加密分区文件enc，同时挂载到指定文件夹下使用的步骤。初始化首选系统需要安装 cryptsetup 工具，然后按下面的步骤初始化加密的虚拟分区文件，并进行首次挂载 fallocate -l 10G enc cryptsetup -c aes-xts-plain64 -s 512 -h sha512 -i 5000 luksFormat enc cryptsetup open enc myenc mkfs.ext4 /dev/mapper/myenc mount /dev/mapper/mye…

阅读全文

腾讯云国内服务器重装系统并设置内网源镜像，docker内网加速镜像等

发布于一月 26, 2024

以debian 11为例，国内服务器访问debian源和docker hub源速度缓慢，为了解决这个问题，需要做一些加速镜像的设置。由于腾讯云建立了内网加速镜像，使用内网加速比网络上的一些公开镜像速度更快且更稳定一些。适合腾讯云的服务器使用。<img src="https://cloudcache.tencent-cloud.com/open_proj/proj_qcloud_v2/gateway/shareicons/cloud.png" />默认从腾讯云官网重装系统后，会自动帮你设置好这些，并贴心的安排上agent。但是对于dd后的纯净系统来说，需要自己手动设置一下，记录如下：<h3 style="text-align: left;">设置内网dns</h3>编辑 /etc/resolv.conf<blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;">nameserver 183.60.83.19 nameserver 183.60.82.98</blockquote><h3 style="text-align: left;">设置系统加速镜像</h3>这里以debian 11为例。编辑 /etc/apt/sources.list<blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;">deb http://mirrors.tencentyun.com/debian/ bullseye main contrib non-free deb http://mirrors.tencentyun.com/debian/ bullseye-updates main contrib non-free deb http://mirrors.tencentyun.com/debian/ bullseye-backports main contrib non-free deb http://mirrors.tencentyun.com/debian-security bullseye-security main contrib non-free</blockquote><h3 style="text-align: left;">设置docker hub加速镜像</h3>安装好docker之后，编辑&nbsp;/etc/docker/daemon.json<blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;">{ &nbsp; &nbsp; "registry-mirrors": [ &nbsp; &nbsp; &nbsp; &nbsp; "http://mirror.ccs.tencentyun.com" &nbsp; &nbsp; ] }</blockquote>然后执行 systemctl restart docker 使修改生效。&nbsp;

以debian 11为例，国内服务器访问debian源和docker hub源速度缓慢，为了解决这个问题，需要做一些加速镜像的设置。由于腾讯云建立了内网加速镜像，使用内网加速比网络上的一些公开镜像速度更快且更稳定一些。适合腾讯云的服务器使用。默认从腾讯云官网重装系统后，会自动帮你设置好这些，并贴心的安排上agent。但是对于dd后的纯净系统来说，需要自己手动设置一下，记录如下：设置内网dns 编辑 /etc/resolv.conf nameserver 183.60.83.19 nameserver 183.60.82.98 设置系统加速镜像这里以debian 11为例。编辑 /etc/apt/so…

阅读全文

IPV6服务器通过warp获得IPV4网络的步骤

发布于一月 11, 2024

目前有部分ipv6 only的服务器价格低廉，但只有ipv6，这类服务器连ssh下载github上的源码都很困难，好在网友已经写好了脚本，用于为这类服务器安装warp以获得ipv4的网络访问能力。步骤很简单： 1. 设置dns64 cp /etc/resolv.conf{,.bak}; echo -e "nameserver 2a00:1098:2b::1\nnameserver 2a01:4f9:c010:3f02::1\nnameserver 2a01:4f8:c2c:123f::1\nnameserver 2a00:1098:2c::1" > /etc/resol…

阅读全文

VPS线路详解：包括163、CN2 GT、CN2 GIA、AS4837、AS9929、CMI/CMIN2线路

发布于十二月 27, 2023

VPS线路详细介绍：电信： ChinaNet（亦称163骨干网，AS4134），IP地址段以202.97开头。此网络旨在承载普通质量的互联网业务，具备早期基建、大带宽和低成本特点。 CN2（ChinaNet Next Generation Carrier Network，即中国电信的下一代承载网，AS4809），IP地址段以59.43开头。相较于163网络，CN2提供较小带宽但更稳定高速的服务。CN2分为CN2 GT与CN2 GIA两种子类型。 CN2 GT（半程使用CN2），作为CN2的中端产品，接入网络为ChinaNet（AS4134），省级骨干使用163（去程和回程均可能经过202.97节点…

阅读全文

解决部分网站禁止复制内容的js脚本（无需安装插件）

发布于十二月 22, 2023

部分网站（例如CSDN）会需要登录才可以复制内容，这无形中增加了很多麻烦，虽然也有一些浏览器插件可以解决禁止复制的问题，但是毕竟还要折腾安装。这里给出一行脚本，打开浏览器开发者模式，在控制台输入并回车即可 javascript:document.body.contentEditable='true';document.designMode='on'; void 0 这个脚本的原理是，为页面开启编辑模式，可以直接在网页上进行文字的添加、删除和修改，就像使用文档编辑器一样。对于如果这时候还是不能使用ctrl+c复制，那么改用ctrl+x剪切内容即可。

阅读全文

生成100年自签ssl证书（https证书）的命令

发布于十二月 22, 2023

有时候为了测试https，需要为nginx配置自签证书，这里给出的命令是通过openssl生成100年有效期的自签SSL证书（https证书），命令如下： openssl version openssl genrsa -out diy.key 2048 openssl req -new -subj "/C=CN/ST=BEIJING/L=BEIJING/O=BEI/OU=CN/CN=diy" -key diy.key -out diy.csr mv diy.key diy.origin.key openssl rsa -in diy.origin.key -out diy.key o…

阅读全文

某运营商云电脑重装Debian 12

发布于十月 30, 2023

本文适用于某运营商云电脑重装Debian，安装分2个部分，一个是从Win安装中转系统Alpine，第二个是从Alpine安装Debian<img src="https://pic.iresearch.cn/news/202302/e3a00cbb-e14c-47d1-874d-09384209a23b.png" />步骤记录如下：<h3>从Win安装到Alpine</h3>下载 <a href="https://raw.githubusercontent.com/bin456789/reinstall/main/reinstall.bat">reinstall.bat</a> ，使用管理员权限打开power shell，执行<blockquote>reinstall.bat alpine-3.18</blockquote>等待即可<h3>进入Alpine配置Grub</h3>使用账号和密码（root/123@@@）登入Alpine，编辑/etc/apk/repositories，添加<blockquote>https://mirrors.tuna.tsinghua.edu.cn/alpine/v3.18/main https://mirrors.tuna.tsinghua.edu.cn/alpine/v3.18/community</blockquote>接着执行 setup-disk ，选择vda硬盘，再选择sys，然后重启重启完成后执行<blockquote>apk update apk add grub grub-bios grub-efi wget curl bash os-prober grub-install /dev/vda</blockquote>接着编辑/etc/default/grub，末尾添加<blockquote>GRUB_DISABLE_OS_PROBER=false</blockquote>最后执行<blockquote>grub-mkconfig -o /boot/grub/grub.cfg</blockquote>然后重启从Alpine安装Debian登入Alpine，使用重装脚本<a href="https://raw.githubusercontent.com/bin456789/reinstall/main/reinstall.sh">reinstall.sh</a>&nbsp;安装debian 12<blockquote>bash &lt;(curl -Ls https://cdn.jsdelivr.net/gh/bin456789/reinstall/reinstall.sh) debian-12</blockquote>等待安装结束后，使用账号密码（root/123@@@）登入即可

本文适用于某运营商云电脑重装Debian，安装分2个部分，一个是从Win安装中转系统Alpine，第二个是从Alpine安装Debian 步骤记录如下：从Win安装到Alpine 下载 reinstall.bat ，使用管理员权限打开power shell，执行 reinstall.bat alpine-3.18 等待即可进入Alpine配置Grub 使用账号和密码（root/123@@@）登入Alpine，编辑/etc/apk/repositories，添加 https://mirrors.tuna.tsinghua.edu.cn/alpine/v3.18/main https://mirrors.tu…

阅读全文

Docker下安装ubuntu使用浏览器远程办公开发

发布于九月 15, 2023

通常需要远程办公的时候，我们一般会远程到某台装有Windows的服务器，就连购买小主机时，也是优先寻找可以安装Windows配置的机器，为的就是Windows桌面环境的操作便利性。<img src="https://assets.ubuntu.com/v1/df4cb5d8-Social+media+banner.jpg" />很早也尝试过使用虚拟机安装Ubuntu进行办公的经历，只是在虚拟机中安装的ubuntu环境，远远谈不上流畅，充其量只能在尝鲜。也因此很少真正的对ubuntu产生好感。最近看到有人尝试在Docker下安装了一个完整的ubuntu，通过web vnc在浏览器中访问即可进入桌面环境，试了一下居然异常的流畅。同时环境中已经装好了大部分的常用软件。这里也记录一下具体的步骤。说来也简单，一行命令就搞定的事情：<pre style="margin-left: 40px; text-align: left;"><code class="language-text-plain" style="color: red;">docker run -d \
 --name docker-ubuntu \
 --hostname docker-ubuntu \
 --restart unless-stopped \
 --cpus 2 \
 --memory 4096M \
 --shm-size 512m \
 -e VNC_PW=password \
 -e LANG=zh_CN.UTF-8 \
 -e LANGUAGE=zh_CN:zh \
 -e LC_ALL=zh_CN.UTF-8 \
 -p 6901:6901 \
 -v /home/docker/ubuntu-desktop/shares:/home/kasm-user/shares \
 kasmweb/ubuntu-jammy-desktop:1.14.0</code></pre>以上需要修改一下<code>VNC_PW</code>的值，完成后浏览器访问https://localhost:6901，输入用户名：kasm_user，密码：<code>VNC_PW</code>的值登录即可。登录后还需要做一下配置，点击页面左侧的悬浮窗，在设置里勾选上“输入法输入法”，即可使用宿主机自身的输入法；在设置里勾选上“无缝剪贴板”，即可在宿主机之间复制粘贴。&nbsp;安装软件和设置目录权限，需要登入root账户。首先在宿主机运行以下命令重置root账户密码：docker exec -u root -it ubuntu passwd接着在容器环境中的终端里运行：su root --login然后就可以正常安装软件了

通常需要远程办公的时候，我们一般会远程到某台装有Windows的服务器，就连购买小主机时，也是优先寻找可以安装Windows配置的机器，为的就是Windows桌面环境的操作便利性。很早也尝试过使用虚拟机安装Ubuntu进行办公的经历，只是在虚拟机中安装的ubuntu环境，远远谈不上流畅，充其量只能在尝鲜。也因此很少真正的对ubuntu产生好感。最近看到有人尝试在Docker下安装了一个完整的ubuntu，通过web vnc在浏览器中访问即可进入桌面环境，试了一下居然异常的流畅。同时环境中已经装好了大部分的常用软件。这里也记录一下具体的步骤。说来也简单，一行命令就搞定的事情： docker ru…

阅读全文

Cloudflare防火墙安全配置WAF（防CC）

发布于八月 29, 2023

Cloudflare的WAF提供了5条自定义规则和1条速率限制规则，配置好了可以很好的解决网站安全的问题，以下是规则的配置。<img src="https://cf-assets.www.cloudflare.com/slt3lc6tev37/2FNnxFZOBEha1W2MhF44EN/e9438de558c983ccce8129ddc20e1b8b/CF_MetaImage_1200x628.png" /><h3 style="text-align: left;">自定义规则</h3>先看自定义规则：<h4 style="text-align: left;">1. 放行Bot和白名单</h4>(cf.client.bot) or (ip.geoip.asnum eq 30081) or (ip.src in {1.1.1.1 2.2.2.2 3.3.3.3 4.4.4.4})这里设置为跳过。 <h4 style="text-align: left;">2. 验证IDC</h4>(ip.geoip.asnum in {174 195 209 577 792 793 794 1215 1216 1217 2497 2914 3223 3255 3269 3326 3329 3457 3462 3598 4184 4190 4637 4694 4755 4785 4788 4816 4826 4835 5056 5610 5617 6471 6584 6830 6876 6877 6939 7029 7224 7303 7489 7552 7684 8068 8069 8070 8071 8074 8075 8100 8220 8560 8881 8987 9009 9299 9312 9370 9534 9678 9952 9984 10026 10453 11351 11426 11691 12076 12271 12334 12367 12874 12876 12989 14061 14117 14140 14576 14618 15169 16276 16509 16591 16629 17043 17428 17707 17788 17789 17790 17791 18013 18228 18403 18450 18599 18734 18978 19527 19740 20207 20473 20552 20554 20860 21704 21769 21859 21887 22773 22884 23468 23724 23885 23959 23969 24088 24192 24424 24429 24940 25429 25697 25820 25935 25961 26160 26496 26818 27715 28429 28431 28438 28725 29066 29286 29287 29802 30083 30823 31122 31235 31400 31898 32097 32098 32505 32613 34081 34248 34549 34947 35070 35212 35320 35540 35593 35804 35816 35908 35916 36351 36352 36384 36385 36444 36492 36806 37963 37969 38001 38197 38283 38365 38538 38587 38588 38627 39284 40065 40676 40788 41009 41096 41264 41378 42652 42905 43289 43624 43989 45011 45012 45062 45076 45085 45090 45102 45102 45102 45103 45104 45139 45458 45566 45576 45629 45753 45899 45932 46484 46844 47232 47285 47927 48024 48024 48337 48905 49327 49588 49981 50297 50340 50837 51852 52000 52228 52341 53089 54463 54538 54574 54600 54854 54994 55158 55330 55720 55799 55924 55933 55960 55967 55990 55992 56005 56011 56109 56222 57613 58073 58199 58461 58466 58519 58543 58563 58593 58772 58773 58774 58775 58776 58844 58854 58862 58879 59019 59028 59048 59050 59051 59052 59053 59054 59055 59067 59077 59374 60068 60592 60631 60798 61154 61317 61348 61577 61853 62044 62240 62468 62785 62904 63018 63023 63075 63288 63314 63545 63612 63620 63631 63655 63677 63678 63679 63727 63728 63729 63835 63838 63888 63916 63949 64050 131090 131106 131138 131139 131140 131141 131293 131428 131444 131477 131486 131495 132196 132203 132509 132510 132513 132591 132839 133024 133199 133380 133478 133492 133746 133752 133774 133775 133776 133905 133929 134238 134327 134760 134761 134763 134764 134769 134770 134771 134835 134963 135061 135290 135300 135330 135377 135629 137693 137697 137699 137753 137784 137785 137787 137788 137876 137969 138366 138407 138607 138915 138949 138950 138952 138982 138994 139007 139018 139124 139144 139201 139203 139220 139316 139327 139726 139887 140096 140596 140701 140716 140717 140720 140723 140979 141157 141180 142570 149167 177453 177549 197099 197540 198047 198651 199490 199506 199524 199883 200756 201094 201978 202053 202675 203087 204601 204720 206092 206204 206791 206798 207319 207400 207590 208425 208556 211914 212708 213251 213375 262187 263022 263196 263639 263693 264344 264509 265443 265537 266706 267784 269939 270110 328608 394699 395003 395936 395954 395973 398101 }) 这里设置为交互式质询。ASN也可以参考<a href="https://github.com/DreamFerry/cloudflare-block-bad-bot-ruleset" rel="nofollow" target="_blank">这里</a> <h4 style="text-align: left;">3. 验证风险IP</h4>(cf.threat_score gt 30) or (ip.src in $risk_ip)这里设置为js质询。风险ip需要通过【管理账户】-【配置】-【列表】-【创建新列表】创建一个包含高风险IP的列表，命名为risk_ip。清单可以参考<a href="https://static.lty.fun/%E5%85%B6%E4%BB%96%E8%B5%84%E6%BA%90/CF/WAF/List-RiskIP.csv" rel="nofollow" target="_blank">这里</a><h3 style="text-align: left;">速率限制规则</h3>接着看请求速率限制，这里只允许设置一条(http.request.uri.path contains "/")这样设置相当于匹配所有，下面的速率配置50次/10秒，应该就差不多了

Cloudflare的WAF提供了5条自定义规则和1条速率限制规则，配置好了可以很好的解决网站安全的问题，以下是规则的配置。自定义规则先看自定义规则： 1. 放行Bot和白名单 (cf.client.bot) or (ip.geoip.asnum eq 30081) or (ip.src in {1.1.1.1 2.2.2.2 3.3.3.3 4.4.4.4}) 这里设置为跳过。 2. 验证IDC (ip.geoip.asnum in {174 195 209 577 792 793 794 1215 1216 1217 2497 2914 3223 3255 3269 3326 3329 3457…

阅读全文

NAT 穿透是如何工作的：技术原理及企业级实践

发布于八月 26, 2023

<h1>1 引言</h1><h2>1.1 背景：IPv4 地址短缺，引入 NAT</h2>全球 IPv4 地址早已不够用，因此人们发明了 NAT（网络地址转换）来缓解这个问题。简单来说，大部分机器都使用私有 IP 地址，如果它们需要访问公网服务，那么，<ul><li>出向流量：需要经过一台 NAT 设备，它会对流量进行 SNAT，将私有 srcIP+Port 转 换成 NAT 设备的公网 IP+Port（这样应答包才能回来），然后再将包发出去；</li><li>应答流量（入向）：到达 NAT 设备后进行相反的转换，然后再转发给客户端。</li></ul>整个过程对双方透明。<blockquote>更多关于 NAT 的内容，可参考&nbsp;<a href="https://arthurchiao.art/blog/nat-zh/">(译) NAT - 网络地址转换（2016）</a>。 译注。</blockquote>以上是本文所讨论问题的基本背景。<h2>1.2 需求：两台经过 NAT 的机器建立点对点连接</h2>在以上所描述的 NAT 背景下，我们从最简单的问题开始：如何在两台经过 NAT 的机器之间建立&nbsp;点对点连接（直连）。如下图所示：<img height="70%" src="https://arthurchiao.art/assets/img/nat-traversal/nat-intro.png" width="70%" />直接用机器的 IP 互连显然是不行的，因为它们都是私有 IP（例如&nbsp;<code>192.168.1.x</code>）。 在 Tailscale 中，我们会建立一个&nbsp;WireGuard? 隧道&nbsp;来解决这个问题 —— 但这并不是太重要，因为我们将过去几代人努力都整合到了一个工具集，&nbsp;这些技术广泛适用于各种场景。例如，<ol><li><a href="https://webrtc.org/">WebRTC</a>&nbsp;使用这些技术在浏览器之间完成 peer-to-peer 语音、视频和数据传输，</li><li>VoIP 电话和一些视频游戏也使用类似机制，虽然不是所有情况下都很成功。</li></ol>接下来，本文将在一般意义上讨论这些技术，并在合适的地方拿 Tailscale 和其他一些东西作为例子。<h2>1.3 方案：NAT 穿透</h2><h3>1.3.1 两个必备前提：UDP + 能直接控制 socket</h3>如果想设计自己的协议来实现 NAT 穿透，那必须满足以下两个条件：<ol><li>协议应该基于 UDP。理论上用 TCP 也能实现，但它会给本已相当复杂的问题再增加一层复杂性， 甚至还需要定制化内核 —— 取决于你想实现到什么程度。本文接下来都将关注在 UDP 上。如果考虑 TCP 是想在 NAT 穿透时获得面向流的连接（ stream-oriented connection），可以考虑用&nbsp;QUIC&nbsp;来替代，它构 建在 UDP 之上，因此我们能将关注点放在 UDP NAT 穿透，而仍然能获得一个 很好的流协议（stream protocol）。</li><li>对收发包的&nbsp;socket 有直接控制权。例如，从经验上来说，无法基于某个现有的网络库实现 NAT 穿透，因为我们&nbsp;必须在使用的“主要”协议之外，发送和接收额外的数据包。某些协议（例如 WebRTC）将 NAT 穿透与其他部分紧密集成。但如果你在构建自己的协议，&nbsp;建议将 NAT 穿透作为一个独立实体，与主协议并行运行，二者仅 仅是共享 socket 的关系，如下图所示，这将带来很大帮助：<img height="70%" src="https://arthurchiao.art/assets/img/nat-traversal/nat-deep-integration.png" width="70%" /></li></ol><h3>1.3.2 保底方式：中继</h3>在某些场景中，直接访问 socket 这一条件可能很难满足。退而求其次的一个方式是设置一个 local proxy（本地代理），主协议与这个 proxy 通信 ，后者来完成 NAT 穿透，将包中继（relay）给对端。这种方式增加了一个额外的间接层 ，但好处是：<ol><li>仍然能获得 NAT 穿透，</li><li>不需要对已有的应用程序做任何改动。</li></ol><h2>1.4 挑战：有状态防火墙和 NAT 设备</h2>有了以上铺垫，下面就从最基本的原则开始，一步步看如何实现一个企业级的 NAT 穿透方案。我们的目标是：在两个设备之间通过 UDP 实现双向通信， 有了这个基础，上层的其他协议（WireGuard, QUIC, WebRTC 等）就能做一些更酷的事情。但即便这个看似最基本的功能，在实现上也要解决两个障碍：<ol><li>有状态防火墙</li><li>NAT 设备</li></ol><h1>2 穿透防火墙</h1>有状态防火墙是以上两个问题中相对比较容易解决的。实际上，大部分 NAT 设备都自带了一个有状态防火墙， 因此要解决第二个问题，必须先解决有第一个问题。有状态防火墙具体有很多种类型，有些你可能见过：<ul><li>Windows Defender firewall</li><li>Ubuntu’s ufw (using iptables/nftables)</li><li>BSD/macOS&nbsp;<code>pf</code></li><li>AWS Security Groups（安全组）</li></ul><h2>2.1 有状态防火墙</h2><h3>2.1.1 默认行为（策略）</h3>以上防火墙的配置都是很灵活的，但大部分配置默认都是如下行为：<ol><li>允许所有出向连接（allows all “outbound” connections）</li><li>禁止所有入向连接（blocks all “inbound” connections）</li></ol>可能有少量例外规则，例如 allowing inbound SSH。<h3>2.1.2 如何区分入向和出向包</h3>连接（connection）和方向（direction）都是协议设计者头脑中的概念，到了&nbsp;物理传输层，每个连接都是双向的；允许所有的包双向传输。 那防火墙是如何区分哪些是入向包、哪些是出向包的呢？ 这就要回到“有状态”（stateful）这三个字了：有状态防火墙会记录它 看到的每个包，当收到下一个包时，会利用这些信息（状态）来判断应该做什么。对 UDP 来说，规则很简单：如果防火墙之前看到过一个出向包（outbound），就会允许 相应的入向包（inbound）通过，以下图为例：<img height="70%" src="https://arthurchiao.art/assets/img/nat-traversal/nat-firewalls-1a.png" width="70%" />笔记本电脑中自带了一个防火墙，当该防火墙看到从这台机器出去的&nbsp;<code>2.2.2.2:1234 -&gt; 5.5.5.5:5678</code>&nbsp;包时，就会记录一下：<code>5.5.5.5:5678 -&gt; 2.2.2.2:1234</code>&nbsp;入向包应该放行。&nbsp;这里的逻辑是：我们信任的世界（即笔记本）想主动与&nbsp;<code>5.5.5.5:5678</code>&nbsp;通信，因此应该放行（allow）其回包路径。<blockquote>某些非常宽松的防火墙只要看到有从&nbsp;<code>2.2.2.2:1234</code>&nbsp;出去的包，就 会允许所有从外部进入&nbsp;<code>2.2.2.2:1234</code>&nbsp;的流量。这种防火墙对我们的 NAT 穿透来说非 常友好，但已经越来越少见了。</blockquote><h2>2.2 防火墙朝向（face-off）与穿透方案</h2><h3>2.2.1 防火墙朝向相同</h3><h4>场景特点：服务端 IP 可直接访问</h4>在 NAT 穿透场景中，以上默认规则对 UDP 流量的影响不大 —— 只要路径上所有防火墙的“朝向”是一样的。 一般来说，从内网访问公网上的某个服务器都属于这种情况。我们唯一的要求是：连接必须是由防火墙后面的机器发起的。这是因为 在它主动和别人通信之前，没人能主动和它通信，如下图所示：<h4>穿透方案：客户端直连服务端，或 hub-and-spoke 拓扑</h4><img height="80%" src="https://arthurchiao.art/assets/img/nat-traversal/nat-firewalls-2.png" width="80%" />但上图是假设了通信双方中，其中一端（服务端）是能直接访问到的。 在 VPN 场景中，这就形成了所谓的&nbsp;hub-and-spoke 拓扑：中心的 hub 没有任何防火墙策略，谁都能访问到； 防火墙后面的 spokes 连接到 hub。如下图所示：<img height="70%" src="https://arthurchiao.art/assets/img/nat-traversal/nat-firewalls-3.png" width="70%" /><h3>2.2.2 防火墙朝向不同</h3><h4>场景特点：服务端 IP 不可直接访问</h4>但如果两个“客户端”想直连，以上方式就不行了，此时两边的防火墙相向而立，如下图所示：<img height="70%" src="https://arthurchiao.art/assets/img/nat-traversal/nat-firewalls-4.png" width="70%" />根据前面的讨论，这种情况意味着：两边要同时发起连接请求，但也意味着 两边都无法发起有效请求，因为对方先发起请求才能在它的防火墙上打开一条缝让我们进去！ 如何破解这个问题呢？一种方式是让用户重新配置一边或两边的防火墙，打开一个端口， 允许对方的流量进来。<ol><li>这显然对用户不友好，在像 Tailscale 这样的 mesh 网络中的扩展性也不好，在 mesh 网络中，我们假设对端会以一定的粒度在公网上移动。</li><li>此外，在很多情况下用户也没有防火墙的控制权限：例如在咖啡馆或机场中，连接的路 由器是不受你控制的（否则你可能就有麻烦了）。</li></ol>因此，我们需要寻找一种不用重新配置防火墙的方式。<h4>穿透方案：两边同时主动建连，在本地防火墙为对方打开一个洞</h4>解决的思路还是先重新审视前面提到的有状态防火墙规则：<ul><li>对于 UDP，其规则（逻辑）是：包必须先出去才能进来（packets must flow out before packets can flow back in）。</li><li>注意，这里除了要满足包的 IP 和端口要匹配这一条件之外，并没有要求包必须是相关的（related）。 换句话说，只要某些包带着正确的源和目的地址出去了，任何看起来像是响应的包都会被防火墙放进来&nbsp;—— 即使对端根本没收到你发出去的包。</li></ul>因此，要穿透这些有状态防火墙，我们只需要共享一些信息：让两端提前知道对方使用的 ip:port：<ul><li>手动静态配置是一种方式，但显然扩展性不好；</li><li>我们开发了一个&nbsp;<a href="https://tailscale.com/blog/how-tailscale-works/#the-control-plane-key-exchange-and-coordination">coordination server</a>， 以灵活、安全的方式来同步&nbsp;<code>ip:port</code>&nbsp;信息。</li></ul>有了对方的&nbsp;<code>ip:port</code>&nbsp;信息之后，两端开始给对方发送 UDP 包。在这个过程中，我们预 料到某些包将会被丢弃。因此，双方必须要接受某些包会丢失的事实， 因此如果是重要信息，你必须自己准备好重传。对 UDP 来说丢包是可接受的，但这里尤其需要接受。来看一下具体建连（穿透）过程：<ol><li>如图所示，笔记本出去的第一包，<code>2.2.2.2:1234 -&gt; 7.7.7.7:5678</code>，穿过 Windows Defender 防火墙进入到公网。<img height="70%" src="https://arthurchiao.art/assets/img/nat-traversal/nat-firewalls-5a.png" width="70%" />对方的防火墙会将这个包拦截掉，因为它没有&nbsp;<code>7.7.7.7:5678 -&gt; 2.2.2.2:1234</code>&nbsp;的流量记录。 但另一方面，Windows Defender 此时已经记录了出向连接，因此会允许&nbsp;<code>7.7.7.7:5678 -&gt; 2.2.2.2:1234</code>&nbsp;的应答包进来。</li><li>接着，第一个&nbsp;<code>7.7.7.7:5678 -&gt; 2.2.2.2:1234</code>&nbsp;穿过它自己的防火墙到达公网。<img height="70%" src="https://arthurchiao.art/assets/img/nat-traversal/nat-firewalls-5b.png" width="70%" />到达客户端侧时，Windows Defender&nbsp;认为这是刚才出向包的应答包，因此就放行它进入了！&nbsp;此外，右侧的防火墙此时也记录了：<code>2.2.2.2:1234 -&gt; 7.7.7.7:5678</code>&nbsp;的包应该放行。</li><li>笔记本收到服务器发来的包之后，发送一个包作为应答。这个包穿过 Windows Defender 防火墙 和服务端防火墙（因为这是对服务端发送的包的应答包），达到服务端。<img height="70%" src="https://arthurchiao.art/assets/img/nat-traversal/nat-firewalls-5c.png" width="70%" /></li></ol>成功！这样我们就建立了一个穿透两个相向防火墙的双向通信连接。 而初看之下，这项任务似乎是不可能完成的。<h2>2.3 关于穿透防火墙的一些思考</h2>穿透防火墙并非永远这么轻松，有时会受一些第三方系统的间接影响，需要仔细处理。 那穿透防火墙需要注意什么呢？重要的一点是：通信双方必须几乎同时发起通信， 这样才能在路径上的防火墙打开一条缝，而且两端还都是活着的。<h3>2.3.1 双向主动建连：旁路信道</h3>如何实现“同时”呢？一种方式是两端不断重试，但显然这种方式很浪费资源。假如双方都 知道何时开始建连就好了。<ul><li>这听上去是鸡生蛋蛋生鸡的问题了：双方想要通信，必须先提前通个信。</li><li>但实际上，我们可以通过旁路信道（side channel）来达到这个目的 ，并且这个旁路信道并不需要很 fancy：它可以有几秒钟的延迟、只需要传送几 KB 的 信息，因此即使是一个配置非常低的虚拟机，也能为几千台机器提供这样的旁路通信服务。<ul><li>在遥远的过去，我曾用 XMPP 聊天消息作为旁路，效果非常不错。</li><li>另一个例子是 WebRTC，它需要你提供一个自己的“信令信道”（signalling channel， 这个词也暗示了 WebRTC 的 IP telephony ancestry），并将其配置到 WebRTC API。</li><li>在 Tailscale，我们的协调服务器（coordination server）和 DERP (Detour Encrypted Routing Protocol) 服务器集群是我们的旁路信道。</li></ul></li></ul><h3>2.3.2 非活跃连接被防火墙清理</h3>有状态防火墙内存通常比较有限，因此会定期清理不活跃的连接（UDP 常见的是 30s）， 因此要保持连接 alive 的话需要定期通信，否则就会被防火墙关闭，为避免这个问题， 我们，<ol><li>要么定期向对方发包来 keepalive，</li><li>要么有某种带外方式来按需重建连接。</li></ol><h3>2.3.3 问题都解决了？不，挑战刚刚开始</h3>对于防火墙穿透来说， 我们并不需要关心路径上有几堵墙&nbsp;—— 只要它们是有状态防火墙且允许出 向连接，这种同时发包（simultaneous transmission）机制就能穿透任意多层防火墙。 这一点对我们来说非常友好，因为只需要实现一个逻辑，然后能适用于任何地方了。…对吗？其实，不完全对。这个机制有效的前提是：我们能提前知道对方的 ip:port。 而这就涉及到了我们今天的主题：NAT，它会使前面我们刚获得的一点满足感顿时消失。下面，进入本文正题。<h1>3 NAT 的本质</h1><h2>3.1 NAT 设备与有状态防火墙</h2>可以认为 NAT 设备是一个增强版的有状态防火墙，虽然它的增强功能 对于本文场景来说并不受欢迎：除了前面提到的有状态拦截/放行功能之外，它们还会在数据包经过时修改这些包。<h2>3.2 NAT 穿透与 SNAT/DNAT</h2>具体来说，NAT 设备能完成某种类型的网络地址转换，例如，替换源或目的 IP 地址或端口。<ul><li>讨论连接问题和 NAT 穿透问题时，我们只会受 source NAT —— SNAT 的影响。</li><li>DNAT 不会影响 NAT 穿透。</li></ul><h2>3.3 SNAT 的意义：解决 IPv4 地址短缺问题</h2>SNAT 最常见的使用场景是将很多设备连接到公网，而只使用少数几个公网 IP。 例如对于消费级路由器，会将所有设备的（私有） IP 地址映射为单个连接到公网的 IP 地址。这种方式存在的意义是：我们有远多于可用公网 IP 数量的设备需要连接到公网，（至少 对 IPv4 来说如此，IPv6 的情况后面会讨论）。NAT 使多个设备能共享同一 IP 地址，因 此即使面临 IPv4 地址短缺的问题，我们仍然能不断扩张互联网的规模。<h2>3.4 SNAT 过程：以家用路由器为例</h2>假设你的笔记本连接到家里的 WiFi，下面看一下它连接到公网某个服务器时的情形：<ol><li>笔记本发送 UDP packet&nbsp;<code>192.168.0.20:1234 -&gt; 7.7.7.7:5678</code>。<img height="70%" src="https://arthurchiao.art/assets/img/nat-traversal/nat-overview-1.png" width="70%" />这一步就好像笔记本有一个公网 IP 一样，但源地址&nbsp;<code>192.168.0.20</code>&nbsp;是私有地址， 只能出现在私有网络，公网不认，收到这样的包时它不知道如何应答。</li><li>家用路由器出场，执行 SNAT。包经过路由器时，路由器发现这是一个它没有见过的新会话（session）。 它知道&nbsp;<code>192.168.0.20</code>&nbsp;是私有 IP，公网无法给这样的地址回包，但它有办法解决：<ol><li>在它自己的公网 IP 上挑一个可用的 UDP 端口，例如&nbsp;<code>2.2.2.2:4242</code>，</li><li>然后创建一个&nbsp;NAT mapping：<code>192.168.0.20:1234</code>&nbsp;<code>&lt;--&gt;</code>&nbsp;<code>2.2.2.2:4242</code>，</li><li>然后将包发到公网，此时源地址变成了&nbsp;<code>2.2.2.2:4242</code>&nbsp;而不是原来的&nbsp;<code>192.168.0.20:1234</code>。因此服务端看到的是转换之后地址，</li><li>接下来，每个能匹配到这条映射规则的包，都会被路由器改写 IP 和 端口。</li></ol><img height="70%" src="https://arthurchiao.art/assets/img/nat-traversal/nat-overview-2.png" width="70%" /></li><li>反向路径是类似的，路由器会执行相反的地址转换，将&nbsp;<code>2.2.2.2:4242</code>&nbsp;变回&nbsp;<code>192.168.0.20:1234</code>。对于笔记本来说，它根本感知不知道这正反两次变换过程。</li></ol>这里是拿家用路由器作为例子，但办公网的原理是一样的。不同之处在 于，办公网的 NAT 可能有多台设备组成（高可用、容量等目的），而且它们有不止一个公 网 IP 地址可用，因此在选择可用的公网&nbsp;<code>ip:port</code>&nbsp;来做映射时，选择空间更大，能支持 更多客户端。<img height="70%" src="https://arthurchiao.art/assets/img/nat-traversal/nat-overview-3.png" width="70%" /><h2>3.5 SNAT 给穿透带来的挑战</h2>现在我们遇到了与前面有状态防火墙类似的情况，但这次是 NAT 设备：通信双方 不知道对方的 ip:port 是什么，因此无法主动建连，如下图所示：<img height="70%" src="https://arthurchiao.art/assets/img/nat-traversal/nat-stun-1.png" width="70%" />但这次比有状态防火墙更糟糕，严格来说，在双方发包之前，根本无法确定（自己及对方的）ip:port 信息，因为&nbsp;只有出向包经过路由器之后才会产生 NAT mapping（即，可以被对方连接的&nbsp;<code>ip:port</code>&nbsp;信息）。因此我们又回到了与防火墙遇到的问题，并且情况更糟糕：双方都需要主动和对 方建连，但又不知道对方的公网地址是多少，只有当对方先说话之后，我们才能拿到它的地址信息。如何破解以上死锁呢？这就轮到&nbsp;<a href="https://en.wikipedia.org/wiki/STUN">STUN</a>&nbsp;登场了。<h1>4 穿透 “NAT+防火墙”：STUN (Session Traversal Utilities for NAT) 协议</h1><a href="https://en.wikipedia.org/wiki/STUN">STUN</a>&nbsp;既是一些对 NAT 设备行为的详细研究，也是一种协助 NAT 穿透的协议。本文主要关注 STUN 协议。<h2>4.1 STUN 原理</h2>STUN 基于一个简单的观察：从一个会被 NAT 的客户端访问公网服务器时， 服务器看到的是&nbsp;NAT 设备的公网 ip:port 地址，而非该&nbsp;客户端的局域网 ip:port 地址。也就是说，服务器能告诉客户端它看到的客户端的 ip:port 是什么。 因此，只要将这个信息以某种方式告诉通信对端（peer），后者就知道该和哪个地址建连了！ 这样就又简化为前面的防火墙穿透问题了。本质上这就是&nbsp;STUN 协议的工作原理，如下图所示：<ul><li>笔记本向 STUN 服务器发送一个请求：“从你的角度看，我的地址什么？”</li><li>STUN 服务器返回一个响应：“我看到你的 UDP 包是从这个地址来的：<code>ip:port</code>”。</li></ul><img height="70%" src="https://arthurchiao.art/assets/img/nat-traversal/nat-stun-2.png" width="70%" /><blockquote>The STUN protocol has a bunch more stuff in it — there’s a way of obfuscating the&nbsp;<code>ip:port</code>&nbsp;in the response to stop really broken NATs from mangling the packet’s payload, and a whole authentication mechanism that only really gets used by TURN and ICE, sibling protocols to STUN that we’ll talk about in a bit. We can ignore all of that stuff for address discovery.</blockquote><h2>4.2 为什么 NAT 穿透逻辑和主协议要共享同一个 socket</h2>理解了 STUN 原理，也就能理解为什么我们在文章开头说，如果&nbsp;要实现自己的 NAT 穿透逻辑和主协议，就必须让二者共享同一个 socket：<ol><li>每个 socket 在 NAT 设备上都对应一个映射关系（私网地址 -&gt; 公网地址），</li><li>STUN 服务器只是辅助穿透的基础设施，</li><li>与 STUN 服务器通信之后，在 NAT 及防火墙设备上打开了一个连接，允许入向包进来（回忆前面内容，&nbsp;只要目的地址对，UDP 包就能进来，不管这些包是不是从 STUN 服务器来的），</li><li>因此，接下来只要将这个地址告诉我们的通信对端（peer），让它往这个地址发包，就能实现穿透了。</li></ol><h2>4.3 STUN 的问题：不能穿透所有 NAT 设备（例如企业级 NAT 网关）</h2>有了 STUN，我们的穿透目的似乎已经实现了：每台机器都通过 STUN 来获取自己的私网 socket 对应的公网&nbsp;<code>ip:port</code>，然后把这个信息告诉对端，然后两端 同时发起穿透防火墙的尝试，后面的过程就和上一节介绍的防火墙穿透一样了，对吗？答案是：看情况。某些情况下确实如此，但有些情况下却不行。通常来说，<ul><li>对于大部分家用路由器场景，这种方式是没问题的；</li><li>但对于一些企业级 NAT 网关来说，这种方式无法奏效。</li></ul>NAT 设备的说明书上越强调它的安全性，STUN 方式失败的可能性就越高。（但注意，从实际意义上来说，&nbsp;NAT 设备在任何方面都并不会增强网络的安全性，但这不是本文重点，因此不展开。）<h2>4.4 重新审视 STUN 的前提</h2>再次审视前面关于 STUN 的假设：当 STUN 服务器告诉客户端在公网看来它的地址是&nbsp;<code>2.2.2.2:4242</code>&nbsp;时，那所有目的地址是&nbsp;<code>2.2.2.2:4242</code>&nbsp;的包就都能穿透防火墙到达该客户端。这也正是问题所在：这一点并不总是成立。<ul><li>某些 NAT 设备的行为与我们假设的一致，它们的有状态防火墙组件只要看到有客户端自己 发起的出向包，就会允许相应的入向包进入；因此只要利用 STUN 功能，再加上两端同时 发起防火墙穿透，就能把连接打通；<blockquote>in theory, there are also NAT devices that are super relaxed, and don’t ship with stateful firewall stuff at all. In those, you don’t even need simultaneous transmission, the STUN request gives you an internet&nbsp;<code>ip:port</code>&nbsp;that anyone can connect to with no further ceremony. If such devices do still exist, they’re increasingly rare.</blockquote></li><li>另外一些 NAT 设备就要困难很多了，它会针对每个目的地址来生成一条相应的映射关系。 在这样的设备上，如果我们用相同的 socket 来分别发送数据包到&nbsp;<code>5.5.5.5:1234</code>&nbsp;and&nbsp;<code>7.7.7.7:2345</code>，我们就会得到&nbsp;<code>2.2.2.2</code>&nbsp;上的两个不同的端口，每个目的地址对应一个。 如果反向包的端口用的不对，包就无法通过防火墙。如下图所示：<img height="70%" src="https://arthurchiao.art/assets/img/nat-traversal/nat-stun-3.png" width="70%" /></li></ul><h1>5 中场补课：NAT 正式术语</h1>知道 NAT 设备的行为并不是完全一样之后，我们来引入一些正式术语。<h2>5.1 早期术语</h2>如果之前接触过 NAT 穿透，可能会听说过下面这些名词：<ul><li>“Full Cone”</li><li>“Restricted Cone”</li><li>“Port-Restricted Cone”</li><li>“Symmetric” NATs</li></ul>这些都是 NAT 穿透领域的早期术语。但其实这些术语相当让人困惑。我每次都要 查一下 Restricted Cone NAT 是什么意思。从实际经验来看，我并不是唯一对此感到困惑的人。 例如，如今互联网上将 “easy” NAT 归类为 Full Cone，而实际上它们更应该归类为 Port-Restricted Cone。<h2>5.2 近期研究与新术语</h2>最近的一些研究和 RFC 已经提出了一些更准确的术语。<ul><li>首先，它们明确了如下事实：NAT 设备的行为差异表现在多个维度， 而并非只有早期研究中所说的 “cone” 这一个维度，因此基于 “cone” 来划分类别并不是很有帮助。</li><li>其次，新研究和新术语能更准确地描述 NAT 在做什么。</li></ul>前面提到的所谓&nbsp;"easy" 和 "hard" NAT，只在一个维度有不同：NAT 映射是否考虑到目的地址信息。&nbsp;<a href="https://tools.ietf.org/html/rfc4787">RFC 4787</a>&nbsp;中，<ul><li>将&nbsp;easy NAT 及其变种称为 “Endpoint-Independent Mapping” (EIM，终点无关的映射)但是，从“命名很难”这一程序员界的伟大传统来说，EIM 这个词其实 也并不是 100% 准确，因为这种 NAT 仍然依赖 endpoint，只不过依赖的是源 endpoint：每个 source&nbsp;<code>ip:port</code>&nbsp;对应一个映射 —— 否则你的包就会和别人的包混在一起，导致混乱。严格来说，EIM 应该称为 “Destination Endpoint Independent Mapping” (DEIM?)， 但这个名字太拗口了，而且按照惯例，Endpoint 永远指的是 Destination Endpoint。</li><li>将&nbsp;hard NAT 以及变种称为 “Endpoint-Dependent Mapping”（EDM，终点相关的映射） 。EDM 中还有一个子类型，依据是只根据 dst_ip 做映射，还是根据 dst_ip + dst_port 做映射。 对于 NAT 穿透来说，这种区分对来说是一样的：它们都会导致 STUN 方式不可用。</li></ul><h2>5.3 老的 cone 类型划分</h2>你可能会有疑问：根据是否依赖 endpoint 这一条件，只能组合出两种可能，那为什么传 统分类中会有四种 cone 类型呢？答案是&nbsp;cone 包含了两个正交维度的 NAT 行为：<ul><li>NAT 映射行为：前面已经介绍过了，</li><li>有状态防火墙行为：与前者类似，也是分为与 endpoint 相关还是无关两种类型。</li></ul>因此最终组合如下：NAT Cone Types<table><thead><tr><th> </th><th>Endpoint 无关 NAT mapping</th><th>Endpoint 相关 NAT mapping (all types)</th></tr></thead><tbody><tr><td>Endpoint 无关防火墙</td><td>Full Cone NAT</td><td>N/A*</td></tr><tr><td>Endpoint 相关防火墙 (dst. IP only)</td><td>Restricted Cone NAT</td><td>N/A*</td></tr><tr><td>Endpoint 相关防火墙 (dst. IP+port)</td><td>Port-Restricted Cone NAT</td><td>Symmetric NAT</td></tr></tbody></table>分解到这种程度之后就可以看出，cone 类型对 NAT 穿透场景来说并没有什么意义。 我们关心的只有一点：是否是 Symmetric —— 换句话说，一个 NAT 设备是 EIM 还是 EDM 类型的。<h2>5.4 针对 NAT 穿透场景：简化 NAT 分类</h2>以上讨论可知，虽然理解防火墙的具体行为很重要，但对于编写 NAT 穿透代码来说，这一点并不重要。 我们的两端同时发包方式（simultaneous transmission trick）能&nbsp;有效穿透以上三种类型的防火墙。在真实场景中， 我们主要在处理的是 IP-and-port endpoint-dependent 防火墙。因此，对于实际 NAT 穿透实现，我们可以将以上分类简化成：<table><thead><tr><th> </th><th>Endpoint-Independent NAT mapping</th><th>Endpoint-Dependent NAT mapping (dst. IP only)</th></tr></thead><tbody><tr><td>Firewall is yes</td><td>Easy NAT</td><td>Hard NAT</td></tr></tbody></table><h2>5.5 更多 NAT 规范（RFC）</h2>想了解更多新的 NAT 术语，可参考<ul><li>RFC&nbsp;<a href="https://tools.ietf.org/html/rfc4787">4787</a>&nbsp;(NAT Behavioral Requirements for UDP)</li><li>RFC&nbsp;<a href="https://tools.ietf.org/html/rfc5382">5382</a>&nbsp;(for TCP)</li><li>RFC&nbsp;<a href="https://tools.ietf.org/html/rfc5508">5508</a>&nbsp;(for ICMP)</li></ul>如果自己实现 NAT，那应该（should）遵循这些 RFC 的规范，这样才能使你的 NAT 行为符合业界惯例，与其他厂商的设备或软件良好兼容。<h1>6 穿透 NAT+防火墙：STUN 不可用时，fallback 到中继模式</h1><h2>6.1 问题回顾与保底方式（中继）</h2>补完基础知识（尤其是定义了什么是 hard NAT）之后，回到我们的 NAT 穿透主题。<ul><li>第 1~4 节已经解决了 STUN 和防火墙穿透的问题，</li><li>但&nbsp;hard NAT 对我们来说是个大问题，只要路径上出现一个这种设备，前面的方案就行不通了。</li></ul>准备放弃了吗？ 这才进入 NAT 真正有挑战的部分：如果已经试过了前面介绍的所有方式 仍然不能穿透，我们该怎么办呢？<ul><li>实际上，确实有很多 NAT 实现在这种情况下都会选择放弃，向用户报一个“无法连接”之类的错误。</li><li>但对我们来说，这么快就放弃显然是不可接受的 —— 解决不了连通性问题，Tailscale 就没有存在的意义。</li></ul>我们的保底解决方式是：创建一个中继连接（relay）实现双方的无障碍地通信。 但是，中继方式性能不是很差吗？这要看具体情况：<ul><li>如果能直连，那显然没必要用中继方式；</li><li>但如果无法直连，而中继路径又非常接近双方直连的真实路径，并且带宽足够大，那中 继方式并不会明显降低通信质量。延迟肯定会增加一点，带宽会占用一些，但&nbsp;相比完全连接不上，还是更能让用户接受的。</li></ul>不过要注意：我们只有在无法直连时才会选择中继方式。实际场景中，<ol><li>对于大部分网络，我们都能通过前面介绍的方式实现直连，</li><li>剩下的长尾用中继方式来解决，并不算一个很糟的方式。</li></ol>此外，某些网络会阻止 NAT 穿透，其影响比这种 hard NAT 大多了。例如，我们观察到 UC Berkeley guest WiFi 禁止除 DNS 流量之外的所有 outbound UDP 流量。 不管用什么 NAT 黑科技，都无法绕过这个拦截。因此我们终归还是需要一些可靠的 fallback 机制。<h2>6.2 中继协议：TURN、DERP</h2>有多种中继实现方式。<ol><li>TURN&nbsp;(Traversal Using Relays around NAT)：经典方式，核心理念是<ol><li>用户（人）先去公网上的 TURN 服务器认证，成功后后者会告诉你：“我已经为你分配了 ip:port，接下来将为你中继流量”，</li><li>然后将这个 ip:port 地址告诉对方，让它去连接这个地址，接下去就是非常简单的客户端/服务器通信模型了。</li></ol>Tailscale 并不使用 TURN。这种协议用起来并不是很好，而且与 STUN 不同， 它没有真正的交互性，因为互联网上并没有公开的 TURN 服务器。</li><li>DERP (Detoured Encrypted Routing Protocol)这是我们创建的一个协议，<a href="https://tailscale.com/blog/how-tailscale-works/#encrypted-tcp-relays-derp">DERP</a>，<ol><li>它是一个通用目的包中继协议，运行在 HTTP 之上，而大部分网络都是允许 HTTP 通信的。</li><li>它根据目的公钥（destination’s public key）来中继加密的流量（encrypted payloads）。</li></ol>前面也简单提到过，DERP 既是我们在 NAT 穿透失败时的保底通信方式（此时的角色 与 TURN 类似），也是在其他一些场景下帮助我们完成 NAT 穿透的旁路信道。 换句话说，它既是我们的保底方式，也是有更好的穿透链路时，帮助我们进行连接升 级（upgrade to a peer-to-peer connection）的基础设施。</li></ol><h2>6.3 小结</h2>有了“中继”这种保底方式之后，我们穿透的成功率大大增加了。 如果此时不再阅读本文接下来的内容，而是把上面介绍的穿透方式都实现了，我预计：<ul><li>90% 的情况下，你都能实现直连穿透；</li><li>剩下的 10% 里，用中继方式能穿透一些（some）；</li></ul>这已经算是一个“足够好”的穿透实现了。<h1>7 穿透 NAT+防火墙：企业级改进</h1>如果你并不满足于“足够好”，那我们可以做的事情还有很多！本节将介绍一些五花八门的 tricks，在某些特殊场景下会帮到我们。单独使用这项技术都 无法解决 NAT 穿透问题，但将它们巧妙地组合起来，我们能更加接近 100% 的穿透成功率。<h2>7.1 穿透 hard NAT：暴力端口扫描</h2>回忆 hard NAT 中遇到的问题，如下图所示，关键问题是：easy NAT 不知道该往 hard NAT 方的哪个&nbsp;<code>ip:port</code>&nbsp;发包。<img height="70%" src="https://arthurchiao.art/assets/img/nat-traversal/nat-birthday-attack-1.png" width="70%" />但必须要往正确的&nbsp;<code>ip:port</code>&nbsp;发包，才能穿透防火墙，实现双向互通。 怎么办呢？<ol><li>首先，我们能知道 hard NAT 的一些&nbsp;<code>ip:port</code>，因为我们有 STUN 服务器。这里先假设我们获得的这些 IP 地址都是正确的（这一点并不总是成立，但这里先这么假 设。而实际上，大部分情况下这一点都是成立的，如果对此有兴趣，可以参考 REQ-2 in&nbsp;<a href="https://tools.ietf.org/html/rfc4787">RFC 4787</a>）。</li><li>IP 地址确定了，剩下的就是端口了。总共有 65535 中可能，我们能遍历这个端口范围吗？如果发包速度是 100 packets/s，那最坏情况下，需要&nbsp;10 分钟来找到正确的端口。 还是那句话，这虽然不是最优的，但总比连不上好。这很像是端口扫描（事实上，确实是），实际中可能会触发对方的网络入侵检测软件。</li></ol><h2>7.2 基于生日悖论改进暴力扫描：hard side 多开端口 + easy side 随机探测</h2>利用&nbsp;<a href="https://en.wikipedia.org/wiki/Birthday_problem">birthday paradox</a>&nbsp;算法， 我们能对端口扫描进行改进。<ul><li>上一节的基本前提是：hard side 只打开一个端口，然后 easy side 暴力扫描 65535 个端口来寻找这个端口；</li><li>这里的改进是：在 hard size 开多个端口，例如 256 个（即同时打开 256 个 socket，目的地址都是 easy side 的&nbsp;<code>ip:port</code>）， 然后 easy side 随机探测这边的端口。</li></ul>这里省去算法的数学模型，如果你对实现干兴趣，可以看看我写的&nbsp;<a href="https://github.com/danderson/nat-birthday-paradox">python calculator</a>。 计算过程是“经典”生日悖论的一个小变种。 下面是随着 easy side random probe 次数（假设 hard size 256 个端口）的变化，两边打开的端口有重合（即通信成功）的概率：<table><thead><tr><th>随机探测次数</th><th>成功概率</th></tr></thead><tbody><tr><td>174</td><td>50%</td></tr><tr><td>256</td><td>64%</td></tr><tr><td>1024</td><td>98%</td></tr><tr><td>2048</td><td>99.9%</td></tr></tbody></table>根据以上结果，如果还是假设 100 ports/s 这样相当温和的探测速率，那&nbsp;2 秒钟就有约 50% 的成功概率。 即使非常不走运，我们仍然能在&nbsp;20s 时几乎 100% 穿透成功，而此时只探测了总端口空间的 4%。非常好！虽然这种 hard NAT 给我们带来了严重的穿透延迟，但最终结果仍然是成功的。 那么，如果是两个 hard NAT，我们还能处理吗？<h2>7.3 双 hard NAT 场景</h2><img height="70%" src="https://arthurchiao.art/assets/img/nat-traversal/nat-birthday-attack-2.png" width="70%" />这种情况下仍然可以用前面的&nbsp;多端口+随机探测&nbsp;方式，但成功概率要低很多了：<ul><li>每次通过一台 hard NAT 去探测对方的端口（目的端口）时，我们自己同时也生成了一个随机源端口，</li><li>这意味着我们的搜索空间变成了二维&nbsp;<code>{src port, dst port}</code>&nbsp;对，而不再是之前的一维 dst port 空间。</li></ul>这里我们也不就具体计算展开，只告诉结果：仍然假设目的端打开 256 个端口，从源端发起 2048 次（20 秒）， 成功的概率是：0.01%。如果你之前学过生日悖论，就并不会对这个结果感到惊讶。理论上来说，<ul><li>要达到&nbsp;99.9% 的成功率，我们需要两边各进行170,000 次探测 —— 如果还是以 100 packets/sec 的速度，就需要&nbsp;28 分钟。</li><li>要达到&nbsp;50% 的成功率，“只”需要 54,000 packets，也就是&nbsp;9 分钟。</li><li>如果不使用生日悖论方式，而且暴力穷举，需要 1.2 年时间！</li></ul>对于某些应用来说，28 分钟可能仍然是一个可接受的时间。用半个小时暴力穿透 NAT 之后， 这个连接就可以一直用着 —— 除非 NAT 设备重启，那样就需要再次花半个小时穿透建个新连接。但对于 交互式应用来说，这样显然是不可接受的。更糟糕的是，如果去看常见的办公网路由器，你会震惊于它的 active session low limit 有多么低。 例如，一台 Juniper SRX 300&nbsp;最多支持 64,000 active sessions。 也就是说，<ul><li>如果我们想创建一个成功的穿透连接，就会把它的整张 session 表打爆&nbsp;（因为我们要暴力探测 65535 个端口，每次探测都是一条新连接记录）！ 这显然要求这台路由器能从容优雅地处理过载的情况。</li><li>这只是创建一条连接带来的影响！如果 20 台机器同时对这台路由器发起穿透呢？绝对的灾难！</li></ul>至此，我们通过这种方式穿透了比之前更难一些的网络拓扑。这是一个很大的成就，因为&nbsp;家用路由器一般都是 easy NAT，hard NAT 一般都是办公网路由器或云 NAT 网关。 这意味着这种方式能帮我们解决<ul><li>home-to-office（家-&gt;办公室）</li><li>home-to-cloud （家-&gt;云）</li></ul>的场景，以及一部分<ul><li>office-to-cloud （办公室-&gt;云）</li><li>cloud-to-cloud （云-&gt;办公室）</li></ul>场景。<h2>7.4 控制端口映射（port mapping）过程：UPnP/NAT-PMP/PCP 协议</h2>如果我们能让 NAT 设备的行为简单点，不要把事情搞这么复杂，那建 立连接（穿透）就会简单很多。真有这样的好事吗？还真有，有专门的一种协议叫&nbsp;端口映射协议（port mapping protocols）。通过这种协议禁用掉前面 遇到的那些乱七八糟的东西之后，我们将得到一个非常简单的“请求-响应”。下面是三个具体的端口映射协议：<ol><li><a href="https://openconnectivity.org/developer/specifications/upnp-resources/upnp/internet-gateway-device-igd-v-2-0/">UPnP IGD</a>&nbsp;(Universal Plug’n’Play Internet Gateway Device)最老的端口控制协议， 诞生于 1990s 晚期，因此使用了很多上世纪 90 年代的技术 （XML、SOAP、multicast HTTP over UDP —— 对，HTTP over UDP&nbsp;），而且很难准确和安全地实现这个协议。但以前很多路由器都内置了 UPnP 协议， 现在仍然很多。请求和响应：<ul><li>“你好，请将我的&nbsp;<code>lan-ip:port</code>&nbsp;转发到公网（WAN）”，</li><li>“好的，我已经为你分配了一个公网映射&nbsp;<code>wan-ip:port</code>&nbsp;”。</li></ul></li><li>NAT-PMPUPnP IGD 出来几年之后，Apple 推出了一个功能类似的协议，名为&nbsp;<a href="https://tools.ietf.org/html/rfc6886">NAT-PMP</a>&nbsp;(NAT Port Mapping Protocol)。但与 UPnP 不同，这个协议只做端口转发，不管是在客户端还是服务端，实现起来都非常简单。</li><li>PCP稍后一点，又出现了 NAT-PMP v2 版，并起了个新名字<a href="https://tools.ietf.org/html/rfc6887">PCP</a>&nbsp;(Port Control Protocol)。</li></ol>因此要更好地实现穿透，可以<ol><li>先判断本地的默认网关上是否启用了 UPnP IGD, NAT-PMP and PCP，</li><li>如果探测发现其中任何一种协议有响应，我们就申请一个公网端口映射，可以将这理解为一个加强版 STUN：我们不仅能发现自己的公网&nbsp;<code>ip:port</code>，而且能指示我们的 NAT 设备对我们的通信对端友好一些 —— 但并不是为这个端口修改或添加防火墙规则。</li><li>接下来，任何到达我们 NAT 设备的、地址是我们申请的端口的包，都会被设备转发到我们。</li></ol>但我们不能假设这个协议一定可用：<ol><li>本地 NAT 设备可能不支持这个协议；</li><li>设备支持但默认禁用了，或者没人知道还有这么个功能，因此从来没开过；</li><li>安全策略要求关闭这个特性。这一点非常常见，因为 UPnP 协议曾曝出一些高危漏洞（后面都修复了，因此如果是较新的设备，可以安全地使用 UPnP —— 如果实现没问题）。 不幸的是，某些设备的配置中，UPnP, NAT-PMP，PCP 是放在一个开关里的（可能 统称为 “UPnP” 功能），一开全开，一关全关。因此如果有人担心 UPnP 的安全性，他连另 外两个也用不了。</li></ol>最后，终归来说，只要这种协议可用，就能有效地减少一次 NAT，大大方便建连过程。 但接下来看一些不常见的场景。<h2>7.5 多 NAT 协商（Negotiating numerous NATs）</h2>目前为止，我们看到的客户端和服务端都各只有一个 NAT 设备。如果有多个 NAT 设备会 怎么样？例如下面这种拓扑：<img height="70%" src="https://arthurchiao.art/assets/img/nat-traversal/nat-multiple-layers.png" width="70%" />这个例子比较简单，不会给穿透带来太大问题。包从客户端 A&nbsp;经过多次 NAT&nbsp;到达公网的过程，与前面分析的穿过多层有状态防火墙是一样的：<ul><li>额外的这层（NAT 设备）对客户端和服务端来说都不可见，我们的穿 透技术也不关心中间到底经过了多少层设备。</li><li>真正有影响的其实只是最后一层设备，因为对端需要在这一层设备上 找到入口让包进来。</li></ul>具体来说，真正有影响的是端口转发协议。<ol><li>客户端使用这种协议分配端口时，为我们分配端口的是最靠近客户端的这层 NAT 设备；</li><li>而我们期望的是让最离客户端最远的那层 NAT 来分配，否则我们得到的就是一个网络中间层分配的&nbsp;<code>ip:port</code>，对端是用不了的；</li><li>不幸的是，这几种协议都不能递归地告诉我们下一层 NAT 设备是多少 —— 虽然可以用 traceroute 之类的工具来探测网络路径，再加上 猜路上的设备是不是 NAT 设备（尝试发送 NAT 请求） —— 但这个就看运气了。</li></ol>这就是为什么互联网上充斥着大量的文章说&nbsp;double-NAT 有多糟糕，以 及警告用户为保持后向兼容不要使用 double-NAT。但实际上，double-NAT&nbsp;对于绝大部分 互联网应用来说都是不可见的（透明的），因为大部分应用并不需要主动地做这种 NAT 穿 透。但我也绝不是在建议你在自己的网络中设置 double-NAT。<ol><li>破坏了端口映射协议之后，某些视频游戏的多人（multiplayer）模式就会无法使用，</li><li>也可能会使你的 IPv6 网络无法派上用场，后者是不用 NAT 就能双向直连的一个好方案。</li></ol>但如果 double-NAT 并不是你能控制的，那除了不能用到这种端口映射协议之外，其他大部分东西都是不受影响的。double-NAT 的故事到这里就结束了吗？—— 并没有，而且更大型的 double-NAT 场景将展现在我们面前。<h2>7.6 运营商级 NAT 带来的问题</h2>即使用 NAT 来解决 IPv4 地址不够的问题，地址仍然是不够用的，ISP（互联网服务提供商） 显然 无法为每个家庭都分配一个公网 IP 地址。那怎么解决这个问题呢？ISP 的做法是不够了就再嵌套一层 NAT：<ol><li>家用路由器将你的客户端 SNAT 到一个 “intermediate” IP 然后发送到运营商网络，</li><li>ISP’s network 中的 NAT 设备再将这些 intermediate IPs 映射到少量的公网 IP。</li></ol>后面这种 NAT 就称为“运营商级 NAT”（carrier-grade NAT，或称电信级 NAT），缩写 CGNAT。如下图所示：<img height="70%" src="https://arthurchiao.art/assets/img/nat-traversal/nat-cgnat-1.png" width="70%" />CGNAT 对 NAT 穿透来说是一个大麻烦。<ul><li>在此之前，办公网用户要快速实现 NAT 穿透，只需在他们的路由器上手动设置端口映射就行了。</li><li>但有了 CGNAT 之后就不管用了，因为你无法控制运营商的 CGNAT！</li></ul>好消息是：这其实是 double-NAT 的一个小变种，因此前面介绍的解决方式大部分还仍然是适用的。 某些东西可能会无法按预期工作，但只要肯给 ISP 交钱，这些也都能解决。 除了 port mapping protocols，其他我们已经介绍的所有东西在 CGNAT 里都是适用的。<h3>新挑战：同一 CGNAT 侧直连，STUN 不可用</h3>但我们确实遇到了一个新挑战：如何直连两个在同一 CGNAT 但不同家用路由器中的对端呢？如下图所示：<img height="70%" src="https://arthurchiao.art/assets/img/nat-traversal/nat-cgnat-2.png" width="70%" />在这种情况下，STUN 就无法正常工作了：STUN 看到的是客户端在公网（CGNAT 后面）看到的地址， 而我们想获得的是在 “middle network” 中的&nbsp;<code>ip:port</code>，这才是对端真正需要的地址，<h3>解决方案：如果端口映射协议能用：一端做端口映射</h3>怎么办呢？如果你想到了端口映射协议，那恭喜，答对了！如果 peer 中任何一个 NAT 支持端口映射协议， 对我们就能实现穿透，因为它分配的&nbsp;<code>ip:port</code>&nbsp;正是对端所需要的信息。这里讽刺的是：double-NAT（指 CGNAT）破坏了端口映射协议，但在这里又救了我们！ 当然，我们假设这些协议一定可用，因为 CGNAT ISP 倾向于在它们的家用路由器侧关闭 这些功能，已避免软件得到“错误的”结果，产生混淆。<h3>解决方案：如果端口映射协议不能用：NAT hairpin 模式</h3>如果不走运，NAT 上没有端口映射功能怎么办？让我们回到基于 STUN 的技术，看会发生什么。两端在 CGNAT 的同一侧，假设 STUN 告诉我们 A 的地址是&nbsp;<code>2.2.2.2:1234</code>，B 的地址是&nbsp;<code>2.2.2.2:5678</code>。那么接下来的问题是：如果 A 向&nbsp;<code>2.2.2.2:5678</code>&nbsp;发包会怎么样？期望的 CGNAT 行为是：<ol><li>执行 A 的 NAT 映射规则，即对&nbsp;<code>2.2.2.2:1234 -&gt; 2.2.2.2:5678</code>&nbsp;进行 SNAT。</li><li>注意到目的地址&nbsp;<code>2.2.2.2:5678</code>&nbsp;匹配到的是 B 的入向 NAT 映射，因此接着对这个包执行 DNAT，将目的 IP 改成 B 的私有地址。</li><li>通过 CGNAT 的 internal 接口（而不是 public 接口，对应公网）将包发给 B。</li></ol>这种 NAT 行为有个专门的术语，叫&nbsp;hairpinning（直译为发卡，意思 是像发卡一样，沿着一边上去，然后从另一边绕回来），<img height="20%" src="https://arthurchiao.art/assets/img/nat-traversal/hairpin-icon.png" width="20%" />大家应该猜到的一个事实是：不是所以 NAT 都支持 hairpin 模式。 实际上，大量 well-behaved NAT 设备都不支持 hairpin 模式，<ul><li>因为它们都有&nbsp;“只有 src_ip 是私有地址且 dst_ip 是公网地址的包才会经过我”&nbsp;之类的假设。</li><li>因此对于这种目的地址不是公网、需要让路由器把包再转回内网的包，它们会直接丢弃。</li><li>这些逻辑甚至是直接实现在路由芯片中的，因此除非升级硬件，否则单靠软件编程无法改变这种行为。</li></ul>Hairpin 是所有 NAT 设备的特性（支持或不支持），并不是 CGNAT 独有的。<ol><li>在大部分情况下，这个特性对我们的 NAT 穿透目的来说都是无所谓的，因为我们期望中&nbsp;两个 LAN NAT 设备会直接通信，不会再向上绕到它们的默认网关 CGNAT 来解决这个问题。Hairpin 特性可有可无这件事有点遗憾，这可能也是为什么 hairpin 功能经常 broken 的原因。</li><li>一旦必须涉及到 CGNAT，那 hairpinning 对连接性来说就至关重要了。Hairpinning 使内网连接的行为与公网连接的行为完成一致，因此我们无需关心目的 地址类型，也不用知晓自己是否在一台 CGNAT 后面。</li></ol>如果 hairpinning 和 port mapping protocols 都不可用，那只能降级到中继模式了。<h2>7.7 全 IPv6 网络：理想之地，但并非问题全无</h2>行文至此，一些读者可能已经对着屏幕咆哮：不要再用 IPv4 了！&nbsp;花这么多时间精力解决这些没意义的东西，还不如直接换成 IPv6！<ul><li>的确，之所以有这些乱七八糟的东西，就是因为 IPv4 地址不够了，我们一直在用越来越复杂的 NAT 来给 IPv4 续命。</li><li>如果 IP 地址够用，无需 NAT 就能让世界上的每个设备都有一个自己的公网 IP 地址，这些问题不就解决了吗？</li></ul>简单来说，是的，这也正是 IPv6 能做的事情。但是，也只说对了一半：在理想的全 IPv6 世界中，所有这些东西会变得更加简单，但我们面临的问题并不会完全消失&nbsp;—— 因为有状态防火墙仍然还是存在的。<ul><li>办公室中的电脑可能有一个公网 IPv6 地址，但你们公司肯定会架设一个防火墙，只允许 你的电脑主动访问公网，而不允许反向主动建连。</li><li>其他设备上的防火墙也仍然存在，应用类似的规则。</li></ul>因此，我们仍然会用到<ol><li>本文最开始介绍的防火墙穿透技术，以及</li><li>帮助我们获取自己的公网&nbsp;<code>ip:port</code>&nbsp;信息的旁路信道</li><li>仍然需要在某些场景下 fallback 到中继模式，例如 fallback 到最通用的 HTTP 中继 协议，以绕过某些网络禁止 outbound UDP 的问题。</li></ol>但我们现在可以抛弃&nbsp;STUN、生日悖论、端口映射协议、hairpin&nbsp;等等东西了。 这是一个好消息！<h3>全球 IPv4/IPv6 部署现状</h3>另一个更加严峻的现实问题是：当前并不是一个全 IPv6 世界。目前世界上<ul><li>大部分还是 IPv4，</li><li><a href="https://www.google.com/intl/en/ipv6/statistics.html">大约 33% 是 IPv6</a>，而且分布极度不均匀，因此某些 通信对所在的可能是 100% IPv6，也可能是 0%，或二者之间。</li></ul>不幸的是，这意味着，IPv6 **还**无法作为我们的解决方案。 就目前来说，它只是我们的工具箱中的一个备选。对于某些 peer 来说，它简直是完美工 具，但对其他 peer 来说，它是用不了的。如果目标是“任何情况下都能穿透（连接） 成功”，那我们就仍然需要 IPv4+NAT 那些东西。<h3>新场景：NAT64/DNS64</h3>IPv4/IPv6 共存也引出了一个新的场景：NAT64 设备。<img height="70%" src="https://arthurchiao.art/assets/img/nat-traversal/nat-ipv6.png" width="70%" />前面介绍的都是 NAT44 设备：它们将一个 IPv4 地址转换成另一 IPv4 地址。 NAT64 从名字可以看出，是将一个内侧 IPv6 地址转换成一个外侧 IPv4 地址。 利用 DNS64 设备，我们能将 IPv4 DNS 应答给 IPv6 网络，这样对终端来说，它看到的就是一个 全 IPv6 网络，而仍然能访问 IPv4 公网。<blockquote>Incidentally, you can extend this naming scheme indefinitely. There have been some experiments with NAT46; you could deploy NAT66 if you enjoy chaos; and some RFCs use NAT444 for carrier-grade NAT.</blockquote>如果需要处理 DNS 问题，那这种方式工作良好。例如，如果连接到 google.com，将这个域名解析成 IP 地址的过程会涉及到 DNS64 设备，它又会进一步 involve NAT64 设备，但后一步对用户来说是无感知的。但对于 NAT 和防火墙穿透来说，我们会关心每个具体的 IP 地址和端口。<h3>解决方案：CLAT (Customer-side transLATor)</h3>如果设备支持 CLAT (Customer-side translator — from Customer XLAT)，那我们就很幸运：<ul><li>CLAT 假装操作系统有直接 IPv4 连接，而背后使用的是 NAT64，以对应用程序无感知。 在有 CLAT 的设备上，我们无需做任何特殊的事情。</li><li>CLAT&nbsp;在移动设备上非常常见，但在桌面电脑、笔记本和服务器上非常少见， 因此在后者上，必须自己做 CLAT 做的事情：检测 NAT64+DNS64 的存在，然后正确地使用它们。</li></ul><h3>解决方案：CLAT 不存在时，手动穿透 NAT64 设备</h3><ol><li>首先检测是否存在 NAT64+DNS64。方法很简单：向&nbsp;<code>ipv4only.arpa.</code>&nbsp;发送一个 DNS 请求。这个域名会解析 到一个已知的、固定的 IPv4 地址，而且是纯 IPv4 地址。如果得到的 是一个 IPv6 地址，就可以判断有 DNS64 服务器做了转换，而它必然会用到 NAT64。这样 就能判断出 NAT64 的前缀是多少。</li><li>此后，要向 IPv4 地址发包时，发送格式为<code>{NAT64 prefix + IPv4 address}</code>&nbsp;的 IPv6 包。 类似地，收到来源格式为&nbsp;<code>{NAT64 prefix + IPv4 address}</code>&nbsp;的包时，就是 IPv4 流量。</li><li>接下来，通过 NAT64 网络与 STUN 通信来获取自己在 NAT64 上的公网&nbsp;<code>ip:port</code>，接 下来就回到经典的 NAT 穿透问题了 —— 除了需要多做一点点事情。</li></ol>幸运的是，如今的大部分 v6-only 网络都是移动运营商网络，而几乎所有手机都支持 CLAT。 运营 v6-only 网络的 ISPs 会在他们给你的路由器上部署 CLAT，因此最后你其实不需要做什么事情。 但如果想实现 100% 穿透，就需要解决这种边边角角的问题，即必须显式支持从 v6-only 网络连接 v4-only 对端。<h2>7.8 将所有解决方式集成到 ICE 协议</h2><h3>针对具体场景，该选择哪种穿透方式？</h3>至此，我们的 NAT 穿透之旅终于快结束了。我们已经覆盖了有状态防火墙、简单和高级 NAT、IPv4 和 IPv6。只要将以上解决方式都实现了，NAT 穿透的目的就达到了！但是，<ul><li>对于给定的 peer，如何判断改用哪种方式呢？</li><li>如何判断这是一个简单有状态防火墙的场景，还是该用到生日悖论算法，还是需要手动处理 NAT64 呢？</li><li>还是通信双方在一个 WiFi 网络下，连防火墙都没有，因此不需要任何操作呢？</li></ul>早期 NAT 穿透比较简单，能让我们精确判断出 peer 之间的路径特点，然后针对性地采用相应的解决方式。 但后面，网络工程师和 NAT 设备开发工程师引入了一些新理念，给路径判断造成很大困难。因此 我们需要简化客户端侧的思考（判断逻辑）。这就要提到 Interactive Connectivity Establishment (ICE，交换式连接建立) 协议了。 与 STUN/TURN 类似，ICE 来自电信领域，因此其 RFC 充满了 SIP、SDP、信令会话、拨号等等电话术语。 但如果忽略这些领域术语，我们会看到它描述了一个极其优雅的判断最佳连接路径的算法。真的？这个算法是：每种方法都试一遍，然后选择最佳的那个方法。就是这个算法，惊喜吗？来更深入地看一下这个算法。<h3>ICE (Interactive Connectivity Establishment) 算法</h3>这里的讨论不会严格遵循 ICE spec，因此如果是在自己实现一个可互操作的 ICE 客户端，应该通读<a href="https://tools.ietf.org/html/rfc8445">RFC 8445</a>, 根据它的描述来实现。这里忽略所有电信术语，只关注核心的算法逻辑， 并提供几个在 ICE 规范允许范围的灵活建议。<ol><li>为实现和某个 peer 的通信，首先需要确定我们自己用的（客户端侧）这个 socket 的地址， 这是一个列表，至少应该包括：<ol><li>我们自己的 IPv6&nbsp;<code>ip:ports</code></li><li>我们自己的 IPv4 LAN&nbsp;<code>ip:ports</code>（局域网地址）</li><li>通过 STUN 服务器获取到的我们自己的 IPv4 WAN&nbsp;<code>ip:ports</code>（公网地址，可能会经过 NAT64 转换）</li><li>通过端口映射协议获取到的我们自己的 IPv4 WAN&nbsp;<code>ip:port</code>（NAT 设备的端口映射协议分配的公网地址）</li><li>运营商提供给我们的 endpoints（例如，静态配置的端口转发）</li></ol></li><li>通过旁路信道与 peer 互换这个列表。两边都拿到对方的列表后，就开始互相探测对方提供的地址。&nbsp;列表中地址没有优先级，也就是说，如果对方给的了 15 个地址，那我们应该把这 15 个地址都探测一遍。这些探测包有两个目的：<ol><li>打开防火墙，穿透 NAT，也就是本文一直在介绍的内容；</li><li>健康检测。我们在不断交换（最好是已认证的）“ping/pong” 包，来检测某个特定的路径是不是端到端通的。</li></ol></li><li>最后，一小会儿之后，从可用的备选地址中（根据某些条件）选择“最佳”的那个，任务完成！</li></ol>这个算法的优美之处在于：只要选择最佳线路（地址）的算法是正确的，那就总能获得最佳路径。<ul><li>ICE 会预先对这些备选地址进行排序（通常：LAN &gt; WAN &gt; WAN+NAT），但用户也可以自己指定这个排序行为。</li><li>从 v0.100.0 开始，Tailscale 从原来的 hardcode 优先级切换成了根据 round-trip latency 的方式，它大部分情况下排序的结果和&nbsp;<code>LAN &gt; WAN &gt; WAN+NAT</code>&nbsp;是一致的。 但相比于静态排序，我们是动态计算每条路径应该属于哪个类别。</li></ul>ICE spec 将协议组织为两个阶段：<ol><li>探测阶段</li><li>通信阶段</li></ol>但不一定要严格遵循这两个步骤的顺序。在 Tailscale，<ul><li>我们发现更优的路径之后就会自动切换过去，</li><li>所有的连接都是先选择 DERP 模式（中继模式）。这意味着连接立即就能建立（优先级最低但 100% 能成功的模式），用户不用任何等待，</li><li>然后并行进行路径发现。通常几秒钟之后，我们就能发现一条更优路径，然后将现有连接透明升级（upgrade）过去。</li></ul>但有一点需要关心：非对称路径。ICE 花了一些精力来保证通信双方选择的是相同的网络 路径，这样才能保证这条路径上有双向流量，能保持防火墙和 NAT 设备的连接一直处于 open 状态。 自己实现的话，其实并不需要花同样大的精力来实现这个保证，但需要确保你所有使用的所有路径上，都有双向流量。 这个目标就很简单了，只需要定期在所有已使用的路径上发 ping/pong 就行了。<h3>健壮性与降级</h3>要实现健壮性，还需要检测当前已选择的路径是否已经失败了（例如，NAT 设备维护清掉了所有状态）， 如果失败了就要降级（downgrade）到其他路径。这里有两种方式：<ol><li>持续探测所有路径，维护一个降级时会用的备用地址列表；</li><li>直接降级到保底的中继模式，然后再通过路径探测升级到更好的路径。考虑到发生降级的概率是非常小的，因此这种方式可能是更经济的。</li></ol><h2>7.9 安全</h2>最后需要提到安全。本文的所有内容都假设：我们使用的上层协议已经有了自己的安全机制（ 例如 QUIC 协议有 TLS 证书，WireGuard 协议有自己的公钥）。 如果还没有安全机制，那显然是要立即补上的。一旦动态切换路径，基于 IP 的安全机制就是无用的了&nbsp;（IP 协议最开始就没怎么考虑安全性），至少要有端到端的认证。<ul><li>严格来说，如果上层协议有安全机制，那即使收到是欺骗性的 ping/pong 流量，问题都不大， 最坏的情况也就是攻击者诱导两端通过他们的系统来中继流量。 而有了端到端安全机制，这并不是一个大问题（取决于你的威胁模型）。</li><li>但出于谨慎考虑，最好还是对路径发现的包也做认证和加密。具体如何做可以咨询你们的应用安全工程师。</li></ul><h1>8 结束语</h1>我们终于完成了 NAT 穿透的目标！如果实现了以上提到的所有技术，你将得到一个业内领先的 NAT 穿透软件，能在绝大多数场景下实现端到端直连。 如果直连不了，还可以降级到保底的中继模式（对于长尾来说只能靠中继了）。但这些工作相当复杂！其中一些问题研究起来很有意思，但很难做到完全正确，尤其是那些 非常边边角角的场景，真正出现的概率极小，但解决它们所需花费的经历又极大。 不过，这种工作只需要做一次，一旦解决了，你就具备了某种超级能力： 探索令人激动的、相对还比较崭新的端到端应用（peer-to-peer applications）世界。<h2>8.1 跨公网 端到端直连</h2>去中心化软件领域中的许多有趣想法，简化之后其实都变成了&nbsp;跨过公网（互联网）实现端到端直连&nbsp;这一问题，开始时可能觉得很简单，但真正做才 发现比想象中难多了。现在知道如何解决这个问题了，动手开做吧！<h2>8.2 结束语之 TL; DR</h2>实现健壮的 NAT 穿透需要下列基础：<ol><li>一种基于 UDP 的协议；</li><li>能在程序内直接访问 socket；</li><li>有一个与 peer 通信的旁路信道；</li><li>若干 STUN 服务器；</li><li>一个保底用的中继网络（可选，但强烈推荐）</li></ol>然后需要：<ol><li>遍历所有的&nbsp;<code>ip:port</code>；</li><li>查询 STUN 服务器来获取自己的公网&nbsp;<code>ip:port</code>&nbsp;信息，以及判断自己这一侧的 NAT 的“难度”（difficulty）；</li><li>使用 port mapping 协议来获取更多的公网&nbsp;<code>ip:ports</code>；</li><li>检查 NAT64，通过它获取自己的公网&nbsp;<code>ip:port</code>；</li><li>将自己的所有公网&nbsp;<code>ip:ports</code>&nbsp;信息通过旁路信道与 peer 交换，以及某些加密秘钥来保证通信安全；</li><li>通过保底的中继方式与对方开始通信（可选，这样连接能快速建立）</li><li>如果有必要/想这么做，探测对方的提供的所有&nbsp;<code>ip:port</code>，以及执行生日攻击（birthday attacks）来穿透 harder NAT；</li><li>发现更优路径之后，透明升级到该路径；</li><li>如果当前路径断了，降级到其他可用的路径；</li><li>确保所有东西都是加密的，并且有端到端认证。</li></ol>译文：https://arthurchiao.art/blog/how-nat-traversal-works-zh/原文：https://tailscale.com/blog/how-nat-traversal-works/

1 引言 1.1 背景：IPv4 地址短缺，引入 NAT 全球 IPv4 地址早已不够用，因此人们发明了 NAT（网络地址转换）来缓解这个问题。简单来说，大部分机器都使用 私有 IP 地址 ，如果它们需要访问公网服务，那么，出向流量：需要经过一台 NAT 设备，它会对流量进行 SNAT，将私有 srcIP+Port 转换成 NAT 设备的公网 IP+Port（这样应答包才能回来），然后再将包发出去；应答流量（入向）：到达 NAT 设备后进行相反的转换，然后再转发给客户端。整个过程对双方透明。更多关于 NAT 的内容，可参考 (译) NAT - 网络地址转换（2016）。译注。以上是本文所讨论问题的 …

发表评论

阅读全文

更多博文

搜索此博客

三思屋

博文

Win11家庭版无需重装，通过更换Key升级到专业版(Windows 11)

常用的国内外延迟测速链接（generate_204）

Serv00进入伪root模式的方法

如何快速手工测试VPS上行和下行速度

解决Ubuntu桌面上Free Download Manager无法打开的问题

使用 Nginx 状态码 444 提升 HTTPS 服务安全性，屏蔽 HTTP 497 访问提示

Fake Login - 在Linux(Debian)中显示虚假的Windows登录屏幕

Debian 12上使用Nginx代理TCP流量，并配置IPv6白名单访问控制

使用AdGuard的公共dns屏蔽广告

利用cgroup对docker进行全局资源限制(CPU, 内存, IO读写等限制)

Linux下加密虚拟分区并挂载文件夹使用

腾讯云国内服务器重装系统并设置内网源镜像，docker内网加速镜像等

IPV6服务器通过warp获得IPV4网络的步骤

VPS线路详解：包括163、CN2 GT、CN2 GIA、AS4837、AS9929、CMI/CMIN2线路

解决部分网站禁止复制内容的js脚本（无需安装插件）

生成100年自签ssl证书（https证书）的命令

某运营商云电脑重装Debian 12

Docker下安装ubuntu使用浏览器远程办公开发

Cloudflare防火墙安全配置WAF（防CC）

NAT 穿透是如何工作的：技术原理及企业级实践

Popular Posts

随身WiFi折腾指南: 解锁、刷机与DIY

mihomo各平台客户端下载(windows, android, macos)

Cromite - 极度注重隐私的Chromium浏览器

ungoogled-chromium浏览器各平台版本下载(windows, android, macos, linux)

git推送拉取时对服务器进行【袋里】加速

《活法》作者：[日]稻盛和夫 pdf下载

Sublime3 3211 - 跨平台文本编辑器开发工具

中国民谣殿堂级乐队野孩子20周年「黄河谣」音乐会

《精益创业》[美] 埃里克·莱斯

Microsoft 365安装包下载（Office桌面应用）