From a86d84d38404570167cbedd9db57813a76d95a5d Mon Sep 17 00:00:00 2001 From: Dnomd343 Date: Wed, 29 Mar 2023 16:00:30 +0800 Subject: [PATCH] docs: update tutorial format --- docs/campus_network_cracking.md | 45 ++++++++++++++++---------------- docs/dual_stack_network_proxy.md | 30 ++++++++++----------- 2 files changed, 37 insertions(+), 38 deletions(-) diff --git a/docs/campus_network_cracking.md b/docs/campus_network_cracking.md index 1788d41..4a04312 100644 --- a/docs/campus_network_cracking.md +++ b/docs/campus_network_cracking.md @@ -8,13 +8,13 @@ 为了方便讲解,我们假设以下典型情况: -+ 校园网交换机无 IPv6 支持,同时存在 QoS ++ 校园网交换机无 IPv6 支持,同时存在 QoS; -+ 无认证时允许 53 端口通行,ICMP 流量无法通过 ++ 无认证时允许 53 端口通行,ICMP 流量无法通过; -+ 使用三台公网服务器负载均衡,其 53 端口上运行有代理服务 ++ 使用三台公网服务器负载均衡,其 53 端口上运行有代理服务; -+ 三台服务器只有一台支持 IPv4 与 IPv6 双栈,其余只支持 IPv4 ++ 三台服务器只有一台支持 IPv4 与 IPv6 双栈,其余只支持 IPv4; ## 代理协议 @@ -26,15 +26,15 @@ ## 初始化配置 -> 分配 `192.168.2.0/24` 和 `fc00::/64` 给内网使用 +> 分配 `192.168.2.0/24` 和 `fc00::/64` 给内网使用。 -路由器 WAN 口接入学校交换机,构建一个 NAT 转换,代理流量在路由器转发后送到公网服务器的 53 端口上;假设内网中路由器地址为 `192.168.2.1` ,配置虚拟网关 IPv4 地址为 `192.168.2.2` ,IPv6 地址为 `fc00::2` ;在网关中,无论 IPv4 还是 IPv6 流量都会被透明代理,由于校园网无 IPv6 支持,数据被封装后只通过 IPv4 网络发送,代理服务器接收以后再将其解开,对于 IPv6 流量,这里相当于一个 6to4 隧道。 +路由器 WAN 口接入学校交换机,构建一个 NAT 转换,代理流量在路由器转发后送到公网服务器的 53 端口上;假设内网中路由器地址为 `192.168.2.1` ,配置虚拟网关 IPv4 地址为 `192.168.2.2` ,IPv6 地址为 `fc00::2` ;在网关中,无论 IPv4 还是 IPv6 流量都会被透明代理,由于校园网无 IPv6 支持,数据被封装后只通过 IPv4 网络发送,代理服务器接收以后再将其解开,对于 IPv6 流量,这里相当于一个 `6to4` 隧道。 -``` +```bash # 宿主机网卡假定为 eth0 -shell> ip link set eth0 promisc on -shell> modprobe ip6table_filter -shell> docker network create -d macvlan \ +$ ip link set eth0 promisc on +$ modprobe ip6table_filter +$ docker network create -d macvlan \ --subnet=192.168.2.0/24 \ # 此处指定的参数为容器的默认网络配置 --gateway=192.168.2.1 \ --subnet=fc00::/64 \ @@ -44,8 +44,8 @@ shell> docker network create -d macvlan \ 我们将配置文件保存在 `/etc/scutweb` 目录下,使用以下命令开启 XProxy 服务: -``` -shell> docker run --restart always \ +```bash +docker run --restart always \ --privileged --network macvlan -dt \ --name scutweb --hostname scutweb \ --volume /etc/scutweb/:/xproxy/ \ @@ -110,7 +110,7 @@ custom: 在开始代理前,我们使用 `custom` 注入了一段脚本配置:由于这里我们只代理 TCP 与 UDP 流量,ICMP 数据包不走代理,内网设备 ping 外网时会一直无响应,加入这段脚本可以创建一个 NAT,假冒远程主机返回成功回复,但实际上 ICMP 数据包并未实际到达,效果上表现为 ping 成功且延迟为内网访问时间。 -> 这段脚本并无实质作用,只是演示 `custom` 功能 +> 这段脚本并无实质作用,仅用于演示 `custom` 功能。 ## 代理配置 @@ -184,15 +184,15 @@ custom: 重启 XProxy 容器使配置生效: -``` -shell> docker restart scutweb +```bash +docker restart scutweb ``` 最后,验证代理服务是否正常工作,若出现问题可以查看 `/etc/scutweb/log` 文件夹下的日志,定位错误原因。 ## 代理 ICMP 流量 -> 这一步仅用于修复 ICMP 代理,无此需求可以忽略 +> 这一步仅用于修复 ICMP 代理,无此需求可以忽略。 由于 socks5 代理服务不支持 ICMP 协议,当前搭建的网络只有 TCP 与 UDP 发往外网,即使在上文我们注入了一段命令用于劫持 PING 流量,但是返回的仅仅是虚假结果,并没有实际意义;所以如果对这个缺陷不满,您可以考虑使用以下方法修复这个问题。 @@ -235,23 +235,22 @@ with open(os.path.join(workDir, 'setup'), 'w') as script: os.system('chmod +x %s' % os.path.join(workDir, 'setup')) ``` -``` +```bash # fetch.py 为上述脚本 - -shell> cd /etc/scutweb -shell> mkdir -p ./toolset && cd ./toolset -shell> python3 fetch.py wireguard-tools # 拉取wireguard-tools依赖 +$ cd /etc/scutweb +$ mkdir -p ./toolset && cd ./toolset +$ python3 fetch.py wireguard-tools # 拉取wireguard-tools依赖 ··· ··· ``` -拉取成功后将生成 `wireguard-tools` 文件夹,包含多个依赖的 `.apk` 安装包与 `setup` 安装脚本 +拉取成功后将生成 `wireguard-tools` 文件夹,包含多个依赖的 `.apk` 安装包与 `setup` 安装脚本。 ### 2. 写入 WireGuard 配置文件 一个典型的客户端配置文件如下: -``` +```ini [Interface] PrivateKey = 客户端私钥 diff --git a/docs/dual_stack_network_proxy.md b/docs/dual_stack_network_proxy.md index dbb54a6..93e8487 100644 --- a/docs/dual_stack_network_proxy.md +++ b/docs/dual_stack_network_proxy.md @@ -1,4 +1,4 @@ -## 家庭网络的 IPv4 与 IPv6 透明代理 +# 家庭网络的 IPv4 与 IPv6 透明代理 家庭网络光纤入网,支持 IPv4 与 IPv6 网络,需要在内网搭建透明代理,让设备的国内流量直连,出境流量转发到代理服务器上,避开 GFW 的流量审查。 @@ -12,15 +12,15 @@ 大多数地区的运营商不会提供 IPv4 公网地址,IPv6 分配一般为 64 位长度的公网网段;虚拟网关在这里需要收集内网的所有 IPv4 与 IPv6 流量,将国内流量直接送出,国外流量发往代理服务器;为了增加难度,我们假设有两台境外代理服务器,一台支持IPv6,一台只支持IPv4,我们需要将IPv6代理流量发送给前者,其余代理流量送往后者。 -### 分流规则 +## 分流规则 -代理内核需要区分出哪些流量可以直连,哪些流量需要送往代理服务器,为了更准确地分流,这里需要开启嗅探功能,获取访问的域名信息,同时允许流量重定向(目标地址修改为域名,送至代理服务器解析,避开 DNS 污染); +代理内核需要区分出哪些流量可以直连,哪些流量需要送往代理服务器,为了更准确地分流,这里需要开启嗅探功能,获取访问的域名信息,同时允许流量重定向(目标地址修改为域名,送至代理服务器解析,避开 DNS 污染)。 目前路由资源中包含了一份国内常见域名列表(即 `geosite.dat` ,XProxy 已集成),如果嗅探后的域名在其中,那可以直接判定为直连流量,但是对于其他流量,即使它不在列表内,但仍可能是国内服务,我们不能直接将它送往代理服务器;因此下一步我们需要引出分流的核心规则,它取决于 DNS 污染的一个特性:受污染的域名返回解析必然为境外 IP ,基于这个原则,我们将嗅探到的域名使用国内 DNS 进行一次解析,如果结果是国内 IP 地址,那就直连该流量,否则发往代理服务器,IPv4 与 IPv6 均使用该逻辑分流。 如果有可能的话,您可以在内网搭建一个无污染的解析服务,比如 [ClearDNS](https://github.com/dnomd343/ClearDNS),它的作用在于消除 DNS 污染,准确地给出国内外的解析地址,这样子可以在分流时就不用多做一次 DNS 解析,减少这一步导致的延迟(DNS 流量通过代理送出,远程解析以后再返回,其耗时较长且不稳定),无污染 DNS 可以更快更准确地进行分流。 -### 网络配置 +## 网络配置 网络地址方面,内网 IPv4 段由我们自己决定,这一部分取决于路由器设置的 LAN 侧 IP 段,我们假设为 `192.168.2.0/24` ,其中路由器地址为 `192.168.2.1` ,虚拟网关分配为 `192.168.2.2` ,由于 IPv4 部分由路由器 NAT 隔离,这里不需要修改光猫配置;虚拟网关上游配置为路由器地址,修改内网 DHCP 服务,让网关指向 `192.168.2.2` 。 @@ -40,22 +40,22 @@ IPv6部分,由于路由器桥接,地址分配等操作均为光猫负责, 这是 IPv6 在代理方面的缺点,它将发送 RA 广播的链路地址直接视为路由网关,且该地址无法通过其他协议更改,我们没法像 DHCPv4 一样直接配置网关地址,这在透明代理时远没有 IPv4 方便,只能将 RA 广播源放在网关上。 -### 启动服务 +## 启动服务 首先创建 macvlan 网络: -``` +```bash # 宿主机网卡假定为 eth0 -shell> ip link set eth0 promisc on -shell> modprobe ip6table_filter +$ ip link set eth0 promisc on +$ modprobe ip6table_filter # IPv6网段后续由XProxy更改,这里可以随意指定 -shell> docker network create -d macvlan --subnet=fe80::/10 --ipv6 -o parent=eth0 macvlan +$ docker network create -d macvlan --subnet=fe80::/10 --ipv6 -o parent=eth0 macvlan ``` 将配置文件保存在 `/etc/route` 目录下,使用以下命令开启 XProxy 服务: -``` -shell> docker run --restart always \ +```bash +docker run --restart always \ --privileged --network macvlan -dt \ --name route --hostname route \ --volume /etc/route/:/xproxy/ \ @@ -64,7 +64,7 @@ shell> docker run --restart always \ dnomd343/xproxy:latest ``` -### 参数配置 +## 参数配置 在设计上,应该配置四个出口,分别为 IPv4 直连、IPv4 代理、IPv6 直连、IPv6 代理,这里创建 4 个对应的 socks5 接口 `direct4` 、`proxy4` 、`direct6` 、`proxy6` ,用于检测对应出口是否正常工作。 @@ -121,7 +121,7 @@ asset: geosite.dat: "https://github.com/Loyalsoldier/v2ray-rules-dat/releases/latest/download/geosite.dat" ``` -### 代理配置 +## 代理配置 配置出站代理,修改 `config/outbounds.json` 文件,其中 direct 直连到国内网络,proxy 填入代理服务器参数: @@ -228,8 +228,8 @@ asset: 重启 XProxy 容器使配置生效: -``` -shell> docker restart route +```bash +docker restart route ``` 最后,验证代理服务是否正常工作,若出现问题可以查看 `/etc/route/log` 文件夹下的日志,定位错误原因。