虚拟机创建红帽（RedHat）时遇到网络配置错误，十有八九是网卡配置文件参数写错，或者NetworkManager服务状态没对齐，按“先看物理连接、再查虚拟机网卡、最后改系统配置文件”的顺序排查，多数情况下都能在几分钟内解决。
如果你正盯着终端里那行“Network is unreachable”发呆，别急着重装系统，网络配置错误在红帽虚拟机里相当常见，几乎每个刚接触Linux的运维新手都栽过跟头，我自己的排查经验是，十有八九都是小问题，但小问题卡人一整天的情况也太太多了。
虚拟机装红帽网络不通，问题通常出在哪
刚创建完红帽虚拟机,输完root密码进入系统，想装个nginx或者yum update一下，结果发现连不上网，这种情况很典型，问题根源往往不在操作系统本身，而是你在创建虚拟机或配置网络时，某个环节没对齐。
常见场景有两个：
- 用VMware Workstation创建红帽虚拟机，选了桥接模式，结果虚拟机拿不到和宿主机同网段的IP。
- 用VirtualBox创建红帽虚拟机,默认NAT模式，能ping通宿主机，但虚拟机上网总掉线。
这两种情况有一个共同点：你大概率没搞清“虚拟机网卡模式”和“红帽系统网卡配置”之间的关系。 虚拟机软件提供了网卡硬件，但IP地址、网关、DNS这些参数得由红帽系统自己读，而红帽系统读配置的顺序和工具链又比较多，任何一个环节出了问题，都会表现为“上不了网”。
行业共识认为,排查顺序不按“物理设备→虚拟设备→系统配置”来走，而是直接从系统配置文件开改，是造成问题扩大化的主要原因，比如你本机网卡没接好，虚拟机怎么改都没用；而你在system里敲了一百遍ifconfig也没用，真要改的是/etc/sysconfig/network-scripts/下的文件。
先确认宿主机网络是通的
排查红帽虚拟机网络问题,第一步不是进虚拟机，而是先确认宿主机本身能上网、能ping通网关，如果宿主机网络本身就不稳，虚拟机网络配置再正确也白搭。
确认步骤很简单：
- 宿主机ping网关,ping 114.114.114.114，看延迟和丢包率。
- 如果宿主机走的是有线网络,看看物理网线是否松动，交换机端口有没有亮灯。
- 如果是笔记本连着Wi-Fi，确认Wi-Fi没有断开、没有连到需要网页认证的公共热点。
宿主机网络确认OK之后,再去动虚拟机，别让虚拟机背锅。
进虚拟机后先ping网关
在红帽系统里打开终端,先看看IP有没有拿到：
ip addr
这个命令会列出所有网卡和已分配的IP地址,如果看到ens33或eth0这块网卡上没有inet地址，说明网卡完全没拿到IP，问题基本锁定在系统网络配置或者DHCP服务上。
然后ping一下网关地址,如果网关ping不通，看具体报错原因，是“Network is unreachable”还是“Destination Host Unreachable”，这两种报错意义完全不同，前者说明没有路由，后者说明路由存在但网关不通达排查方向也完全不同。
VMware桥接模式与NAT模式下，红帽虚拟机网卡配置怎么排查
VMware和VirtualBox是日常用得最多的两个虚拟化工具,你在虚拟机创建红帽时选择的网卡模式，决定了红帽系统应该用DHCP还是静态IP，也决定了你后续改文件的方式。
NAT模式下通则通，但注意DNS和默认网关
NAT模式默认走VMware虚拟网卡VMnet8,宿主机上会生成一个虚拟网关，通常是192.168.220.2之类的地址，虚拟机的IP由VMware内置的DHCP服务自动分配。
很多人在NAT模式下遇到的典型问题是：虚拟机可以ping通网关和宿主机，但域名解析不了，yum下载报错“Could not resolve host”，这种问题多半是DNS写错或者没写，改一下/etc/resolv.conf或者NetworkManager的DNS配置就行。
echo "nameserver 114.114.114.114" > /etc/resolv.conf
注意,在红帽系统里，NetworkManager默认会接管resolv.conf，你手动改完一旦重启网络服务可能被覆盖，更好的做法是改ifcfg文件里的DNS参数，或者用nmcli配。
桥接模式下，网段不对最容易出问题
桥接模式需要你把红帽虚拟机的网卡物理连接到宿主机所在的局域网,虚拟机拿到的IP必须和宿主机在同一网段，如果你创建虚拟机时选了桥接，但红帽系统里没开DHCP客户端，或者网卡配置文件里写死了和宿主不同段的静态IP，这一块就会出问题。
排查方式很简单：
- 在虚拟机内执行
ping 宿主机IP。 - 不通的话,跑
ip addr看IP段和宿主机是否一致。 - 不一致的话,编辑ifcfg文件，把IP改成同段内的空闲地址，重启网络服务。
顺便提醒一下,不少人把VMware桥接模式和无线网卡连在一起时经常掉线，这不是红帽系统的问题，是VMware桥接驱动和Wi-Fi的兼容性问题，你可以把网络模式改成NAT，稳定性会好很多，这也是很多人实际折腾后得出的结论。
红帽系统内部的网络配置文件，才是多数错误的根源
如果你能ping通网关,但yum源用不了，或者外网完全不通，那问题基本不在虚拟化层，而是红帽网络配置文件写错，红帽系的网络配置不像Debian那样集中在interfaces文件里，而是分散在/etc/sysconfig/network-scripts/中，网卡配置文件名为ifcfg-ens33、ifcfg-eth0之类。
这个文件里常见的坑有三个。
ONBOOT=no导致网卡悄然罢工
默认情况下,红帽安装过程中的网络配置如果没设置“自动连接”，安装完成之后网卡不会自启，多少次排查网络问题，最后发现配置文件里写着 ONBOOT=no，改成yes，重启网络服务，问题就消失了。
vi /etc/sysconfig/network-scripts/ifcfg-ens33 # 修改 ONBOOT=yes systemctl restart network
这里有个细节：RHEL/CentOS 8以上版本网络服务已改名为NetworkManager，你注意看服务状态即可。
IPADDR、GATEWAY、DNS三个参数不配套
即使ONBOOT=yes，网卡拿不到外网IP，你得检查是不是写死了静态IP但网关配错了，比如你的宿主网关是192.168.1.1，配置文件里GATEWAY写成了192.168.0.1，结局就是虚拟机ping不通任何外部地址。
建议严格对照宿主机网络信息来配：
- IPADDR＝宿主机同网段空闲IP
- NETMASK＝对应子网掩码，多数是255.255.255.0
- GATEWAY＝宿主机的网关地址，不是虚拟机网卡模式对应的虚拟网关
- DNS1=114.114.114.114
红帽系统对该文件的解析比较严格,参数名大小写都要对，比如是GATEWAY，不是Gateway，否则系统启动时静默忽略，报错信息也不明显。
如果ifcfg文件里BOOTPROTO=dhcp但又手动加了IPADDR参数，两者会相互冲突，多数情况下你手动设置的IP会生效，但默认网关可能来自DHCP，导致路由表错乱，这也是个隐藏雷区。
业内专家指出,在企业级RHEL运维中，网卡配置冲突导致的事故报告数量远高于网卡物理损坏，而这个冲突恰恰是最容易被忽略的。
NetworkManager覆盖问题和禁用后的惯用做法
红帽自RHEL 7起默认用NetworkManager接管网络配置，如果你习惯手动编辑ifcfg文件，改了之后没有重启NetworkManager服务，系统不会重新加载配置。
操作方式：
nmcli connection reload
或者
systemctl restart NetworkManager
如果不想用NetworkManager,也可以关闭它，改用network脚本：
systemctl stop NetworkManager systemctl disable NetworkManager systemctl start network
关闭NetworkManager后,ifcfg文件的变动会被network脚本直接读取，但你也失去了NetworkManager提供的自动连接管理等便利，如果你有云服务器或者虚拟机的管理需求，NetworkManager这个工具反而是很好的，相当于你的网络小管家，不必非要关掉。
用nmcli和系统日志快速定位网络故障
当你遇到网络配置错误,别一上来就改文件，先用命令确认状态，再动手，效率要高得多。
nmcli是红帽网络排查的利器
nmcli device status
可以看到网卡的连接状态和类型,如果显示unmanaged，说明NetworkManager不接管这个网卡，可能是ifcfg文件里写了 NM_CONTROLLED=no，或者NetworkManager服务本身没起来。
再看连接信息：
nmcli connection show
能直观看到是否有active连接,以及连接的UUID、设备、类型等，排查完之后，尽量用nmcli来修改配置，而不是傻乎乎地改文件，命令行直接设固定IP：
nmcli connection modify ens33 ipv4.method manual nmcli connection modify ens33 ipv4.addresses 192.168.1.100/24 nmcli connection modify ens33 ipv4.gateway 192.168.1.1 nmcli connection modify ens33 ipv4.dns 114.114.114.114 nmcli connection up ens33
这套操作步骤比手动编辑ifcfg文件要安全得多,能让你有效避免因为格式错引起的网络断连。
日志文件里藏着关键线索
如果改了配置仍然网络不通,那就去查看系统日志：
journalctl -u NetworkManager -f
重点关注有没有出现“connection failed”“failed to look up”“No DNS servers found”之类的关键字，有些情况下，你会看到网络状态反复循环“activating”到“activated”，多半是DNS解析延迟问题，可以直接忽略，等几秒再测。
查看路由表和DNS设置：
ip route cat /etc/resolv.conf
防火墙和SELinux可能暗中拦截网络请求
很多人在给红帽虚拟机配好静态IP后,发现外网能ping通，宿主机也能连SSH，但就是多台虚拟机之间互相Ping不通，这种情况多数不是网卡配置错误，而是firewalld防火墙或者SELinux在拦截。
systemctl status firewalld
如果防火墙开着,可以临时关闭验证问题：
systemctl stop firewalld
同理,SELinux如果处于enforcing状态，对网络服务是有额外的限制策略的，临时设为permissive模式，然后重启网络服务，再测试网络连通性：
setenforce 0
确认问题之后,再决定是永久关闭SELinux，还是添加一条符合场景的allow规则，反正虚拟机环境大多数是测试学习用，关闭防火墙和SELinux都无伤大雅。
网络配置常见问题解答
虚拟机里已经设置了静态IP，但红帽重启后IP又变回原来的了，是什么原因？
ifcfg文件里BOOTPROTO还是dhcp,这时即使写了IPADDR，重启后也会优先使用DHCP，把BOOTPROTO改成none，同时确认DEVICE参数和网卡实际名称一致，然后重启NetworkManager即可。
用VirtualBox桥接模式创建红帽虚拟机，虚拟机内能ping通宿主，但虚拟机外网不通，怎么排查？
先看虚拟机是否拿到和宿主机同一网段的IP,不是的话改为DHCP重新获取，确认网关正确之后，测试ping你的域名解析服务器，比如114.114.114.114，能ping通说明路由没问题，问题大概率在DNS配置，检查/etc/resolv.conf内容，在VirtualBox桥接模式下，DNS失效是出镜率最高的原因，解决办法是把红帽网卡的DNS手动指定为114.114.114.114或223.5.5.5。
红帽虚拟机配好了网络，yum安装软件总提示“Could not resolve host”，怎么处理？
最常见情况是网卡配置文件没有配置DNS参数,NetworkManager启动后覆盖了resolv.conf，用nmcli命令直接设置DNS即可，然后确认yum源的地址可用，红帽默认yum源是Subscription Manager订阅源，未注册时本身就可能开启失败，这也是网络报错的一个隐性环节，可考虑换成简米云或清华源镜像。