linux中修改mac地址必须严格按down→address→up三步执行，跳过任一步将报错；克隆后需同步更新udev规则、ifcfg配置及networkmanager设置，否则因mac与设备名不匹配导致网络失效。
Linux中修改网卡MAC地址，尤其在VMware等虚拟化环境克隆后，不能只改IP，必须同步处理MAC——否则会因地址冲突或设备识别错乱导致网络失效。核心原则是：MAC变更必须配合接口状态控制、驱动层确认、以及上层网络管理服务协调。
克隆后网卡识别错乱：先理清eth0和eth1谁在用
VMware克隆会自动生成新MAC，并触发udev规则重命名网卡。常见现象是：
- ifconfig 或 ip addr 只显示 eth1，不显示 eth0
- /etc/sysconfig/network-scripts/ifcfg-eth0 文件仍存在，但HWADDR与实际eth1的MAC不匹配
- 启动网络服务失败，报错 “Device eth0 has different MAC address than expected”
本质是系统“认人不认卡”：内核根据/etc/udev/rules.d/70-persistent-net.rules中MAC→名称映射绑定设备名，而ifcfg-eth0仍指向旧MAC。解决路径是统一指向新网卡。
临时修改MAC（重启即失效）：三步不可省略
适用于测试、调试或单次伪装，必须严格按顺序执行（以ens33为例）：
-
关闭接口：
sudo ip link set dev ens33 down -
写入新MAC：
sudo ip link set dev ens33 address aa:bb:cc:dd:ee:ff -
启用接口：
sudo ip link set dev ens33 up
跳过任意一步都会报 Device or resource busy 或 Invalid argument。改完用 ip link show ens33 | grep ether 查软状态，再用 sudo tcpdump -i ens33 -c 1 -e | head -1 抓包验证真实发出帧的源MAC——后者才是生效依据。
永久生效：避开NetworkManager干扰和配置文件陷阱
直接改ifcfg-eth0里的HWADDR字段无效，系统启动时会校验失败。正确做法分两类：
-
若用NetworkManager管理：停服务后修改连接配置
sudo systemctl stop NetworkManagersudo nmcli connection modify "Wired connection 1" 802-3-ethernet.mac-address aa:bb:cc:dd:ee:ffsudo nmcli connection down "Wired connection 1" && sudo nmcli connection up "Wired connection 1" -
若用传统network服务（CentOS 6/7）：
编辑 /etc/udev/rules.d/70-persistent-net.rules，注释掉旧eth0规则，把新网卡规则的NAME="eth1"改为NAME="eth0"；
再编辑 /etc/sysconfig/network-scripts/ifcfg-eth0，将HWADDR值更新为新MAC，同时确认ONBOOT=yes；
最后重启或运行sudo systemctl restart network
克隆虚拟机专用流程：MAC+IP一起清
VMware克隆后建议按此顺序操作（以CentOS/RHEL系为例）：
- 关机状态下，在VMware设置里点击网卡 → 高级 → “生成MAC地址”，确保底层硬件层已刷新
- 开机后先查真实网卡名：
ip -br a或dmesg | grep -i eth - 根据实际网卡名（如ens160），编辑对应ifcfg文件，修改
IPADDR（保持同网段）、BOOTPROTO=static（避免DHCP租约冲突） - 同步更新该ifcfg文件中的
HWADDR为ip link show ens160 | grep ether输出值 - 清理udev规则或重命名规则文件（如重命名为
70-persistent-net.rules.bak），防止下次启动再次错绑 - 重启网络或整机
