实验环境

我使用的是 Ubuntu 24.04.4，基本环境配置见ARP攻击原理学习

网络结构如下：

启动实验前先清理容器环境，防止被之前的网络配置干扰

1
2

sudo docker stop $(sudo docker ps -q) 2>/dev/null
sudo docker system prune -f

进入实验目录并启动

1
2

cd seed-labs/category-network/Firewall_Evasion/Labsetup
sudo docker compose up -d

验证容器状态

1

sudo docker ps

基础网络测试

实验开始前，首先确认从A1到B1，和从A1到B2容器的网络连通性

1
2

sudo docker exec A1-10.8.0.5 ping -c 3 192.168.20.5
sudo docker exec A1-10.8.0.5 ping -c 3 192.168.20.6

查看中间路由器的路由表，这里可以看到它有两个网卡，eth0连接 A 区网段10.8.0.0/24，自己的地址是 10.8.0.11，eth1连接 B 区网段192.168.20.0/24，自己的地址是 192.168.20.11。说明这个路由器就是两个区域通信的中转

1

sudo docker exec router-firewall ip route show

进入防火墙容器，查看默认的 iptables 规则

1
2
3
4
5

sudo docker exec -it router-firewall /bin/bash
# 查看完整的 filter 表
iptables -L -v -n
# 只看 FORWARD 链
iptables -L FORWARD -v -n

这部分规则模拟的就是一个简易的公司内网防火墙环境，类比到真实情况，A 就是防火墙外侧网络，可以作为外部访问者或者代理服务器，B 就是受保护的内网。这里重点是看FORWARD链，也就是路由器转发包的规则，默认策略是 ACCEPT

从 A 区方向进来的 TCP 流量中，已经建立的连接和SSH流量，也就是目标端口是22的流量可以通过，其他普通 TCP 会被丢弃，这样 A 区主机如果直接访问 B 区的 Telnet、HTTP 这类普通 TCP 服务，就会被防火墙阻断

从 B 区方向进来的所有流量中，目标是93.184.216.0/24的流量会被丢弃，这个 IP 在之后的实验中对应的是www.example.com，这就体现了 B 区主机访问某个网站被防火墙阻断的情况

静态端口转发

通过建立 SSH 静态隧道，把对本地端口的访问转发到远程内网的特定服务上。这里把 A 区网关的 8000 端口映射到 192.168.20.5:23，从而让 A 区主机穿透防火墙，访问 B 区被保护的 Telnet 服务

新开一个终端窗口，进入 A 区网关容器

1

sudo docker exec -it A-10.8.0.99 /bin/bash

在 A 区网关上建立 SSH 隧道，目的是将10.8.0.99:8000映射到192.168.20.5:23。执行命令后终端会持续运行来维持 SSH 隧道

1

ssh -4NT -L 0.0.0.0:8000:192.168.20.5:23 seed@192.168.20.99

• -L：启用本地端口转发

• 0.0.0.0:8000：让 A 区网关上的 SSH 客户端监听所有网卡上的 8000 端口

• 192.168.20.5:23：如果监听到8000端口的连接，就通过 SSH 隧道转发给 B 区网关，B 区网关再连接 B1 的 Telnet 服务

• seed@192.168.20.99：SSH 连接到 B 区网关

• -N：不执行远程命令，只做端口转发

• -T：不分配伪终端

新开一个终端进入 A1 容器，通过 A 区网关的 8000 端口连接 B1 的 Telnet 服务

1
2

sudo docker exec -it A1-10.8.0.5 /bin/bash
telnet 10.8.0.99 8000

输入用户和密码登录后，输入下面的命令

1

ip -br a

可以看到已经成功登录到了 192.168.20.5的终端

为了观察防火墙视角下的数据包，可以在路由器容器中抓包

1

tcpdump -n -i any

防火墙主要能看到 10.8.0.99 到 192.168.20.99:22 的 SSH 流量，真正的 Telnet 数据被包在 SSH 加密连接内部，防火墙看不到里面访问的是 192.168.20.5:23，这就是静态端口转发可以绕过防火墙限制的原因

动态 SOCKS 代理

静态端口转发每次只能绑定一个固定目标，而动态端口转发会在本地启动一个 SOCKS 代理，仅指定代理出入口，但访问目标不写死在 SSH 命令里，由 SOCKS 代理命令来传输。因此能让 B 区主机通过 A 区网关作为出口，来访问原本被防火墙拦截的网站

SOCKS 代理在应用层，处理的是应用发起的具体访问请求

新开一个终端窗口，进入 B 区网关容器

1

sudo docker exec -it B-192.168.20.99 /bin/bash

在 B 区网关上建立动态代理隧道，目的是通过 SSH 隧道把请求发到 A 区网关，再让 A 区网关去访问目标。执行命令后终端会持续运行来维持 SSH 隧道

1

ssh -4NT -D 0.0.0.0:9000 seed@10.8.0.99

• -D：启用动态端口转发，也就是创建 SOCKS 代理

• 0.0.0.0:9000：让 B 区网关上的 SSH 客户端监听所有网卡上的 9000 端口

• seed@10.8.0.99：SSH 连接到 A 区网关

进入 B1 容器，修改本地映射，将域名与被防火墙封锁的网段绑定

1
2

sudo docker exec -it B1-192.168.20.5 /bin/bash
echo "93.184.216.34 www.example.com" >> /etc/hosts

直接访问目标网站，可以发现没有反应，说明无法访问

1

curl www.example.com

用 SOCKS5 代理访问网站，这次可以成功拿到网页 HTML 内容。这是因为 B1 会把请求交给 B 区网关的 SOCKS 代理，也就是192.168.20.99:9000，代理再通过 SSH 隧道把请求发给 A 区网关来访问外部网站

这里使用的是 socks5h， h 表示域名解析交给代理端完成。因此 B1 在/etc/hosts 中对 www.example.com 的映射主要用来直接访问触发防火墙阻断，而通过 SOCKS 代理访问时，域名可能被代理出口重新解析

1

curl --proxy socks5h://192.168.20.99:9000 www.example.com

浏览器也是类似的流程，首先在 Firefox 浏览器中如图配置代理

访问www.example.com，可以发现页面成功加载了

关闭SSH隧道，再次访问就发现代理服务器拒绝连接，这和真实网络中的代理是类似的

3 层 VPN 隧道

这部分更接近真正 VPN 的工作方式，它会创建一个虚拟网卡 tun0，然后把数据包放进 SSH 隧道中传输。3层指的是网络层，记录了源IP、目标IP

开始这个部分前，先重启实验容器，清理之前的隧道和路由配置来防止干扰

1
2

sudo docker compose down
sudo docker compose up -d

A区访问B区

这里先在防火墙上添加规则，禁止 A 区网段直接访问 B 区网段。这个规则是添加在最后的，用于处理不匹配前面几个规则的流量

1
2

sudo docker exec -it router-firewall /bin/bash
iptables -A FORWARD -s 10.8.0.0/24 -d 192.168.20.0/24 -j DROP

此时从 A 区网关 ping B1 会失败

1

sudo docker exec -it A-10.8.0.99 ping 192.168.20.5

为了成功访问，A 网关不再把包直接发向 B 区，而是建立 SSH 连接。但由于SSH只是一个通信协议，不参与流量的规划，因此还要在 A 区网关和 B 区网关创建虚拟网卡 tun0，作用是分离需要代理的流量。这样只需要把访问 B 区网段的流量引到 tun0，这些数据包就会被 SSH 封装后发到 B 区网关

进入 A 区网关容器，用 SSH 的 -w 参数建立三层 VPN 隧道。执行命令后终端会持续运行来维持 VPN 隧道

1
2
3
4
5

sudo docker exec -it A-10.8.0.99 /bin/bash
ssh -w 0:0 root@192.168.20.99 \
    -o "PermitLocalCommand=yes" \
    -o "LocalCommand= ip addr add 192.168.53.88/24 dev tun0 && ip link set tun0 up" \
    -o "RemoteCommand=ip addr add 192.168.53.99/24 dev tun0 && ip link set tun0 up"

• -w 0:0：启用 SSH 的三层隧道功能，在 A 区和 B 区网关分别创建 tun0 虚拟网卡
• root@192.168.20.99：SSH 连接到 B 区网关，也就是 VPN 隧道出口
• PermitLocalCommand=yes：允许 SSH 连接建立后在本地自动执行命令
• LocalCommand=...：在 A 区网关上配置 tun0，分配 192.168.53.88/24并启动网卡
• RemoteCommand=...：在 B 区网关上配置 tun0，分配 192.168.53.99/24并启动网卡

上一步只是搭建了传输的基础，但还没有对流量进行规划。这一步需要配置路由，给访问流量和回程流量添加规则

进入 A 区网关配置路由。为了避免 SSH 隧道自己的连接进入 tun0，先给 B 区网关加一条单独的规则来让它走原来的路径，再把访问 B 区网段的流量引入 tun0

1
2
3
4
5

sudo docker exec -it A-10.8.0.99 /bin/bash
# 访问192.168.20.99的流量走原来的中间路由器
ip route add 192.168.20.99/32 via 10.8.0.11
# 访问所有192.168.20.0网段的流量走虚拟网卡
ip route replace 192.168.20.0/24 dev tun0

还需要给 B1 配置回程路由，将目标是 192.168.53.0/24 的回包交给 B 区网关

1

sudo docker exec -it B1-192.168.20.5 ip route add 192.168.53.0/24 via 192.168.20.99

回到 A 区网关再次 ping B1，此时数据包先进入 tun0，再被封装进 SSH 连接中，防火墙看到的外层还是 SSH，不会进行拦截，因此成功发送了数据包

1

ping 192.168.20.5

B区访问外部

注意：实验中的www.example.com通过CDN解析，域名解析出的IP经常会变化，变化一次就会导致之前的一大串配置全部失效，需要修改IP后重新执行。这个方案稳定性极低，但也是无奈之举，更好的实验流程是将访问目标设置为自己有公网IP的服务器

开始这个部分前，重启容器来清理路由

1
2

sudo docker compose down
sudo docker compose up -d

首先在A网关尝试访问目标网站，输出中可以看到www.example.com被映射到了104.20.23.154。这个IP经常变化，因此虽然在VPN转发流程中A区网关并不参与DNS解析，还是需要执行下面的命令来找到有效的IP

1

sudo docker exec A-10.8.0.99 curl -4 --connect-timeout 8 -v www.example.com

重新在路由器容器建立B区网段对于目标网段的防火墙阻断

1
2

sudo docker exec -it router-firewall /bin/bash
iptables -A FORWARD -s 192.168.20.0/24 -d 104.20.23.0/24 -j DROP

将 B1 的本地映射改成 104.20.23.154

1
2
3
4
5

sudo docker exec -it B1-192.168.20.5 /bin/bash
sed '/www.example.com/d' /etc/hosts > /tmp/hosts
cat /tmp/hosts > /etc/hosts
echo "104.20.23.154 www.example.com" >> /etc/hosts
getent ahostsv4 www.example.com

直接访问目标网站被拒绝

进入 B 区网关容器，用 SSH 的 -w 参数建立带 NAT 的三层 VPN 隧道。执行命令后终端会持续运行来维持 VPN 隧道

1
2
3
4
5
6
7
8

sudo docker exec -it B-192.168.20.99 /bin/bash
ssh -w 0:0 root@10.8.0.99 \
    -o "PermitLocalCommand=yes" \
    -o "LocalCommand= ip addr add 192.168.53.88/24 dev tun0 && ip link set tun0 up \
       && ip route add 104.20.23.0/24 dev tun0 \
       && iptables -t nat -A POSTROUTING -j MASQUERADE -o tun0" \
    -o "RemoteCommand=ip addr add 192.168.53.99/24 dev tun0 && ip link set tun0 up \
       && iptables -t nat -A POSTROUTING -j MASQUERADE -o eth0"

• -w 0:0：启用 SSH 的三层隧道功能，在 B 区网关和 A 区网关之间创建 tun0 虚拟网卡
• root@10.8.0.99：SSH 连接到 A 区网关，也就是 VPN 隧道出口
• PermitLocalCommand=yes：允许 SSH 连接建立后在本地自动执行命令
• LocalCommand=...：在 B 区网关上配置 tun0，分配 192.168.53.88/24，启动网卡，并把目标网段的流量导入隧道
• RemoteCommand=...：在 A 区网关上配置tun0，分配 192.168.53.99/24并启动网卡

这里两侧都配置 NAT是为了解决返回路径问题。B 区网关上的NAT会把 B1 发出的流量伪装成 B 区网关的隧道地址 192.168.53.88，这样 A 区网关会将数据包从 tun0 送回 B 区网关，网关再根据NAT记录发给B1。A 区网关上的NAT会把从隧道转发出来的流量伪装成 A 区网关的出口地址 10.8.0.99，这样目标IP的返回包会先回到 A 区网关，再由 NAT 记录转发回隧道

然后给 B1 添加到目标网段的规则，让它访问 104.20.23.0/24 时先交给 B 区网关

1

sudo docker exec -it B1-192.168.20.5 ip route add 104.20.23.0/24 via 192.168.20.99

在 B1 容器中访问 www.example.com，直接 curl www.example.com 可能会变成 IPv6 访问，因此使用下面的命令验证

1

curl -4 www.example.com

B1 先把访问目标 IP 的数据包交给 B 区网关，B 区网关通过 NAT 把源地址改成隧道入口地址后送进tun0，SSH 隧道把数据包带到 A 区网关，A 区网关再通过 NAT 把源地址改成自己的出口地址然后从 eth0 发出。回包按照 NAT 记录逐层返回最终回到 B1，就这样实现了防火墙的越过

实验理解

在这个实验中，不管用什么方法绕过防火墙，最外层都是一个SSH隧道。整个过程中，防火墙负责拦截不允许的流量，路由决定数据包应该走普通网络还是进入隧道，SSH 作为隧道承载流量，tun0 是让流量进入隧道的虚拟网卡，NAT 负责处理返回路径。因此 VPN 本质是在原有网络外创建了一条新的虚拟网络路径

附：VPN 访问排查

在B区访问外部部分，原本是将 www.example.com 绑定到 93.184.216.34，再添加防火墙规则来阻断 B 区主机访问这个IP，最后建立VPN隧道绕过防火墙，但发现VPN建立完成后依旧无法访问

1	sudo docker exec -it B1-192.168.20.5 /bin/bash -c 'echo "93.184.216.34 www.example.com" >> /etc/hosts'

域名解析

在B1容器检查域名解析，发现显示的是 IPv6 地址，说明这个域名的解析可能自动走了IPv6

1

sudo docker exec B1-192.168.20.5 getent hosts www.example.com

查询 IPv4 解析结果，可以看到确实绑定了 93.184.216.34

1

getent ahostsv4 www.example.com

强制用 IPv4 访问目标，结果依旧失败

1

curl -4 --connect-timeout 5 www.example.com

网关配置

检查 B 区网关的 VPN 隧道、路由、 NAT 配置

1
2
3

sudo docker exec B-192.168.20.99 ip -br a
sudo docker exec B-192.168.20.99 ip route get 93.184.216.34
sudo docker exec B-192.168.20.99 iptables -t nat -L POSTROUTING -v -n

B 区网关上可以看到 tun0，地址是 192.168.53.88/24。访问 93.184.216.34 的路由是 dev tun0，说明网关会把目标流量送进 VPN 隧道。NAT 表中可以看到 MASQUERADE -o tun0，计数也增加了，说明有数据包经过 NAT 规则

检查 A 区网关的隧道、出站路由、NAT 、IP 转发状态

1
2
3
4
5

sudo docker exec A-10.8.0.99 ip -br a
sudo docker exec A-10.8.0.99 ip route get 93.184.216.34
sudo docker exec A-10.8.0.99 iptables -t nat -L POSTROUTING -v -n
sudo docker exec A-10.8.0.99 sysctl net.ipv4.ip_forward
sudo docker exec B-192.168.20.99 sysctl net.ipv4.ip_forward

A 区网关上可以看到 tun0，地址是 192.168.53.99/24。访问 93.184.216.34 的路由是 via 10.8.0.1 dev eth0 src 10.8.0.99，说明网关会把目标流量从 eth0 发出，并通过 10.8.0.1 访问外部网络。NAT 表中可以看到 MASQUERADE -o eth0，计数也增加了，说明有数据包经过 NAT 规则。两边的 ip_forward 也都是 1，说明配置部分没有问题

数据链路

之后抓包来查看数据包的路径，在 A 区网关上抓 tun0 的流量

1

sudo docker exec -it A-10.8.0.99 tcpdump -n -i tun0

然后在 B1 中重新访问目标网站

1

sudo docker exec B1-192.168.20.5 curl -4 --connect-timeout 5 www.example.com

抓到如下的流量，这里的 192.168.53.88 > 93.184.216.34.80 说明 B 区网关已经把 B1 的访问流量送进 VPN 隧道并到达 A 区网关的 tun0

检查 A 区网关是否把收到的流量继续从 eth0 发出去

1

sudo docker exec -it A-10.8.0.99 tcpdump -n -i eth0 host 93.184.216.34

抓到如下流量，可以看到源地址被 NAT 成 10.8.0.99，数据包也成功发出，说明传输路径是通的

目标IP

既然数据传输没有问题，那么问题很可能出在 A 区网关访问目标IP的时候。尝试直接访问 93.184.216.34，发现连接不上

1

sudo docker exec A-10.8.0.99 curl -4 --connect-timeout 8 -v http://93.184.216.34

直接访问 www.example.com 却成功了

1

sudo docker exec A-10.8.0.99 curl -4 --connect-timeout 8 -v www.example.com

输出中可以看到实际连接的是 104.20.23.154，而下面的这段信息说明请求经过 Cloudflare

1
2
3

Server: cloudflare
cf-cache-status: HIT
CF-RAY: a0c2ec3ca90216f0-FRA

可以得出 www.example.com 由 CDN 网络提供访问，域名解析可能返回不同的公网 IP。而之前只配置了 93.184.216.0/24的 VPN 隧道，当域名解析到新的IP地址时，原本的规则就无法匹配IP了，导致表现出来的结果是无法访问