![已经拆分 DNS 但想要将某些内容路由到外部?](https://linux22.com/image/735649/%E5%B7%B2%E7%BB%8F%E6%8B%86%E5%88%86%20DNS%20%E4%BD%86%E6%83%B3%E8%A6%81%E5%B0%86%E6%9F%90%E4%BA%9B%E5%86%85%E5%AE%B9%E8%B7%AF%E7%94%B1%E5%88%B0%E5%A4%96%E9%83%A8%EF%BC%9F.png)
我们有一个 DNS 区域 example.com,它是水平分割(内部与公共)的。例如,内部区域具有 的私有 IP 地址,app.example.com
而公共区域具有同名的公有 IP 地址app.example.com
。我们最近将公有 DNS 切换到 Cloudflare,我想开始将它们用作 CDN/代理,但是在投入生产之前,我需要让 QA 团队审核这些更改。我们需要能够在app.example.com
办公室内使用内部版本的 DNS 区域时访问 的公有 IP。此 DNS 会将人们发送到内部 IP,因此他们将无法测试 Cloudflare。修改客户端的 HOSTS 文件可以工作,但这很麻烦,我无法使用公有 IP 地址更新内部 DNS。想知道是否有人能想到其他选择?
答案1
这个答案提出了一个可能的选择,当然也是一个有争议的选择。
放弃这种水平分割 DNS 想法 (1) 趁你还能放弃的时候,以及 (2) 趁你暂时有“业务”理由放弃它的时候。随着组织的发展,不明确的 DNS 配置会越来越困扰你,但它与你的环境结合得越紧密,就越难摆脱它。
使用IP层来解决IP层的问题。
优点:
- 减少人类用户的困惑
- 无论客户端位于网络中的哪个位置,DNS名称的解析都是相同的
- 轻松合并外部网络与自己的 DNS 区域
- 当你需要性能时,你可以使用
app.in.example.com
并且知道它会解析为私有 IP
缺点:
- 你会遇到“发夹式 NAT”的情况 - 谷歌搜索
- 路由器将传递两倍以上的数据包(针对发夹式 NAT 情况)
- 延迟增加微秒(针对发夹式 NAT 情况)
- 对于发夹情况,你的 DNAT-from-public 服务器将在匿名源 IP 下看到自己的子网
- 这是因为你为他的整个 IP 子网设置了 SNAT
- 例如服务器
192.168.8.8
将看到用户192.168.8.9
在netstat
192.168.8.1
- 但同一台服务器将
192.168.1.3
看到192.168.1.3
- 它将把互联网用户
9.9.9.9
视为9.9.9.9
- 它很容易修复,因为 DNAT-from-public 服务器通常是反向代理,并且可以轻松地放在远离用户的单独子网中(换句话说:revproxies 通常位于 DMZ 中)