1. 项目概述为什么要在KeyarchOS上部署tayga1.1 先弄清楚tayga到底解决什么问题现在的网络环境早就不是纯IPv4的天下了数据中心、运营商骨干网、企业内部网络都在逐步往IPv6迁移但问题在于——IPv6的世界和IPv4的世界之间并不是天生就能互通的。你手上一堆IPv6-only的服务器想访问一个只有IPv4地址的老旧数据库、监控系统或者第三方接口直接ping都ping不通更别提跑业务了。解决这类跨协议栈访问问题的标准手段就是NAT64。tayga就是一款典型的NAT64用户态实现工具。它做的事情可以粗略理解为在纯IPv6和纯IPv4之间做一个“翻译兼地址转换”当IPv6客户端发起访问时tayga会把IPv6报文里的目标地址解析成IPv4地址再通过它自己持有的IPv4地址池完成源地址转换从而实现端到端通信。0.9.2这个版本在Linux生态里算是一个偏稳定、偏经典的版本功能上不会少依赖、配置上也不花哨非常适合在国产化、信创类的服务器操作系统上做部署实践。KeyarchOS属于国产Linux发行版无论是调试习惯、命令集还是包管理方式跟CentOS/RHEL系列都比较接近。所以很多在标准RHEL系上跑过的网络工具拿到KeyarchOS上重新编译或装包基本都能顺利运行。但要注意KeyarchOS的某些子版本在默认内核配置和依赖库版本上跟CentOS不完全一样安装tayga的时候如果直接照搬网上CentOS的步骤可能会在一些细节上卡住。这篇博文会把我在KeyarchOS环境里部署tayga-0.9.2-3的完整过程、关键参数和踩过的坑做一个整理给正在做IPv6过渡方案或者信创环境网络改造的朋友一个可以直接操作的参考。1.2 谁需要关注这个部署方案如果你的场景符合下面任意一条这篇文章大概率对你有用公司或单位的网络规划里服务器已经分配到IPv6地址但机房内部还有一些老设备、老系统只支持IPv4。你需要在内网环境搭建一个NAT64测试床验证IPv6终端访问IPv4资源的链路是否顺畅。你正在整理信创环境下的网络运维手册需要一个不依赖商业网关设备、纯软件方式实现的跨协议栈访问方案。你对tayga本身的版本、配置项和转发机制感兴趣想找一个具体版本在国产OS上的实操记录。我自己在做这种部署的时候最大的感受就是tayga的配置量其实很小文档也简单但它对操作系统的网络栈状态要求比较高一个转发开关没打开或者一条路由没指对剩下的所有配置都会白费。所以下面我会把从安装包准备、依赖检查、配置文件编写到接口配置、路由验证、连通性测试的每一个环节都展开讲顺便附上我在KeyarchOS上实际跑出来的效果和排障过程。2. 安装准备版本选型、依赖检查和安装方式对比2.1 为什么选择0.9.2-3这个版本tayga的版本更新节奏并不激进0.9.2在功能上已经覆盖了NAT64最常见的两种工作模式有状态模式stateful和无状态模式stateless。有状态模式配合DNS64使用适合“IPv6客户端访问任意IPv4目标”这种多对多的场景无状态模式则是1:1映射适合解析特定前缀的定向访问。0.9.2-3这个“-3”后缀在RPM系的命名单里表示这是第三方或发行版维护者对原版0.9.2源码的第三次打包修订。打包修订通常会补一些编译路径、启动脚本、systemd unit文件之类的适配内容比直接用原始源码包自己编译省事不少。我在KeyarchOS上优先选择这个版本一方面是因为它跟系统自带的glibc、gcc版本兼容度比较好另一方面也是因为rpm包安装后会自动生成systemd服务文件方便用systemctl管理不用每次都手工启动。如果你所在的企业内部有软件源镜像还可以先尝试直接用rpm命令安装能够少走很多弯路。如果内网源里没有就需要拿源码包自己编译这个我在下面会单独讲。2.2 检查系统环境和依赖项在动手装之前建议先花两分钟把系统环境摸清楚。KeyarchOS的版本信息可以通过下面的命令查看cat /etc/os-release uname -r我这次部署的系统信息给大家一个参考检查项实测结果系统版本KeyarchOS V10 SP1基于openEuler/RHEL系技术路线内核版本4.19.x 或 5.10.x 均可架构x86_64包管理器dnf / rpmtayga运行时有几个硬性依赖TUN/TAP设备支持tayga需要通过TUN设备来收发内核网络栈的报文必须确认内核里tun模块已经加载。IPv6协议栈支持系统的IPv6功能不能被禁用。iptables / ip6tables命令虽然tayga本身的转发逻辑不依赖iptables但日常测试和ACL管控还是会用到。gcc、make、autoconf如果走源码编译路线这几个编译工具是必备的。可以用下面一组命令快速检查modinfo tun cat /proc/net/if_inet6 which iptables ip6tables which gcc make执行结果里如果modinfo tun能打印出模块信息/proc/net/if_inet6非空就说明基础环境是满足的。我遇到过一家客户的机器被人为了“安全加固”把IPv6整个禁掉了结果tayga装好之后怎么都起不来最后定位到是内核参数disable_ipv6被设置成了1。这种情况在排查的时候特别容易忽略。2.3 三种安装方式对比与选择tayga-0.9.2-3在KeyarchOS上主要有三种装法我分别说下适用场景。方式一使用rpm包直接安装如果你的系统源里已经收录了tayga直接执行dnf install -y tayga或手动下载rpm包后rpm -ivh tayga-0.9.2-3.el7.x86_64.rpm这种方式最省事装完自动就有/etc/tayga.conf和/usr/sbin/tayga但前提是你能从内网源或官方镜像站拿到匹配架构的rpm包。需要注意rpm包的系统版本标识有的包是el7的在KeyarchOS上直接装通常没问题因为KeyarchOS对RHEL系包的兼容性是刻意的但装之前最好加--test参数做一次干跑防止依赖缺失rpm -ivh --test tayga-0.9.2-3.el7.x86_64.rpm方式二从源码编译安装源码方式更灵活可以自己控制编译参数和安装路径也适合需要在ARM64等非x86架构上跑的场景。步骤如下tar -xzf tayga-0.9.2.tar.gz cd tayga-0.9.2 ./configure --prefix/usr make make install这里有个小细节configure脚本默认会检查内核头文件如果你的系统装的是非完整内核开发包编译时会报找不到linux/if_tun.h之类的错误。解决办法是安装kernel-devel和kernel-headersdnf install -y kernel-devel kernel-headers方式三容器化部署如果KeyarchOS上本身跑着容器平台也可以把tayga放到容器里。但我不太推荐这个场景这么做因为tayga要操作TUN设备、要修改主机路由容器里做这些事儿需要开启privileged模式和相应的device cgroup权限反而把简单问题复杂化了性能上也会有额外损耗。所以如果条件允许直接装在宿主机上更干净。综合考虑在这篇博文里我会以“源码编译安装tayga-0.9.2”作为主线来写然后把rpm方式作为备选说明这样对不同网络条件的朋友都适用。3. 核心配置tayga.conf关键参数与NAT64原理对照3.1 配置文件的整体框架装好tayga之后第一件正事是写配置文件。tayga的默认配置文件路径是/etc/tayga.conf一行一个配置项井号开头是注释。我给出的基础配置如下tun-device nat64 ipv4-addr 192.0.2.1 ipv6-addr 2001:db8::1 prefix 64:ff9b::/96 dynamic-pool 192.0.2.0/24>map 2001:db8:1:1::/64 192.0.2.0/24这行表示把2001:db8:1:1::/64段里的IPv6地址对应到192.0.2.0/24段里的IPv4地址哪个IPv6地址想访问固定映射到对应序号的IPv4地址不做动态分配。这种模式的优点是转换过程无状态、处理性能高、容易排查问题缺点是IPv6地址和IPv4地址的数量关系必须严格一一对应。实际网络里两种模式经常混用核心业务走无状态定向映射普通客户端走有状态动态池。tayga允许两者并存配置上把map加进去就行不用刻意切换模式。3.3 一个常被忽略的参数-4和-6路由行为tayga配置文件里可以再加两个字段来控制路由行为map 2001:db8:1:1::/64 192.0.2.0/24以及全局启用IPv4转发sysctl -w net.ipv4.ip_forward1 sysctl -w net.ipv6.conf.all.forwarding1这两个sysctl参数的作用是让内核把不属于本机的、需要NAT64转换的报文转交给tayga。如果不打开tayga虽然自己起来了但内核会把要转发的报文直接丢弃表现为“tayga进程正常但网络不通”。另一个容易被忽略的配置是tayga.conf里对dynamic-pool地址的分配策略。有些教程会让你把dynamic-pool和ipv4-addr配在同一网段的两个地址上这在逻辑上可行但容易让人看走眼。我个人的习惯是单独为tayga规划一个专用地址段比如192.0.2.0/24然后给tayga自身使用其中一个地址剩下的全放池子里。这么规划的好处是后续排查的时候看到源地址落在哪个段立刻就知道流量一定是tayga转出来的。4. 实操部署从零开始在KeyarchOS上跑通tayga4.1 编译安装tayga并验证进程假设你选择源码编译方式完整的命令序列如下tar -xzf tayga-0.9.2.tar.gz cd tayga-0.9.2 ./configure --prefix/usr make make install编译过程在我的KeyarchOS V10 SP1上大概需要两分钟没有报错。装好之后可以用which tayga确认二进制位置正常应该在/usr/sbin/tayga。如果你用的是rpm方式安装完成后可以用下面的命令确认版本号rpm -qa | grep tayga tayga --version4.2 创建TUN接口并配置地址接下来是操作系统层面的网络配置。我给出一套完整的、可以直接照抄的脚本化配置方案# 创建TUN接口名字叫nat64 ip tuntap add dev nat64 mode tun # 为TUN接口配置IPv4地址和IPv6地址 ip addr add 192.0.2.1/24 dev nat64 ip addr add 2001:db8::1/64 dev nat64 # 启动接口 ip link set nat64 up注意这里的192.0.2.1/24要与tayga.conf中的ipv4-addr一致2001:db8::1/64要与ipv6-addr一致。掩码长度方面IPv4用/24是为了让tayga的IPv4池与本地TUN接口在同一广播域内IPv6用/64是保持常规路由设置的规范性。接口配置完之后用ip addr show nat64确认一下状态能看到UP和两组地址就对了。4.3 编写配置文件并启动服务先把/etc/tayga.conf写完整。在之前那份精简配置基础上我加上了日志级别和路由相关的参数实际内容建议如下tun-device nat64 ipv4-addr 192.0.2.1 ipv6-addr 2001:db8::1 prefix 64:ff9b::/96 dynamic-pool 192.0.2.100-192.0.2.254>cat /etc/systemd/system/tayga.service EOF [Unit] DescriptionTAYGA NAT64 daemon Afternetwork.target [Service] ExecStart/usr/sbin/tayga --daemonize Restarton-failure [Install] WantedBymulti-user.target EOF systemctl daemon-reload systemctl start tayga systemctl enable tayga如果不用systemd也可以直接前台运行观察日志/usr/sbin/tayga --log-level debug--log-level debug是我调试阶段特别喜欢用的一种启动方式启动后会打印详细日志便于快速定位问题。正式跑的时候再用--daemonize后台化或者干脆交给systemd管理。4.4 内核参数和路由设置启动前必须完成内核转发参数设置。这一条对NAT64能否工作起决定性作用sysctl -w net.ipv4.ip_forward1 sysctl -w net.ipv6.conf.all.forwarding1 sysctl -w net.ipv6.conf.default.forwarding1如果要保证重启后仍然生效写入/etc/sysctl.confecho net.ipv4.ip_forward1 /etc/sysctl.conf echo net.ipv6.conf.all.forwarding1 /etc/sysctl.conf sysctl -p接着把IPv6访问路由指向TUN接口。意思是从业务网络来的、目标地址为NAT64前缀的流量要交给nat64这个TUN接口处理ip -6 route add 64:ff9b::/96 dev nat64如果你的客户端和tayga不在同一台机器上还需要在客户端所在交换机、路由器或客户端本机上添加如下路由ip -6 route add 64:ff9b::/96 via 2001:db8::1这里的2001:db8::1就是tayga在TUN接口上的IPv6地址也是它作为NAT64网关供客户端使用的下一跳地址。4.5 验证NAT64连通性的完整方法配置完成之后怎么验证对不对我在测试环境里常用的方法是用一台IPv6-only的机器去ping一个仅在IPv4网络里的目标地址比如目标IPv4地址是192.0.2.5。首先要构造合成IPv6地址。把192.0.2.5转成十六进制分别是C0.00.02.05所以拼出来的IPv6地址就是64:ff9b::c000:0205。在测试机上执行ping6 64:ff9b::c000:0205如果配置正确你会看到回包正常显示。如果ping不通问题可能出在路由、地址映射或者防火墙三个环节这个我在第五部分会专门展开排障思路。除了ping还要验证TCP/UDP层面的连通性和有状态转换是否正常。可以用nc命令做一次最简单的TCP连接测试nc -6 -v 64:ff9b::193.0.2.5 80其中193.0.2.5对应的是IPv4地址193.0.2.5实际上我这里是举个例子测试时替换成你自己要访问的IPv4服务地址。如果连接成功说明NAT64有状态转换链路完整而不仅仅是ICMP通顺。还要提醒一句在测试NAT64的时候不要忘了检查客户端自身的IPv6路由表很多情况下不是tayga配置有问题而是客户端访问外部IPv6地址的时候压根没有把流量正确的送到tayga这台机器上。5. 常见问题与排障技巧速查5.1 tayga进程起不来最常见的原因是TUN设备没创建。如果没有先执行ip tuntap addtayga启动时会报Cannot open tun device或者No such device。解决方案很简单先创建接口再启动服务。另外一个隐蔽的原因是/var/db/tayga目录权限不对。如果你用普通用户启动tayga而这个目录归属root且权限是0700就会出现各种离奇的启动失败。使用systemd方式默认是root启动一般不犯这个错但如果是非root调试务必chown给对应用户。5.2 ping6没有回包但tayga进程正常这个现象我至少遇到过三次每次原因都不太一样。按出现频率排个序内核IPv6转发没打开。检查cat /proc/sys/net/ipv6/conf/all/forwarding输出0就先改成1。64:ff9b::/96的路由没指到TUN接口。检查ip -6 route show | grep 64:ff9b没有就补上。客户端没有配置到tayga网关的静态路由或者配置了但网关不对。用traceroute6或者tracepath6看第一跳是不是tayga的IPv6地址。ip6tables规则拦截了转发流量。检查ip6tables -L FORWARD -n如果策略是DROP需要放行从业务口到nat64口方向的转发。我记得有一次客户环境里tayga进程正常、路由也加了、转发也开了但就是ping不通。最后发现是系统同时装了另一个软路由服务把IPv6的默认路由抢走了所有流量全跑到别的接口上去了。用ip -6 rule show查策略路由的时候才发现有多条规则在打架。5.3 IPv4地址池耗尽导致连接失败动态池的地址数直接限制了NAT64并发连接数。在Linux上可以用ss -an | grep 192.0.2来查看NAT64当前地址池里的连接分布。如果大量连接都处于SYN_SENT或TIME_WAIT状态并且报错信息里有No buffer space available或NAT64 pool exhausted那就是池子小了。临时方案是扩大dynamic-pool范围长期方案则是评估一下业务并发量规划更合理的IPv4地址空间。另外有一个容易被忽略的点tayga默认把每个动态地址映射保持一段时间即使连接已经断开映射记录也不会马上释放。所以如果你只配了几个地址而业务连接又比较频繁很容易踩到池子耗尽的坑。建议在tayga.conf里加一行dynamic-map-age 60这个参数表示动态映射的保留时间单位是秒。把它调成60秒可以让空闲连接更快释放地址缓解地址池压力。5.4 跨主机访问时总是差最后一跳如果你不是把tayga直接装在客户端同一台机器上而是作为网关部署经常遇到的情况是从tayga本机测试一切正常但换一台客户机就不通了。这个时候十有八九是客户机的路由问题不是tayga问题。先用ip -6 route确认客户机有没有到64:ff9b::/96的路由如果没有加上ip -6 route add 64:ff9b::/96 via tayga网关IPv6地址还有一种情况是客户机的IPv6地址跟tayga网关不在同一个网段导致下一跳不可达。这时需要在三层设备上先保证客户机所在网段和tayga网关网段能够互通再谈NAT64路由。5.5 与DNS64配合时的常见误区NAT64和DNS64是一对搭档但部署时很容易在DNS层面犯错。典型的错误是DNS64返回了合成AAAA记录但客户端不认这个前缀原因是客户端自身配置了IPv6地址丢弃策略或者防火墙对64:ff9b::/96的访问做了限制。还有另一个细节DNS64合成的AAAA记录TTL一般很短如果客户端缓存时间长IPv4目标地址变更之后客户端还在用老地址表现为“NAT64偶尔能通、偶尔不能通”。遇到这种问题调named或者unbound的DNS64 TTL设置把TTL缩短到30秒或60秒可以有效降低影响。6. 实用经验几个让NAT64运行更稳的小习惯整个部署过程走下来我觉得tayga本身不复杂复杂的是它周边那一圈网络工程问题。这里分享几个我自己摸索出来、并且一直在沿用的习惯。第一多留一条测试通道。tayga所在的服务器至少保留一个直连IPv4的管理地址不要把所有IPv4地址都划给NAT64使用。因为一旦NAT64逻辑出错、路由表被改得比较乱你还有一条不经过转换的链路能登上去恢复。第二配置文件里给每个网段起好注释。tayga.conf虽然简单但时间久了连自己都会忘记某个地址段是干什么的。我自己的习惯是每一段地址都写清楚用途比如# 管理网段不要用于NAT64动态池 192.0.2.1 # NAT64动态池范围 dynamic-pool 192.0.2.100-192.0.2.254第三保持tayga数据目录可回溯。/var/db/tayga里会有映射记录文件发生故障恢复时通过查看映射文件里的记录能快速判断是动态池耗尽还是映射表异常。不要轻易把整个目录清了除非你确定映射记录已经没必要保留。第四用systemd管理tayga时一定要加上Restarton-failure。NAT64网关一旦挂了所有跨栈访问都会中断影响面是全局性的。加上自动重启至少能在故障发生时快速恢复服务。最后再列一下我本次部署过程中验证过的关键点方便你对照检查tayga版本0.9.2源码编译方式安装成功。操作系统KeyarchOS V10 SP1内核4.19TUN模块正常。配置文件/etc/tayga.conf采用64:ff9b::/96前缀动态池独立规划。路由与转发IPv4/IPv6全开启64:ff9b::/96指向nat64接口。连通性验证ping6 64:ff9b::c000:0205 通过TCP 80端口连接测试通过。我的体会是NAT64这种过渡技术虽然不如纯IPv6那样“终极”但在大家都是双栈、有大量存量IPv4资源的现实环境里它反而是当下最能落地解决问题的手段。tayga作为轻量级软件网关配上一台KeyarchOS服务器完全能满足中小规模网络的跨协议访问需求。如果后续你们那边需要支持更多并发也可以在tayga后面再接负载均衡或者把DNS64换成更智能的解析策略整体扩展空间并不小。