通过 DHCP Options 下发路由解决同局域网内服务器互访的效率问题

背景

• 局域网 Kubernetes 测试服务器的具有公网(1.2.3.4)、局域网(10.0.0.10)双网卡
• 日常需求较多需要从局域网内/公网环境通过域名访问测试服务器（同时还有部分正式环境的大数据服务）

旧方案

• 公网环境 DNS 配置gw.sukikaka.com A 1.2.3.4
• 局域网环境 DNS Server 10.0.0.1 配置劫持成 gw.sukikaka.com A 10.0.0.10
• 局域网环境通过 DHCP Server 配置 DHCP Options 6,10.0.0.1,223.5.5.5 来达到下发 DNS Server 的目的 而以前用内网DNS服务器添加劫持，将gw.sukikaka.com A 10.0.0.10从而解决解析的问题，但是其他测试环境域名通过CNAME将解析指向gw.sukikaka.com时，并不能将CNAME再次顺利解析到10.0.0.10

存在的问题

• 需要将DNS Server设置成内网指定的DNS Server 10.0.0.10，否则无法劫持
• 增减域名需要在公网DNS Server设置解析，也需要在局域网DNS Server设置解析
• 另外，由于公司不少同事是使用科学上网，而这些科学上网很难要求他们会自己将DNS Server设置成内网的Server，所以最终导致占用 Kubernetes 公网带宽，测试环境体验不好
  • 访问测试环境的数据会经过主路由器 NAT 成 default route 的公网地址，然后再访问Kubernetes的公网地址NAT回来，然后处理完成之后再反向回来局域网内的请求客户端，ip packet 增加了多余的NAT

新方案

• 公网环境 DNS 配置gw.sukikaka.com A 1.2.3.4
• 局域网环境通过 DHCP Server(网关) 配置 DHCP Options 6,10.0.0.1,223.5.5.5 来达到下发 DNS Server的目的（此时内网DNS Server仅通过使用SmartDNS服务，用于优化DNS查询，不做测试环境解析记录劫持）
• 利用 DHCP Server 将 DHCP Options 121, 1.2.3.4/32, 10.0.0.10 添加到请求客户端的路由上

新方案的优缺点

• 优点
  • 直接在请求端发起请求的时候通过路由表路由到最终目的地，ip packet 只经过交换机而不需要经过路由器流转，减少了一次多余的NAT，提升了效率
  • 只需要配置公网 DNS 解析，而不需要再配置局域网 DNS Server 劫持记录，减少了维护成本
• 缺点
  • 双网卡公网服务器一旦有变更，需要更改主路由器下发 DHCP Options 配置

最后，可以通过ip route(Linux/Unix)或route print(Windows)来查看本机路由来确认：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

default via 10.0.0.1 dev en0
1.2.3.4/32 via 10.0.0.10 dev en0   <---- 相比旧方案，新增了这一行
127.0.0.0/8 via 127.0.0.1 dev lo0
127.0.0.1/32 via 127.0.0.1 dev lo0
169.254.0.0/16 dev en0  scope link
192.168.0.0/21 dev en0  scope link
10.0.0.1/32 dev en0  scope link
224.0.0.0/4 dev en0  scope link
255.255.255.255/32 dev en0  scope link

现方案可以认为是以前方案的优化版，具体参考一种有趣的测试环境部署方式