如何创建安全且配置良好的 WSL 2 环境

如果您使用 Windows 但需要 Linux 在系统开发或管理方面的全部功能WSL 几乎成了必备工具。问题在于，许多人匆忙安装，却不考虑安全性、性能，以及如何将其与公司现有工具正确集成。在企业环境中或处理敏感数据时，这样做无异于玩火。

接下来您将看到如何 创建一个真正安全、配置完善且舒适的 WSL 2 环境无论您是本地开发人员，还是在组织中管理数十台计算机并使用 Intune、Microsoft Defender 和高级网络控制的人员，最终目标都是让您获得一个强大、易于管理且易于维护的 WSL，而不仅仅是“另一个 Linux”，没有人真正知道它在做什么。

WSL是什么？它为什么如此有趣……但又并非无害？

WSL（适用于 Linux 的 Windows 子系统）是 Windows 10 的一项功能， Windows 11 让 直接在 Windows 上运行完整的 Linux 发行版无需在 VirtualBox 或 VMware 中设置传统的虚拟机。实际上，您可以从 Microsoft Store 安装 Ubuntu、Debian、Kali 或 AlmaLinux，然后像使用其他应用程序一样使用它们。

微软通过 WSL 2 实现了重大飞跃：它现在可以运行 一个真正的Linux内核，运行在……之上 基于Hyper-V的轻量级虚拟机这大大提高了性能和与系统调用的兼容性，并且使得使用在 WSL1 中无法使用的工具（例如 Docker）成为可能。 数据库 重量级或GPU加速的机器学习环境。

最大的好处是 您无需手动管理虚拟机或复杂的网络。Windows 负责设置环境、挂载文件系统、暴露 \wsl$ 路径，并使 Linux 和 Windows 在文件和命令级别上“看到”彼此，实现相当透明的集成。

对于使用 Windows 系统但部署环境为 Linux 的开发人员和管理员来说，这意味着他们现在可以 在与生产环境几乎完全相同的环境中工作。 无需离开您常用的桌面，即可重用相同的库、数据库管理器、消息队列、Web 服务器等。而且所有这一切都不会影响您继续使用 Visual Studio、Office 或您常用的企业工具。

WSL 2 的安全基本安装

确保 WSL 环境安全的第一步是： 请正确安装，并确保安装在已更新的 Windows 系统上。从 Windows 10 22H2 和 Windows 11 22H2 开始，WSL 与系统的集成度非常高，并且命令也得到了简化。 wsl --install 只需几分钟就能让它正常运行。

首先，建议 请检查您的 Windows 版本和内部版本号。按下 Windows 键 + R，输入 winver 请检查您的系统版本是否为最新版本。如果不是，请通过“设置”或使用 Windows 更新助手进行更新。这并非随意之举：许多网络、安全和集成方面的改进仅在最新版本中可用。

然后打开 PowerShell的 ØEL 命令提示 作为管理员 并运行基本安装命令：

wsl --install

此命令负责 启用 WSL 和虚拟机平台的可选组件下载最新的 Linux 内核，将 WSL 2 设置为默认版本，并自动安装 Ubuntu 发行版（之后可以添加其他发行版）。此过程可能需要重启；请勿跳过此步骤，否则虚拟化和内核将无法正确配置。

如果您更喜欢选择 Ubuntu 以外的发行版，例如 Debian、Kali、AlmaLinux 或类似发行版，您可以使用命令列出可用的镜像并手动安装它们。 wsl --install -d <NombreDistro>或者从 Microsoft Store 下载。在商业环境中，您还可以 使用自定义图像 wsl --import y wsl --export 确保每个人都在经批准的相同基础上工作。

在 WSL 中安全地创建和管理用户及密码

安装完成后，首次从“开始”菜单运行该发行版时，会启动一个简短的向导，询问您相关问题。 创建您自己的 Linux 用户名和密码这些凭据与 Windows 帐户无关；它们对于每个发行版都是独立的。

第一个用户就成为了 具有 sudo 权限的默认用户也就是说，它将是能够执行行政任务的那个人。 sudo从安全角度来看，重要的是要将其视为一个强大的账户。选择一个 强密码不要重复使用 Windows 版本，也不要为了“方便”而与团队其他成员共享。

请记住 WSL 中安装的每个发行版都有自己的一套用户名和密码。如果您重新安装、重置或导入新的发行版，则需要重新创建用户。如果管理得当，这反而是一个优势：您可以使用不同的帐户隔离开发或测试环境。

更改密码 使用账户，只需在发行版中运行该命令即可 passwd输入您当前的密码，然后再输入您的新密码。如果您完全忘记了您的 Linux 密码，您可以 输入为 根 来自 PowerShell 运行：

wsl -u root

如果发行版不是默认发行版穿着：

wsl -d <NombreDistro> -u root

进入系统后，您将能够更新受影响用户的密码。 passwd <usuario>完成后，请写下 exit 关闭 root 会话。这种从 Windows 提升权限的能力非常实用，但建议不要这样做。 有效保护对 PowerShell 团队的访问权限因为如果有人坐在你未上锁的电脑前，他们就可以利用这种方法修改 Linux 账户。

安全维护：软件包和内核更新

Windows 无法处理 自动更新 WSL 中的 Linux 用户空间这意味着，就像在经典的 Linux 服务器上一样，您（或您的 IT 团队）必须定期应用安全补丁，以防止库、数据库、解释器等出现漏洞。

在基于 Debian 或 Ubuntu 的发行版中， 最低维护周期 会定期运行：

sudo apt update && sudo apt upgrade

这可以提供最新的软件包列表，并允许您应用可用的更新。这在企业环境中非常有用。 集成特定的配置管理工具 （例如 Puppet、Ansible、Chef 等）可以跨多台机器同时协调这些更新。例如，微软文档中介绍了如何通过 WSL 2 运行 Puppet 来实现此目的。

另一方面，WSL 内核也会独立更新。如果在使用 WSL 2 时收到类似“WSL 2 需要更新其内核组件”的消息，则需要…… 下载更新后的内核包 从微软下载内核并手动安装。它是一个简单的可执行文件：运行它，重启系统，就完成了。保持内核更新至关重要，这样才能享受性能提升、兼容性增强和安全补丁带来的好处。

WSL、WSL 2 和其他技术：选择合适的场景

在着手搭建 WSL 环境之前，有必要先明确以下几点： 在哪些情况下它是合适的工具，在哪些情况下它不是？最后，您还有其他选择：完整的虚拟机， 引导 双容器、纯 Docker 容器等。

WSL 1 是一个兼容层，可以将 Linux 调用转换为 Windows 调用；对于基本任务很有用，但功能有限，没有完整的内核支持，并且对于 Docker 等工具也存在问题。 另一方面，WSL 2 在轻量级虚拟机中运行真正的 Linux 内核。借助原生虚拟机管理程序，在某些工作负载下可提供高达 500% 的性能提升，并支持以前无法实现的服务。

与……相比 经典虚拟机WSL 2 是 内存和CPU占用率低得多它启动只需几秒钟，并且与 Windows 文件系统完全集成。但是，当您需要非常精细的硬件控制、高生产环境或非常具体的网络配置时，传统的虚拟机仍然具有优势。

与双启动相比，WSL 避免了以下情况： 重启电脑即可在 Windows 和 Linux 之间切换。Linux 可以毫无问题地读取分区。 NTFS Windows 系统，以及借助 WSL 的 Windows 系统，可以访问 ext4 文件系统。这大大减少了为了查看或复制文件而切换操作系统的需要。

最后，Docker 和 WSL 非常契合：Windows 上的 Docker Desktop 依赖 WSL 2 来高效地交付基于 Linux 的容器。Docker 将服务隔离在最小的容器中，而 WSL 则提供 一个完整的 Linux 环境，用于开发、测试和编排这些容器。它们是互补的，而不是竞争对手。

存储和文件系统访问：安全性和性能

确保和优化环境的关键点之一是 决定项目文件的存储位置虽然 Windows 和 Linux 可以访问对方的文件系统，但并非所有情况下都能提供相同的性能或控制级别。

对于主要使用 Linux 工具的项目，一般建议是： 将代码存储在发行版的文件系统中也就是说，在以下类型的路线上：

\\wsl$\<NombreDistro>\home\<Usuario>\Proyecto

从 Linux 访问这些路径非常快例如，在 Windows 系统中使用资源管理器执行此操作，需要用到网络路径。 \\wsl$这一点完全得到支持。

应该避免的是反向操作： 把项目留在 C:\Users\<Usuario>\Proyecto 并从 Linux 系统操控它们 通过 /mnt/c这种方法虽然可行，但会降低性能，在高 I/O 负载下，性能影响会非常明显。此外，如果您不熟悉 Windows 权限和 ACL 与 Linux POSIX 权限，将它们混用可能会造成混淆。

启动 Windows 资源管理器 从当前目录 终端 使用 WSL 非常简单：

explorer.exe .

从 Linux 系统可以通过在以下位置设置的路径访问 Windows 系统： /mnt/c, /mnt/d等等。诀窍在于利用这种互操作性…… 临时通行证，并非主要工作基础尤其是如果您关注性能或权限可追溯性的话。

在 WSL 上配置编辑器和开发工具

为了真正提高工作效率，你需要一个编辑器或集成开发环境（IDE）。 与 WSL 原生集成。 这里 Visual Studio代码 Visual Studio 发挥着主导作用，它特别支持在发行版“内部”工作，就像在远程服务器上工作一样。

Visual Studio Code 配合“远程开发包”允许您： 打开 WSL 文件夹，直接在 Linux 中运行扩展程序、终端和调试器。 该界面运行于 Windows 系统。安装好相应的扩展程序后，只需在 WSL 终端中运行以下命令：

code .

在连接到您的发行版后，在 VS Code 中打开当前目录。这允许您切换环境（主机、WSL 等）。 SSH的（容器）几乎可以即时创建，并且不会用项目特定的依赖项“污染”您的 Windows。

Visual Studio 2022 也改进了其集成性：现在您可以 编译和调试面向 WSL 的 CMake 项目通过 SSH 连接到远程机器或直接连接到 Windows 系统，所有操作均可在同一个 IDE 实例中进行。对于跨平台 C++ 开发而言，此选项尤其强大，因为它允许您在 Windows 环境下验证真实 Linux 系统中的行为。

配置你的 shell 为了简化日常任务，并采取合理的方法，这样做是可取的。一个典型的例子是编辑文件。 .bashrc o .zshrc 包括便于访问 Windows 路径的别名，例如：

alias cnn="cd /mnt/c/Users/tu_usuario"

但是，在处理这些文件时必须格外小心： 错误 .bashrc 可能会使外壳处于一种奇怪的状态因此，打开它们的理想方式是通过 WSL 和 VS Code（code .bashrc）并逐步进行更改，测试每次更改。

版本控制和容器：WSL 中的 Git 和 Docker

WSL旨在成为现代开发流程的核心组成部分，并且 Git 和 Docker 成为密不可分的伙伴将它们良好地整合起来，对于生产效率和安全都至关重要。

对于 Git，建议直接在 Linux 发行版中安装和使用。这样， 行尾符、可执行文件权限和路径 它们的功能与在任何普通的 Linux 环境中相同，从而减少了部署到服务器时可能出现的意外情况。您可以将其与 Windows 凭据管理器结合使用，以管理与 GitHub、Azure DevOps 或 GitLab 的身份验证，而无需在 WSL 中暴露明文令牌。

至于 Docker，WSL 2 的到来改变了游戏规则：Docker Desktop 现在可以充分利用…… WSL 轻量级虚拟机作为 Linux 容器运行时引擎它能与您的 Linux 发行版无缝集成，并提供非常不错的性能。通过适当的网络配置和共享路径，您可以像在纯 Linux 服务器上一样，从 WSL 终端启动容器。

对于更高级的场景，您还可以 无需 Docker Desktop 即可直接从 WSL 启动容器虽然在发行版中使用 dockerd，但在商业环境中，通常更方便的做法是采用官方的 Docker Desktop 解决方案及其更新和遥测策略。

为确保 WSL 安全，需进行高级网络和防火墙配置。

当我们谈论真正的安全时，我们需要仔细审视…… WSL 网络行为及其与 Windows 防火墙的集成从 Windows 11 22H2 和 WSL 2.0.9 开始，主机防火墙规则会自动应用于 WSL 发行版，从而大大简化了控制。

这意味着任何 企业防火墙策略已配置 Windows Defender的 防火墙 （或通过 Intune 或 GPO 管理的）配置会在 WSL 环境中有效复制。对于特殊情况，您可以通过调整 WSL 内部依赖的 Hyper-V 防火墙来进一步自定义其行为。

此外，微软还在文件中引入了高级选项。 .wslconfig 下节 ，例如：

• networkingMode=mirrored启用镜像网络模式，提高与以下系统的兼容性 VPN、IPv6 和复杂的网络环境避免了传统 NAT 模式带来的许多麻烦。
• dnsTunneling=true：改变了 WSL 的方式 DNS解析使用虚拟化功能而非依赖直接网络数据包。如果您设置了严格的防火墙规则、代理或 VPN，导致域名解析中断，这将非常有用。
• autoProxy=true：强制 WSL 重用 Windows HTTP 代理配置，这对于所有流量都必须通过企业代理或检查系统的公司来说至关重要。

如果所有这些都辅以良好的更新控制、访问策略和网络分段，您就可以拥有一个 WSL 环境，该环境 不要在安全架构中创建“侧漏洞”。但它是一个集成度更高、更易于监控的组件。

企业管理：Intune、Defender for Endpoint 和自定义映像

在拥有几十个或几百个员工的组织中 手提 启用 WSL 后，每个开发者仅仅“凑合着用”已经不够了。这是必须的。 集中式方法来配置、监控和限制 WSL 的使用 符合房屋规定。

而微软 Intune 则可用于…… 管理对 WSL、其组件和关键安全参数的访问通过 Intune，可以应用策略来启用或禁用 WSL 作为 Windows 组件，定义推荐配置，以及部署文件。 .wslconfig 具有特定的网络价值，并确保与公司其他工具保持一致。

对公司而言，一个非常有趣的模式是： 自定义 WSL 镜像创建思路很简单：在参考机器上安装 WSL， 下载 您可以选择所需的 Linux 发行版（例如，“企业级”Ubuntu 或根据您的技术栈定制的 AlmaLinux），安装软件包、工具、代理和标准配置，当一切都按照您想要的方式配置完成后， 导出发行版 搭配：

wsl --export <NombreDistro> <RutaArchivo.tar>

该 tar 格式的镜像文件可以在内部分发（网络共享、软件管理系统等），然后再分发给每个用户或设备。 本地导入 搭配：

wsl --import <NombreDistro> <RutaInstalacion> <RutaArchivo.tar>

这样，所有开发者都从这里开始。 受控且安全可靠的环境使用相同版本的解释器、数据库、监控代理和强化规则。这种策略在使用应用商店中未提供的发行版（例如 CentOS、Red Hat 企业版等）或需要非常具体的基线时尤为有效。

命令互操作性和对 Windows 文件系统的访问

WSL最强大（同时也最微妙）的功能之一是 Linux 和 Windows 命令之间的互操作性您可以通过 PowerShell 运行 Linux 工具。 wsl <comando>通过 WSL，您可以调用以 . 结尾的 Windows 可执行文件。 .exe.

您可以使用 PowerShell 列出目录的内容。 运用 ls -la Linux 的典型特征是：

wsl ls -la

或组合 ls 同 findstr (wsl ls -la | findstr "git"要筛选结果，或者反之亦然，请使用 dir | wsl grep git在 Linux 终端中，您可以打开 Windows 记事本进行编辑。 .bashrc 同 notepad.exe .bashrc或者利用诸如以下工具： ipconfig.exe 并用以下方式处理其输出： grep y cut.

关于文件访问，当 WSL 中的 Linux 二进制文件打开 C:\ 目录下的文件时，它会执行以下操作： 需获得运行该程序的 Windows 用户的权限。 wsl.exe这意味着即使您在发行版中拥有 root 权限，如果您的 Windows 帐户不允许，您也无法在 Windows 上执行管理操作。Windows 安全仍然是底层的“硬性保障”。

反之，这种互操作性需要秩序。例如，这样做就不是一个好主意： 在对权限和影响缺乏全面了解的情况下，编写大量混合使用 Windows 和 Linux 路径的脚本。在敏感环境中，建议限制通过 WSL 公开的 Windows 工具以及通过 WSL 公开的 Windows 工具，并培训用户了解每一端实际运行的程序。

WSL 中的 GUI、GPU 和驱动器挂载应用程序

WSL 最初是为终端使用而设计的，但渐渐地，其他功能也开始陆续加入。 更高级的功能：Linux 图形应用程序、GPU 加速和外部磁盘挂载 使用典型的服务器文件系统。

现在可以配置 WSL 来运行 Linux GUI 应用程序 这些工具与 Windows 桌面集成，最大限度地减少了对完整虚拟机的需求。对于那些需要使用原生 Linux IDE、带有自身界面的工具或引导式管理环境的用户来说，这开辟了一系列非常有趣的可能性。在某些情况下，仍然会使用像 Win-KeX（Kali Linux 中的一款工具）这样的外部解决方案，它通过 VNC 提供了一个与 Windows 集成的完整桌面环境。

在机器学习和繁重工作负载领域，WSL 也支持 GPU加速训练正确设置 驱动程序 在这种环境下，您可以在 Linux 系统内利用计算机的图形处理能力来执行高性能任务，而无需离开 Windows 生态系统。这对于需要单一一体化工作站的数据科学家和人工智能开发人员来说尤其有用。

最后，WSL 2 允许 使用 Linux 文件系统挂载外部驱动器或磁盘像 ext4 这样的文件系统通常在 Windows 系统中无法直接访问，但如果您需要访问 Linux 服务器或旧系统上的数据磁盘，则可以通过 WSL 挂载它们。这样，您就可以直接在命令行中操作，而无需借助第三方工具或独立的虚拟机。

但是，建议对待这些设置要像对待真正的服务器一样谨慎： 检查权限，避免运行未知脚本，并控制谁可以访问物理设备和 WSL 环境。因为收集到的数据可能非常敏感。

故障排除和安全最佳实践

WSL功能强大，但并非完美无缺。 典型的安装错误、兼容性问题和虚拟化冲突了解最常见的问题有助于快速解决问题，并避免配置错误，以免日后造成损失。

常见错误包括代码 0x80070003 y 0x80370102 在安装过程中，他们通常会指出 BIOS/UEFI 中的虚拟化问题 或者与发行版的安装位置有关（WSL 只能在 Windows 安装所在的驱动器上正常工作，通常是 C 盘）。另一个常见错误是可选的 WSL 组件未启用；可以通过在 Windows 功能中启用“适用于 Linux 的 Windows 子系统”或使用相应的 DISM/PowerShell 命令来解决此问题。

另一个常见错误是“Windows 子系统 Linux 版未安装任何发行版”的消息，即使您已经下载了发行版，也可能出现此消息。在这种情况下，通常只需…… 从“开始”菜单至少运行一次该发行版。 这样，在从命令行调用它之前，初始配置就已经完成了。

在性能层面， 请检查您是否处于 WSL 2 环境中。 （带 wsl -l -v），确保您有足够的硬件资源，并且您没有通过慢速路由进行工作（/mnt/c 对于大型项目而言），虚拟化不会受到其他解决方案（例如，其他第三方虚拟机或配置错误的安全工具）的干扰。

纯粹从安全角度来看，一些基本的良好做法包括： 限制已安装发行版的数量 （避免使用没有实际用途的发行版集合），仅使用已批准或已知的映像，保持 Windows 和 WSL 为最新版本，在不需要 WSL 的计算机上禁用 WSL，并且在公司中，依靠 Intune 和 Defender for Endpoint 来实现集中可见性和控制。

应用以上所有功能后，WSL 从简单的“Windows 内置 Linux”变成了…… 一个稳定、可控且符合安全政策的工作环境这样一来，开发者和管理员就可以在不同的世界之间自由移动，而不会留下任何漏洞或临时的后门。