WSL 1以不同的方式解决了这个问题，但我需要WSL 2，因为这是一个仅在WSL 2中支持的GUI应用程序。所以，我想继续使用WSL 2。
对。大多数人最终选择WSL 1路线，但由于您需要WSL 2，您可能没有这种奢侈。尽管如此，在我们完全给予之前，考虑一下WSL 1仍然可以运行GUI应用程序--您只需要在Windows中设置一个X服务器来托管它们。请参阅this Super User answer了解详细信息。我自己用过VcXsrv，但其他人应该也没问题。
至于WSL 2选项，我个人的偏好是：

• 在系统上设置Windows OpenSSH服务器。
• 创建一个隧道，如下所示：

ssh -L <license_server_port>:<license_server_host_or_IP>:<license_server_port> \
    <windows_username>@$(hostname).local

这样，在WSL 2中运行的应用程序就应该连接到localhost:<port>。由于SSH客户端连接到Windows主机，因此许可证服务器将看到来自Windows主机的任何请求，这应该允许它通过防火墙。
基于您在Stack Overflow上发帖的事实，我假设这是您正在开发的应用程序，您可以修改它以将许可证服务器更改为localhost:<port>。但是，如果您不能进行更改，您仍然可以在/etc/hosts中设置一个条目，将许可证服务器主机名Map到127.0.0.1。
但是，还有另一种可能性：
有没有办法告诉Windows，所有来自WSL 2的流量都应该被屏蔽（NAT？）通过“普通”网络接口，使其与主机pc使用相同的IP地址？
好吧，也许是这样--您可以尝试在桥接模式下运行WSL 2的网络交换机，这应该使流量看起来像是来自与Windows主机相同的网络适配器。
注意事项--这个特性在18个月前，微软WSL产品经理作为一个“实验性”特性的评论中只提到过一次，AFAIK。在那之后（再次，AFAICT），它再也没有被提及，即使在WSL达到1.0.0里程碑的发行说明中也是如此。
但考虑到这一点，here's a blog post详细介绍了如何让它运行。我在其他答案中多次建议过，但我从未听说有人尝试过。大多数解决方案是WSL 1，其余的解决方案是端口转发解决方案。所以如果你真的尝试了，我很想听听你的效果。我甚至建议，如果你真的用过它，而且它很有效，你可以把你的经验（以及你是如何让它工作的细节）写下来作为一个单独的答案。