3.2 容器与WSL部署

3.2 容器与WSL部署

本节摘要：容器版 Kali 提供秒级重建与分层复用，适合已有 Linux 主力机的人与自动化场景；WSL 版让 Windows 主机随时拥有 Kali 通道并支持图形工具。本节给出两条路线的完整上手过程与边界说明——它们都做不了依赖物理射频的任务。

第三章主线的第二天：如果你不想为 Kali 单独开一台虚拟机，或者你的工作机是受管的 Windows，两条轻量路线就值得认真考虑。

容器路线：把 Kali 变成可丢弃的耗材

容器版 Kali 的核心价值是廉价的重置。虚拟机重置要几十秒到几分钟，容器重建只要几秒；配合分层镜像，公共部分（基础系统、常用工具组）只存一份，个性化部分薄薄一层叠加其上。对"每次任务一个干净环境"的纪律来说，这是最经济的实现方式。

# 拉取官方镜像并启动一个交互容器
docker run --tty --interactive kalilinux/kali-rolling /bin/bash
# 首次进入是极简系统，装上需要的功能域工具组
# 容器内：
apt update && apt install -y kali-tools-information-gathering nmap zsh
exit

# 把配置好的容器固化为自定义镜像（分层复用的关键）
docker commit <容器ID> mykali/recon-base
# 之后每次任务都从自定义镜像起步，秒级就位
docker run -it mykali/recon-base /bin/zsh
​

用一段时间后，推荐把自定义镜像的构建过程写成 Dockerfile——这就是上一节"环境即代码"的容器版：从基础镜像到装哪些工具组、改哪些配置，全部声明在文本里，重建与分发都由一条构建命令完成。

容器路线的边界必须记牢。其一，无物理射频：容器拿不到无线网卡的底层控制，无线类任务绝缘。其二，网络是隔离的：默认的桥接网络访问外部没问题，但要扫描同一网段里的其他虚拟机，需要把容器网络模式改成 host 或挂在自定义网桥上——这类配置做错时的症状（容器里 ping 不通靶机）在第 3 节的排错框架里有对应位置。其三，桌面可选但非默认：需要图形工具时可以装轻桌面加远程访问，但多数人的选择是容器跑命令行部分、图形工具留给虚拟机。

WSL 路线：Windows 里的 Kali 通道

很多安全工程师的日常主机是 Windows——公司发的机器、办公软件的锁定、只有一个系统的现实。WSL（Windows 的 Linux 子系统）给了这条路一个体面的答案：在 Windows 内部运行一个真正的 Linux 用户态环境，Kali 官方直接提供 WSL 发行版。

安装过程在较新的 Windows 上已经是商店级操作：启用 WSL 功能后，一条命令拉起 Kali，之后的使用与原生 Linux 高度一致。两个关键能力值得单独说：

图形支持。 WSL 的图形方案让 Linux 图形程序直接以窗口形式出现在 Windows 桌面上，这意味着那些必须用图形界面的安全工具（流量代理、抓包工具的界面）在 WSL 里也能工作，不必再开虚拟机。

文件互通。 Windows 与 WSL 之间互相访问文件是原生能力，报告写一半切过去抓个证据再切回来，工作流不断。

# Windows 侧安装（PowerShell）
wsl --install -d kali-linux
# 首次启动设置用户名密码，之后进入即是一个 Kali 用户态

# Kali WSL 内部：补齐工具与图形支持
sudo apt update && sudo apt full-upgrade -y
sudo apt install -y kali-win-kex
# 图形模式（Win-KeX）：在一个窗口里拉起完整桌面
kex --win -s
​

Win-KeX 是 Kali 团队为 WSL 做的桌面方案，--win -s 参数以窗口化、声音支持的方式启动完整桌面——一条命令把 Windows 笔记本变成一台双系统工作机。

WSL 的边界与容器类似但要再多说一句：它的内核是微软维护的兼容层内核，不是原生 Linux 内核。绝大多数用户态工具无感，但涉及内核模块、特殊驱动、底层硬件访问的任务会碰壁。判断方法很简单——问题如果在原生虚拟机里不存在、在 WSL 里存在，先怀疑兼容层，别急着怀疑工具。

三线并存的实践形态

两条轻量路线讲完，把第三章开头的决策框架补完整。一个常见的成熟形态是三者并存：

• 虚拟机承担主力测试与所有射频任务，享受快照安全绳；
• 容器承担流水线与自动化（第五章的脚本在这里跑），享受秒级重建；
• WSL承担日常随手通道与 Windows 侧办公衔接，享受文件互通。

三者共享同一份"环境声明"——工具组清单、配置脚本、重建文档。这份声明才是你的环境本体，三个运行形态只是它在不同约束下的投影。

部署实录：十分钟拉起一个侦察容器

把本节内容压成一次可复现的完整操作。背景：需要给一位同事提供一个"只能做信息收集"的临时环境，用完即弃，不留残余。

操作：第一步，从官方镜像起步，装上信息收集功能域与范围核对脚本（1.2），固化成自定义镜像 team/recon-only。第二步，按需起容器——挂载一个专门的结果目录作为输出位置，网络用默认桥接（只出不上）。第三步，交付：把镜像与起容器的命令行交给同事，他的全部操作都在容器里进行，结果文件落在共享目录。第四步，用完销毁：容器删除，镜像保留，目录里的结果按证据规则归档。

# 交付给同事的完整指令就这么多
docker run -it --rm -v "$PWD/results:/results" team/recon-only
# --rm 退出即销毁容器 · -v 只挂载结果目录 · 其余一切不落盘
​

结果：同事得到了一个工具就绪、边界清晰（只能做侦察）、随时可弃的环境；团队得到了一个可复用的镜像资产。解读：这个模式的价值在于最小暴露面交付——按任务授予能力，任务结束能力收回，比"给他一台全能虚拟机"的权限模型干净得多。这也是 7.1 按角色声明镜像思想的容器化缩影。变式：同一镜像换个挂载目录就是下一场任务的现场；换个功能域声明就是另一种能力容器。

容器与 WSL 的边界问答

问：容器里能跑图形界面的工具吗？ 能，但通常不值得。容器跑图形需要额外的显示转发配置，违背了它的轻量初衷。合理的分工是：命令行部分进容器，图形工具留在虚拟机——你的工具箱不必挤在一种形态里。

问：WSL 里的 Kali 和虚拟机里的 Kali，文件算谁的？ 各自的文件系统是独立的，但互相访问是原生能力。要注意的是性能特性：跨文件系统边界的文件操作明显慢于本地。实践建议：工具与数据尽量放在同一侧，跨边界只做传输不做加工。

问：两种形态可以做 4.5 的无线任务吗？ 都不行，原因不同：容器拿不到物理射频的底层控制；WSL 的兼容层内核不含无线注入所需的驱动接口。无线任务的老家永远是物理机加支持直通的虚拟机——2.2 节的边界清单在这里第三次出现。

问：容器镜像会不会越攒越多，最后不知道哪个是哪个？ 会，这是容器路线的固有代价。治理方法与 3.1 的快照治理同构：给镜像打有语义的标签（日期加用途），定期清理超过一定时长未使用的层，保留一份"当前有效镜像清单"作为环境声明的一部分。镜像堆积的乱局与快照链过长是同一种病——可丢弃的便利没有配套清理纪律，就会变成新的负债。

💡 关于"用哪个"的最终建议：别在路线选择上超过十分钟。三条路线都通向同一个地方——一个隔离、可重置、可声明的实验场。真正的分水岭在第 3 节：环境装好后能不能独立把它调顺。下一节就是这场实战演习。