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` 文件夹下的日志，定位错误原因。