DMZ不能主动访问内网，这正是安全设计的核心所在。
那么，一个很自然的问题就来了：外部用户（比如网站访问者）最终想看的数据（比如商品信息、文章）实际上又存储在内网的数据库里，如果DMZ的Web服务器不能访问内网，那网页上怎么显示出这些内容呢？
别急，这并不矛盾。解决方案不是让DMZ“主动伸手”进内网拿东西，而是让内网“主动推送”东西到DMZ。
一、用一个更完善的银行比喻来解释
我们接着用银行的例子，现在这个银行变得更智能了：
大街（互联网）：客户要来取钱。
柜台大厅（DMZ）：柜员在这里。但他身后的现金抽屉里只放着限额内的现金（比如只够一天用的）。
金库（内网）：放着所有的钱。
内部的运钞保安（内部服务）：这是关键！
工作流程是这样的：
规则：柜台柜员（DMZ）绝对不能进入金库（内网）。
流程：每天早上银行开门前，由一位内部的、高度信任的运钞保安（内网的服务），从金库里取出一定额度的现金，主动送到柜台柜员的现金抽屉里。
结果：
客户来取钱，柜员可以直接从自己的抽屉里把钱给客户，服务很快。
即使有劫匪控制了柜台（黑客攻破了Web服务器），他也只能抢走柜台抽屉里那点有限的现金（DMZ服务器上的临时数据）。金库里的巨额财富（核心数据库）依然是安全的，因为柜员自己都进不去。
劫匪甚至不知道钱是怎么补充进来的，因为补充现金的操作（内网到DMZ的连接）是由内部发起的，外部无法观测和控制。
二、对应到实际网络技术是如何实现的？
最常见的两种安全方式：
1. 由内网“推送”数据到DMZ（对应运钞保安送钱）
这是最安全的方式。内部服务器定期、主动地把需要对外公开的数据“推”到DMZ的服务器上。
实际例子：一个新闻网站。
内网：编辑在公司内部的电脑上写好一篇文章，上传到内部的主数据库（金库）。
推送过程：内网有一个发布系统（运钞保安），会把这篇文章生成一个静态的网页文件，然后自动“推”或者同步到放在DMZ的Web服务器（柜台）上。
用户访问：您访问网站时，DMZ的Web服务器直接就把这个现成的静态HTML文件发给您了。整个过程，DMZ的Web服务器完全不需要回头去访问内网的数据库。
优点：极致的安全。DMZ和内网几乎是完全隔离的。
缺点：不是所有应用都适合做成这种“静态发布”的模式。对于需要频繁交互、实时数据的应用（比如电商搜索），就需要下面的方法。
2. 严格受限的“反向”访问（类似一个极其狭窄的单向管道）
当DMZ的服务器确实需要实时查询内网数据时（比如用户搜索商品），会开辟一个极其狭窄、被严密监控的“小孔”。
规则：防火墙规则绝不可能是“允许DMZ访问整个内网”，而是会设置成：
只允许DMZ中某台服务器（如Web服务器） -> 访问内网中某台特定服务器（如数据库服务器）的特定端口（如1433）。
并且，通常这个连接还是由内网服务器发起或预先配置好的，DMZ只是发送请求，数据流回传的通道是由内网“准许”的。
实际例子：一个电商网站搜索商品。
用户在搜索框输入“手机”，这个请求到了DMZ的Web服务器。
Web服务器需要通过一个极其严格的、预先定义好的API接口，向在内网的数据库服务器发出查询请求：“给我所有手机类商品的信息”。
内网的数据库服务器收到请求后，验证通过，将结果返回给DMZ的Web服务器，Web服务器再组装成网页展示给用户。
注意：即使这样，数据库服务器也通常不会是最核心的、存放用户密码和完整订单的“主数据库”，而是一个只读的、仅同步了商品信息的“从数据库”。这又是一层保护。
总结
所以，您的问题答案就是：
原则上禁止：从安全策略上，默认禁止DMZ访问内网，这是一条铁律，是为了避免“城门失火，殃及池鱼”。
实践上变通：通过由内网主动向外“推送”数据，或者在防火墙上开通极其精细和受限的例外规则，在保证安全的前提下，满足业务功能的需求。
核心思想是：信任的方向永远是从内向外（内网信任DMZ），而不是从外向内（DMZ不被信任去访问内网）。 所有的数据流动都必须在内部系统的严格控制下进行，而不是让暴露在风险中的DMZ服务器拥有自由进出内网的权利。