如何让VS2022/2019对接WSL2的Docker调试并解决权限报错问题

目标为实现Visual Studio 2022（操作流程同样适配2019版本）与WSL2上部署的Docker容器联调，已完成的操作流程如下：

• 在WSL2终端进入项目目录执行docker-compose up，容器可正常启动运行
• 修改launchSettings.json内WSL调试配置的launchUrl、ASPNETCORE_URLS属性，确认WSL2环境可正常访问运行中的容器
• 选择Visual Studio的WSL调试配置启动项目调试

当前已实现效果：可正常访问容器、成功接入调试流程
存在的异常：调试执行到app.Run()语句时，抛出System.Net.Sockets.SocketException: 'Permission denied'套接字异常，提示权限拒绝。

• 触发上述套接字权限拒绝异常的根本原因是什么
• 是否有开发者成功实现Visual Studio（非VS Code）基于WSL2环境Docker的容器调试功能
• 目前公开渠道可检索到的相关参考资料极少，未覆盖该报错场景，求可落地的解决思路

该异常90%以上的场景和文件权限无关，均为套接字端口绑定阶段的权限/占用问题，常见触发原因如下：

• 端口抢占冲突：手动执行docker-compose up启动容器时，容器已经占用了ASPNETCORE_URLS中配置的Kestrel监听端口，VS启动的WSL侧dotnet调试进程作为普通用户进程，无权限抢占已被其他进程监听的端口，会在app.Run()启动Kestrel绑定套接字时抛出权限拒绝错误
• 端口落在WSL2系统预留范围：WSL2默认会预留一段端口范围给系统服务使用，若配置的监听端口落在ip_local_reserved_ports规则定义的预留段内，普通用户进程无权限绑定该类端口
• 特权端口绑定限制：若配置的监听端口为1024以下的特权端口，WSL2默认仅允许root进程绑定，普通用户启动的dotnet调试进程无对应权限
• 防火墙规则拦截：WSL2内iptables/nftables规则限制了对应端口的绑定权限，或配置监听0.0.0.0地址时被安全规则拦截

• 调整端口配置避免冲突：不要让手动启动的Docker容器和本地调试进程绑定同一个端口，例如容器对外映射到5000端口时，WSL调试配置内的ASPNETCORE_URLS可设置为http://localhost:5010，同步调整请求转发、启动页配置即可，这是成本最低的解决方式
• 处理端口预留问题：在WSL2终端执行cat /proc/sys/net/ipv4/ip_local_reserved_ports查看当前系统预留的端口段，若业务端口落在预留范围内，编辑/etc/sysctl.conf修改net.ipv4.ip_local_reserved_ports参数，将业务端口移出预留范围，执行sudo sysctl -p生效后重启WSL实例即可
• 配置特权端口绑定权限：若必须使用1024以下端口，可在WSL2内执行sudo setcap cap_net_bind_service=+ep /usr/share/dotnet/dotnet，给dotnet运行时授予绑定特权端口的权限，无需用root身份启动VS调试
• 改用VS内置编排能力：不要手动提前执行docker-compose up，将VS的Docker引擎端点配置为WSL2内的Docker实例，使用VS内置的容器编排调试能力，由工具自动处理端口映射、调试进程附着、网络规则配置，从根源避免手动操作带来的权限、端口冲突问题

内容的提问来源于stack exchange，提问作者cyril_ogc