问
M9000防火墙AFTIPV4访问全国IPV6地址
1天前提问
- 0关注
- 0收藏，56浏览
你这个直觉对一半——单靠 AFT 裸转确实搞不定 DNS 那关，但 M9000 的 AFT 套件里自带 DNS64，配齐了是可以实现的，不是"完全不能"。你纠结的那个"解析成自己前缀也不通"，恰恰是 NAT64+DNS64 标准方案要解决的——关键不是让终端拿 IPv6 地址，而是让防火墙在 DNS 响应里把 AAAA 合成一个 IPv4 的"假地址"下发给内网，流量进来再 4→6 转出去。
先说清为什么你直觉上觉得"不能"
内网纯 IPv4 终端去访问
ipv6.baidu.com这种域名，正常流程是：- 终端发 A 查询 → 公网 DNS 返回"这域名只有 AAAA，没 A 记录"→ 终端直接放弃
- 哪怕你强行让 DNS 返回个地址（比如你自己前缀嵌的），终端拿到的是 IPv4 格式吗？不是，AAAA 是 128bit，IPv4 终端根本没法填进 socket
所以裸 AFT 不碰 DNS = 必死，你这个判断没错。但 M9000 的 AFT 不是裸的，它带
prefix-dns64这一项。M9000 能跑的标准解法：NAT64 + DNS64
整套逻辑是 RFC 6146 + 6147 那套，华三叫 AFT，M9000 Comware V7 全支持：
DNS 那关怎么过
- 内网 IPv4 终端的 DNS 必须指向 M9000（或 M9000 能劫持到 DNS 流量，走 DNS ALG）
- M9000 配
aft prefix-dns64 2000:: 32（举例），当 IPv4 终端来查***.***：- 防火墙代查，公网返回 AAAA
2001:db8:xx::1 - 防火墙按 DNS64 前缀合成一个 A 记录下发给终端，比如
192.0.0.1（well-known 的合成段）或者直接走 NAT64 前缀嵌 - 终端以为对方就是个普通 IPv4 地址，发 IPv4 包过来
- 防火墙收到 IPv4 包，目的 IPv4 → 按 IVI 前缀反算成真实 IPv6 目的，源 IPv4 → 按 NAT64 前缀转成 IPv6 源，扔去 IPv6 公网
AFT 转换侧（M9000 配置骨架）
# 1. 开 IPv6
ipv6
# 2. 内网口（IPv4侧）/ 外网口（IPv6侧）都要 aft enable
interface GigabitEthernet x/x/x # 内网
ip address 192.168.0.1 24
aft enable
interface GigabitEthernet y/y/y # 外网，已拿运营商 IPv6 地址
ipv6 address 2001:db8:1::1/64
aft enable
# 3. 三个前缀都要配
aft prefix-nat64 2012:: 96 # v4→v6 源转 / v6→v4 目的转
aft prefix-ivi 2013:: # v4→v6 目的转（嵌 IPv4 到 v6 目的）
aft prefix-dns64 2000:: 32 # DNS64 合成用
# 4. 转换策略
acl basic 2000
rule permit source 192.168.0.0 0.0.0.255
aft v4tov6 destination acl 2000 prefix-ivi 2013:: # v4 目的 → v6 目的
aft v4tov6 source acl 2000 prefix-nat64 2012:: 96 # v4 源 → v6 源官方"IPv4 网络访问 IPv6 Internet 服务器"的配置举例就是这套，M9000 文档里也有对应章节。
但你得知道几个硬限制（这才是重点）
⚠️ 不是所有场景都能通，下面几种会跪：
- 内网 DNS 没过 M9000 → DNS64 不生效，终端拿不到合成 A 记录，还是废。所以要么内网 DNS 指 M9000，要么 M9000 做 DNS 中继/代理代查
- 应用层嵌 IP（比如 SIP、FTP 被动模式、P2P）→ AFT 的 ALG 不一定全覆盖，M9000 对 FTP/DNS 的 ALG 有，但冷门协议可能跪
- 终端硬编码 IPv6 地址访问 → 你内网是 IPv4 终端，根本发不出 IPv6 包，这种需求本身不成立，无所谓
- DoH / DoT（DNS over HTTPS/TLS）→ M9000 解不了，终端直连 1.1.1.1:443 查 DNS，AAAA 响应回不来合成，废
- 只适用于"纯 IPv6 公网站点" —— 双栈站点（比如 baidu、taobao）终端 A 查询能拿到 A 记录，走普通 v4 出去就行，反而没问题；真正要吃 NAT64 的是那些只有 AAAA 没有 A 的站点（部分海外站点、IPv6-only 云主机）
回到你那句"解析成自己的前缀也不通"
如果你之前试的是：公网 DNS 返回 AAAA
240e:xxxx（运营商真实前缀），你内网 IPv4 终端根本没法用——这是对的，这条路走不通。正确姿势是"不要让终端看到 AAAA"：DNS64 在 M9000 本地把 AAAA 吃掉，合成 A 记录下发，终端全程不知道对面是 IPv6。所以"自己的前缀"不是指运营商前缀，是 M9000 上
prefix-dns64/ prefix-ivi这两个本地合成前缀，对外发包时 M9000 再把 IVI 前缀里的嵌的 IPv4 反算 + NAT64 前缀拼出真实 IPv6 源/目的。
结论：能实现，但必须满足"内网 DNS 流量过 M9000（DNS64 能生效）"这个前提，配
prefix-dns64 + prefix-ivi + prefix-nat64三件套 + v4tov6 策略就行。你现在是已经在 M9000 上试了 AFT 发现 DNS 那关过不去，还是还在方案阶段盘能不能做？如果是前者，把 display aft configuration和 DNS 走向贴一下，能直接看是 DNS64 没生效还是前缀配错了。
zhiliao_Gixe
六段
可以实现，需通过NAT64+DNS64技术。步骤如下：
1. 配置NAT64前缀（如2001:db8:1::/96）：
nat64 prefix 2001:db8:1::/96
2. 配置DNS64，将IPv4域名解析结果转换为NAT64前缀+IPv4地址的IPv6地址：
dns64 prefix 2001:db8:1::/96
dns64 enable
3. 配置IPv4到IPv6的NAT64转换策略，允许内网IPv4访问转换后的IPv6地址：
acl number 2000
rule permit source 192.168.0.0 0.0.255.255（内网IPv4段）
nat64 outbound 2000
4. 确保防火墙IPv6路由可达全国IPv6公网，且DNS服务器配置正确（指向支持DNS64的服务器或防火墙自身DNS64功能）。
注：需防火墙支持NAT64和DNS64特性，且出口需有IPv6公网地址。
1. 配置NAT64前缀（如2001:db8:1::/96）：
nat64 prefix 2001:db8:1::/96
2. 配置DNS64，将IPv4域名解析结果转换为NAT64前缀+IPv4地址的IPv6地址：
dns64 prefix 2001:db8:1::/96
dns64 enable
3. 配置IPv4到IPv6的NAT64转换策略，允许内网IPv4访问转换后的IPv6地址：
acl number 2000
rule permit source 192.168.0.0 0.0.255.255（内网IPv4段）
nat64 outbound 2000
4. 确保防火墙IPv6路由可达全国IPv6公网，且DNS服务器配置正确（指向支持DNS64的服务器或防火墙自身DNS64功能）。
注：需防火墙支持NAT64和DNS64特性，且出口需有IPv6公网地址。
暂无评论
一、核心结论：完全可以实现，你的顾虑「公网 AAAA 解析真实 IPv6 前缀不通」是未配置 DNS64 导致的认知误区
先解释你疑惑的根源
如果内网 IPv4 终端直接向公网 DNS 查询域名，DNS 返回
AAAA 2409:xxxx::（运营商真实公网 IPv6 地址），Windows/Linux 纯 IPv4 网卡无法识别 IPv6 地址，终端直接丢弃该记录，打不开网站。
M9000 的AFT+DNS64 联动会解决这个问题：- 内网终端只发 IPv4 的 A 记录查询；
- M9000 拦截 DNS 报文，同时向公网 DNS 查 A（IPv4）+AAAA（IPv6）；
- 若域名只有 IPv6 记录（纯 IPv6 站点），防火墙用自定义
dns64前缀合成一条 ** 虚拟 IPv4 地址（A 记录）** 下发给内网终端； - 内网终端只和虚拟 IPv4 通信，完全感知不到 IPv6；
- 报文送到 M9000 后，AFT 把虚拟 IPv4 目的地址通过
IVI前缀还原成真实公网 IPv6，源 IPv4 通过NAT64前缀转换成运营商分配的公网 IPv6 地址，转发至 IPv6 互联网。
关键：内网终端拿到的永远是防火墙虚拟合成的 IPv4，不会接触运营商真实 IPv6 前缀，彻底解决你担心的解析不通问题。
二、三大 AFT 前缀分工（缺一不可）
- aft prefix-nat64（/96）：源地址转换，内网 IPv4 → 公网 IPv6（动态 PAT，多终端复用运营商 IPv6 地址）
- aft prefix-ivi（固定 / 32）：目的地址转换，虚拟 IPv4 ↔ 真实公网 IPv6（把 IPv4 嵌入 IPv6 地址后半段）
- aft prefix-dns64（/96）：DNS64 合成专用前缀，用于生成内网可见的虚拟 IPv4 地址 三条前缀必须互不相同，避免地址冲突H3C。
三、硬性前置条件（不满足则无法部署）
- M9000 外网接口已从运营商获取公网 IPv6 地址 / 网段（PPPoE IPv6 或静态 IPv6）；
- 内网所有终端 DNS 请求必须经过防火墙（配置 DNS 透明代理，禁止终端直连外网 DNS）；
- M9000 全局开启
ipv6、内外网接口均开启aft enable； - 安全域策略放行：trust（内网 IPv4）→ untrust（IPv6 公网）双向 AFT 转换流量。
四、完整标准配置骨架（M9000 Comware V7）
1. 全局基础使能
h3c
system-view
# 全局开启IPv6
ipv6
# 开启DNS透明代理（拦截内网DNS，是DNS64生效前提）
dns transparent-proxy enable
# 定义三类独立前缀（示例，前缀可自定义，不可重复）
aft prefix-nat64 2012:: 96
aft prefix-ivi 2013::
aft prefix-dns64 2000:: 96
2. 接口配置（内网 Trust / 外网 Untrust）
h3c
# 内网IPv4接口 Trust域
interface GigabitEthernet 1/0/1
port link-mode route
ip address 192.168.1.1 255.255.255.0
aft enable
firewall zone trust
add interface GigabitEthernet 1/0/1
# 外网IPv6接口 Untrust域（运营商分配公网IPv6）
interface GigabitEthernet 1/0/2
port link-mode route
ipv6 address 2408:xxxx:xxxx::1/64
aft enable
firewall zone untrust
add interface GigabitEthernet 1/0/2
3. IPv4 访问 IPv6 转换策略（核心 v4tov6）
h3c
# ACL匹配内网所有IPv4用户
acl number 2000
rule permit source 192.168.1.0 0.0.0.255
rule deny
# 源地址动态NAT64：内网IPv4源转换为公网IPv6
aft v4tov6 source acl number 2000 prefix-nat64 2012:: 96
# 目的地址IVI转换：虚拟IPv4还原成真实公网IPv6
aft v4tov6 destination prefix-ivi 2013::
4. DNS64 自动合成虚拟 IPv4（解决纯 IPv6 域名解析）
h3c
# 匹配DNS64前缀流量，启用DNS64地址合成
aft v6tov4 prefix-dns64 2000:: 96
5. 安全策略放行 AFT 跨域流量
h3c
# 内网IPv4 → IPv6公网允许所有业务
security-policy
rule 10 permit source-zone trust destination-zone untrust service all
五、通信完整流程（解开你的解析疑问）
- 内网 192.168.1.100 访问纯 IPv6 站点
***.***，发起 DNS A 记录查询； - DNS 透明代理拦截报文，防火墙同时向公网 DNS 查询 A、AAAA；
- 公网 DNS 仅返回 AAAA 记录
2409::1234（真实 IPv6），无 A 记录； - M9000 通过
prefix-dns64合成虚拟 IPv4：10.0.0.1下发给终端； - 终端发起访问
10.0.0.1（仅 IPv4 报文，无 IPv6 感知）； - 报文到达防火墙，AFT 执行两层转换：
- 源 192.168.1.100 → NAT64 前缀 → 公网 IPv6
2012::c0a8:164 - 目的虚拟 10.0.0.1 → IVI 前缀 → 真实 IPv6
2013::a00:1（等价 2409::1234）
- 源 192.168.1.100 → NAT64 前缀 → 公网 IPv6
- 转换后的 IPv6 报文转发至运营商 IPv6 互联网；
- 回程报文反向转换，真实 IPv6 → 虚拟 IPv4，回传给内网终端。
六、常见故障排查点
- 域名打不开，仅纯 IPv6 站点失效
排查：未开
dns transparent-proxy enable，终端直连公网 DNS 拿到原生 AAAA 记录，纯 IPv4 网卡丢弃；必须强制 DNS 流量过防火墙。 - 能解析但无法连通 IPv6 网站
排查：内外网接口
aft enable漏配、三类前缀重复、安全域策略拦截、运营商 IPv6 路由不通。 - display session table 看不到 AFT 会话
排查：
aft v4tov6 source/destination策略未绑定正确前缀 / ACL。
七、补充说明
- 此方案仅支持内网 IPv4 主动访问公网 IPv6，公网 IPv6 无法主动发起访问内网 IPv4（如需双向互访需额外配置 v6tov4 策略 + IPv4 地址池）；
- 国内运营商 IPv6 网络全覆盖，配置完成后可正常访问全部纯 IPv6、双栈站点；
- 无需在内网终端做任何 IPv6 配置，全程纯 IPv4 单栈运行，对终端透明。
暂无评论
编辑答案
➤
✖
亲~登录后才可以操作哦!
确定
✖
✖
你的邮箱还未认证，请认证邮箱或绑定手机后进行当前操作
✖
举报
×
侵犯我的权益
>
对根叔社区有害的内容
>
辱骂、歧视、挑衅等（不友善）
侵犯我的权益
×
侵犯了我企业的权益
>
抄袭了我的内容
>
诽谤我
>
辱骂、歧视、挑衅等（不友善）
骚扰我
侵犯了我企业的权益
×
您好，当您发现根叔知了上有关于您企业的造谣与诽谤、商业侵权等内容时，您可以向根叔知了进行举报。 请您把以下内容通过邮件发送到 pub.zhiliao@h3c.com 邮箱，我们会在审核后尽快给您答复。
- 1. 您举报的内容是什么？（请在邮件中列出您举报的内容和链接地址）
- 2. 您是谁？（身份证明材料，可以是身份证或护照等证件）
- 3. 是哪家企业？（营业执照，单位登记证明等证件）
- 4. 您与该企业的关系是？（您是企业法人或被授权人，需提供企业委托授权书）
我们认为知名企业应该坦然接受公众讨论，对于答案中不准确的部分，我们欢迎您以正式或非正式身份在根叔知了上进行澄清。
抄袭了我的内容
×
原文链接或出处
诽谤我
×
您好，当您发现根叔知了上有诽谤您的内容时，您可以向根叔知了进行举报。 请您把以下内容通过邮件发送到pub.zhiliao@h3c.com 邮箱，我们会尽快处理。
- 1. 您举报的内容以及侵犯了您什么权益？（请在邮件中列出您举报的内容、链接地址，并给出简短的说明）
- 2. 您是谁？（身份证明材料，可以是身份证或护照等证件）
我们认为知名企业应该坦然接受公众讨论，对于答案中不准确的部分，我们欢迎您以正式或非正式身份在根叔知了上进行澄清。
对根叔社区有害的内容
×
垃圾广告信息
色情、暴力、血腥等违反法律法规的内容
政治敏感
不规范转载
>
辱骂、歧视、挑衅等（不友善）
骚扰我
诱导投票
不规范转载
×
举报说明
暂无评论