docs: update tutorial format

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 = 客户端私钥
 

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