IPv4客户端访问IPv6服务器、IPv6客户端访问IPv4业务，本质上都是协议栈不互通的问题，解决思路只有一条：让一方在地址层面“翻译”成另一方认得的格式。现实中用得最多的翻译工具是双栈、NAT64/DNS64组合和反向代理,选哪个取决于你的资源情况和业务类型。
为什么IPv4和IPv6互通成了绕不开的坎？
IPv4地址池从设计之初就没想过互联网会膨胀到今天这个规模，总数约43亿个的IPv4地址早在数年前就已全部分配完毕，国内运营商的家宽用户普遍拿到的是私网地址，公网IPv4资源越发紧张，IPv6正是解这个死结的，但互联网上还有海量老设备、老系统只认IPv4，两边直接通信几乎不可能IPv6报文到了IPv4网络里,路由器根本不知道怎么处理。
现实情况是，双轨共存还得持续相当长时间，据工信部数据，国内IPv6活跃连接数已达亿级规模；近年来，谷歌的IPv6普及率统计也显示，全球已有三成以上的用户网络环境具备IPv6访问能力，但存量IPv4业务依然庞大,两边互相访问就成了日常刚需。
IPv4客户端如何访问IPv6服务器？三条路按场景选
如果你有一台纯IPv6服务器，想让老客户用IPv4访问，有三条路可走,按部署成本和维护难度从低到高排：
- 双栈：服务器同时绑定IPv4和IPv6地址，DNS里A记录和AAAA记录都返回,客户端走哪条都行。
- 反向代理：一台双栈前置设备监听IPv4端口,把请求转发给后端的IPv6服务器。
- NAT64反向映射：通过NAT64网关的静态端口映射,把IPv4公网地址的某个端口对应到IPv6服务器的服务端口。
双栈：最省心，但条件是“有矿”
双栈在技术上没有任何门槛，网卡上同时配两类地址，业务直接监听双栈端口即可，难点在于你得有一个可用的IPv4公网地址，国内现在公网IPv4地址非常稀缺，很多机房新开的服务器根本不分配IPv4，云厂商也在推IPv6单栈实例，所以双栈适合有大段IPv4地址的老牌IDC和企业自建机房,新环境很难复刻这条路。
反向代理：Web业务最优解
如果你的业务走HTTP/HTTPS，Nginx或HAProxy就能轻松搞定，做法是让代理服务器监听IPv4端口，转发请求到IPv6后端,配置片段如下：
server {
listen 80;
location / {
proxy_pass http://[2408:8400:xxxx::1]:8080;
}
}这个方案的优点很明显：
- 客户端完全无感知,不要求用户改任何配置。
- 代理层可以顺便做负载均衡、TLS卸载、缓存。
- 成本低,一台双栈小机器就能撑起不少请求量。
缺点是代理本身是性能瓶颈，且只适合应用层协议，FTP、游戏、自定义TCP业务想这样做，就得用HAProxy做四层转发,本质上还是同样的思路。
NAT64反向映射：IPv4主动“跨界”的少数派方案
NAT64天生是给IPv6用户访问IPv4服务的，但网关也支持把IPv4流量映射进IPv6网络，你可以把公网IPv4地址的某个端口静态映射到IPv6服务器的内网服务上,相当于把当年的IPv4端口映射搬到IPv6场景里。
这个方案在只有一个IPv4地址时特别实用，缺点是映射规则多了以后不好管理，而且只解决“外部访问内部”的问题，IPv6服务器主动外联IPv4资源时还得单独配NAT64出方向规则，多数情况下,企业不会把它当首选方案。
IPv6客户端访问IPv4业务：NAT64和DNS64是怎么配合的？
反过来的场景更常见，公司网络全面IPv6化，员工电脑只有IPv6地址，可老OA、老ERP系统还是只监听IPv4，怎么办？NAT64和DNS64这对组合拳就是为这个场景准备的。
完整访问流程长什么样
假设员工要访问 old-biz.example.com，这个域名只解析出IPv4地址 0.113.10,整条链路是这样走的：
- 客户端发起DNS查询，要
old-biz.example.com的AAAA记录。 - DNS64服务器没有查到AAAA记录，但查到A记录
0.113.10。 - DNS64把这条A记录“包裹”成一条合成AAAA记录，格式为
64:ff9b::前缀后接IPv4地址，64:ff9b::c000:20a。 - 客户端收到合成AAAA记录,把流量发往这个IPv6地址。
- 流量在IPv6网络里路由到NAT64网关，网关把IPv6头剥掉，目标地址还原为
0.113.10,用IPv4网络转发给老业务服务器。 - 老业务服务器回复后，NAT64网关再按原路把IPv4报文翻译回IPv6格式,回送给客户端。
整个过程对两端都是透明的，老服务器根本不知道自己在跟IPv6客户端打交道,客户端也感知不到对方是IPv4主机。
实操配置：开源方案就能落地
Linux环境下，DNS64用BIND9实现，NAT64用Jool内核模块实现,是目前比较成熟的组合。
BIND9的DNS64配置（named.conf）：
options {
dns64 64:ff9b::/96 {
clients { any; };
};
};Jool的NAT64配置（简化示例）：
jool instance add --netfilter --pool6 64:ff9b::/96
jool global update --pool4 203.0.113.10pool6 指的是IPv6翻译前缀，pool4 是网关对外访问IPv4网络时使用的IPv4地址池，Jool要求至少配置一个IPv4地址作为出口,纯粹的内网测试也可以填私网地址。
没有公网IPv4地址能跑通吗？
能，但要分场景，如果客户端和服务器都在内网，NAT64网关用私网地址池就行，如果IPv6客户端来自公网，网关就必须有公网IPv4出口地址，否则翻译出来的包回不去，这是选型时容易踩的坑,务必提前确认。
NAT64和DNS64有什么区别？分工不同，缺一不可
不少人把NAT64和DNS64混为一谈,实际它俩负责的层完全不同。
| 技术 | 工作层面 | 核心职责 |
|---|---|---|
| DNS64 | DNS协议层 | 为只有A记录的域名生成合成AAAA记录 |
| NAT64 | 网络IP层 | 在IPv6和IPv4地址之间做报文翻译 |
DNS64是“翻译员”，负责把IPv4地址“伪装”成IPv6地址给终端看；NAT64是“搬运工”，负责把真正的数据包从IPv6网络扛到IPv4网络,再把应答扛回来。
没有DNS64行不行？行，但客户端得手工使用 64:ff9b:: + IPv4地址的格式去访问，这对普通用户不现实，没有NAT64行不行？不行，DNS64合成了地址，流量根本送不到IPv4网络，协议栈直接丢弃报文。两者必须组合才算完整方案。
企业IPv6改造怎么选方案？避坑思路和预算控制
网络改造最怕一开始就搞大而全，先把“谁访问谁”理清楚,才能把钱花在刀刃上。
按需求场景对号入座
- 对外官网要被IPv6用户访问
：优先做双栈，如果云厂商不分配IPv4地址，就在前面挂一台支持双栈的负载均衡或者CDN,让边缘节点替业务蹭通互通问题。
- 内部IPv6终端要访问老IPv4系统：部署NAT64+DNS64，改动最小,老系统一行代码都不用动。
- 新建业务系统：默认做IPv6单栈部署，用前置NAT64网关兼容IPv4访问,避免以后二次改造。
- 开发测试环境：直接上反向代理，成本最低,一小时内能跑通。
成本怎么控制
双栈的成本远高于单栈，因为IPv4公网地址的使用费、备案费、安全策略都得按双份维护，反向代理最便宜，一台轻量云主机就够，NAT64网关设备方面，开源Jool和Tayga完全免费，商业硬件网关的优势集中在高并发吞吐和可视化运维，如果业务规模不大,没必要额外采购。
业内专家指出，IPv4地址资源枯竭是不可逆的，任何新采购的网络设备都应默认支持IPv6，避免几年后重复投资，行业共识认为，存量IPv4系统通过NAT64过渡是性价比最高的路径,等老系统自然退役后逐步收敛到IPv6单栈。
关于IPv4客户端访问IPv6服务器，你可能还关心这些
IPv4和IPv6地址能直接互通吗？
不能，两者协议头格式、地址长度完全不同，IPv6报文无法在IPv4网络上路由，必须经过双栈网关、NAT64翻译或代理设备转换,两端才可能通信。
NAT64一定需要DNS64配合吗？
常规场景下需要配合，DNS64负责把IPv4域名“翻译”成IPv6格式的合成地址，终端才能发起IPv6访问，如果应用直接使用IPv4地址访问，NAT64也支持通过转换格式访问，但操作门槛高,实际部署中很少这样用。
一台只有IPv6地址的服务器，IPv4老用户还能访问吗？
可以，前置一台双栈反向代理或NAT64网关即可，把IPv4请求翻译成IPv6转发给服务器，老用户无需任何配置,这也是目前云厂商为纯IPv6实例提供IPv4访问能力时采用的通用做法。
IPv4和IPv6的互通没有银弹，选型第一原则是弄清楚“谁缺谁”，IPv4地址池永远不会扩大，IPv6的占比只会越来越高，越早把地址转换机制搭好,后面的网络改造就越从容。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/584628.html
