环境
考虑以下Web应用程序的生产环境设置：
最终用户 - 互联网 - ＆gt; DMZ中的Web服务器 - 防火墙 - ＆gt;在app服务器上托管的WCF - ＆gt;数据库服务器
约束：
还要考虑到从基础架构的角度来看我们无法改变任何东西。例如，打开端口，更改任何防火墙设置等。
问题：
我们希望将托管在应用服务器上的WCF暴露给外部客户端。我们试图按如下方式解决这个问题：
最终用户 - 互联网 - ＆gt; DMZ中的路由器WCF - 防火墙 - ＆gt;在app服务器上托管的WCF - ＆gt;数据库服务器
请注意，我们无法从需要托管WCF的DMZ环境建立数据库连接，以便外部客户端可以使用它。我们开发了一个路由器WCF＆＃34;它将所有消息传递给内部WCF，反之亦然。
此解决方案增加了序列化和反序列化数据的不必要开销。必须有一种更好，更恰当的方法。我们期待社区的指导。谢谢。
答案 0 :(得分：0)
在DMZ中，参考书目告诉您：始终创建一个中间层。这意味着互联网上的另一台机器将成为连接点，它将代理连接回WCF。
该机器是您似乎提到的Web服务器，它是愚蠢的，没有数据，并且（作为一个合适的DMZ）在它与它所服务的所有机器（WCF和其他机器）之间有一个防火墙，只允许IP：此类机器上使用的PORTS。
在这种情况下，通常Apache在公共Web服务器上具有URL重写规则（即，如果是/ x / y将其发送到servera.internal.com:9900 - 如果是/ x / z将其发送到serverb.internal.com:9901等...）就够了，但当然有很多解决方案。
看来你正在这样做，为什么你说它不是正确的解决方案？
DMZ似乎有点过时的保护机制（我同意），但你必须考虑像你的WCF机器这样的服务器有几十个端口打开，你想降低面向网络的随机端口的风险机器，一个巨大的攻击面。现在一切都可以在几个端口打开的情况下工作，所以它看起来很傻傻＆＃34;完成所有这些只是为了转发TCP端口。但它仍然很有价值（例如）如果DMZ中的Web服务器后面的服务器没有Internet访问权限，即使WCF遭到攻击，攻击者也无法使用自己的反向shell部署现在称为APT的服务器（昨天后门） ）。攻击者＆＃34;看不到＆＃34;他自己的机器从WCF作为DMZ提供与外部世界的连接。