RED韵把一台刚装好的Linux主机，从"能开机"变成"能干活、能抗折腾"的服务器，需要跨过的门槛其实没有想象中那么高，但也绝不只是敲几条命令的事。这次要聊的是一套典型的综合服务器配置：网络、DNS、Apache、vsFTP、Samba、VNC，再加上firewalld和SELinux全程开启。这个过程我反复带人练过，也自己踩过不少坑，所以打算把整套配置的思路、步骤和排查心得完整写下来。无论你是刚学Linux的在校生，还是刚接手服务器维护的初级运维，这套配置练完之后，你对"服务为什么起不来""客户端为什么连不上"这类问题的判断力会明显上一个台阶。
这套配置之所以值得做，是因为它几乎覆盖了服务器日常管理的所有核心场景：对外提供网页访问，对内提供文件共享，远程管理需要图形界面，名称解析要自建DNS，而所有这些服务又同时被防火墙和SELinux约束着。很多人在单点服务上能顺利跑通，一旦把几个服务叠在同一台机器上，就被各种端口冲突、安全上下文问题、防火墙拦截搞得焦头烂额。这篇文章不会只给你一堆命令，而是把每个环节的"为什么"讲清楚，尤其是firewalld和SELinux这两个最容易劝退新手的部分。
1. 整套配置的架构思路：为什么要这么组合
1.1 服务之间的关系与配置顺序
这套配置里的几个服务，表面上看是各自独立的软件，实际上彼此之间有着隐性的依赖关系。DNS负责把名字解析成IP，Apache和vsFTP是内容发布的出口，Samba服务的是内网Windows客户端，VNC则是远程管理员的眼睛。它们都跑在同一张网卡、同一个防火墙策略、同一套SELinux上下文里，所以配置顺序相当重要。
我最开始练手的时候，上来就先装Apache，浏览器里看到测试页就觉得自己搞定了，结果后面开启SELinux enforcing之后，所有页面瞬间变403。原因很简单：Apache的DocumentRoot目录虽然赋予了正确的读权限，但缺少对应的httpd_sys_content_t类型标签。这种教训反复出现过多次，后来我总结出了一套合理的配置顺序：先做网络和DNS，确保主机身份和名称解析都正常；再配置firewalld，把要开放的端口和服务按需放行；接着处理SELinux，确认安全策略处于可控状态；最后才去装和调各个应用服务。安全机制要在一开始就站稳，不要把全部希望寄托在最后一刻再慢慢补。
反过来，如果你先把所有服务都跑起来，再回头开SELinux，这时候日志里会涌出大量AVC拒绝记录，你很难分清哪些是正常的隔离行为、哪些是真正需要放行的请求。换到先开安全机制、再按需放行的思路，每次引入一个新服务，你只需要观察它对应的那一条策略变化，定位成本会低很多。
1.2 安全基线与最小权限
这套配置叫"安全服务器配置"，安全基线的核心不是用防火墙把所有端口全封死，而是明确"哪些服务必须对外开放，哪些只允许内网访问"。我在配置过程中会先列一张端口清单，把每个服务的通信路径画清楚。
服务与端口对应关系可以整理成下面这张表：
| 服务 | 监听端口 | 客户端访问方式 | 放行策略 |
|---|---|---|---|
| SSH | 22/tcp | 远程命令行管理 | 仅管理网段 |
| DNS | 53/tcp + 53/udp | 域名解析查询 | 按需开放 |
| Apache | 80/tcp | 浏览器/HTTP客户端 | 对外发布 |
| vsFTP | 21/tcp + 30000-30100/tcp | FTP客户端 | 按需开放被动端口 |
| Samba | 139/tcp + 445/tcp | Windows或smbclient | 仅内网 |
| VNC | 5901/tcp | VNC客户端 | 仅管理网段 |
这张清单的好处是，你在配firewalld的时候不用凭感觉放行，每一笔规则都能对着表去核对。另外一个原则是账户权限最小化：VNC远程桌面尽量用普通用户而不是root，FTP共享的目录不要用匿名可写，Samba的共享目录只授予必要的组权限。这些细节看起来琐碎，但在实际生产环境里，很多被勒索软件、蠕虫病毒打穿的服务器，往往就栽在"Samba匿名可写"或者"FTP目录权限过大"这种不起眼的地方。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 网络与DNS：所有服务的地基
2.1 网卡静态配置：传统文件和nmcli两条路
服务器和家用电脑不一样，它需要一个固定不变的内网IP，这样客户端才能真正通过IP或主机名访问服务。我在CentOS 7环境里一般用ens33这块网卡，设置成192.168.10.10，网关指向192.168.10.2。
传统方法就是直接编辑网卡配置文件/etc/sysconfig/network-scripts/ifcfg-ens33，把BOOTPROTO改成static，补上IPADDR、NETMASK、GATEWAY和DNS。一个最小可用的配置长这样：
ini复制TYPE=Ethernet
BOOTPROTO=static
NAME=ens33
DEVICE=ens33
ONBOOT=yes
IPADDR=192.168.10.10
NETMASK=255.255.255.0
GATEWAY=192.168.10.2
DNS1=192.168.10.10
但要提醒一句，CentOS 7和RHEL 7默认由NetworkManager管理网络连接，如果你只是改了ifcfg文件然后用systemctl重启network，有时候会出现配置不生效或者被NetworkManager回滚的情况。更稳的做法是用nmcli操作：
bash复制nmcli con mod ens33 ipv4.method manual ipv4.addresses 192.168.10.10/24 ipv4.gateway 192.168.10.2 ipv4.dns 192.168.10.10
nmcli con up ens33
这里有一个细节要留意：如果这台机器同时也扮演DNS服务器角色，那在本机上优先使用自己作为DNS没有任何问题，但前提是named服务已经正常启动。很多初学者在配置阶段就把DNS指向了自己，等named服务还没起来的空窗期，连yum都跑不了，因为域名解析全联不通了。稳妥的方案是先指向一个可用的公共DNS，确认网络和软件源没问题后，再切回本地DNS验证效果。
2.2 /etc/hosts的妙用与客户端DNS的坑
在正式配置BIND之前，先用/etc/hosts做好本机名称解析很有帮助。hosts文件有着最高解析优先级，它的作用是给服务器打上"身份标签"，避免服务启动和客户端访问时因为名字解析不到而出错。
text复制127.0.0.1 localhost localhost.localdomain
192.168.10.10 server.example.com server
192.168.10.20 client.example.com client
这里用example.com作为练习域，不涉及任何线上真实域名。hosts文件在排错阶段尤其好用：客户端连不上服务器时，先ping一下server.example.com，如果通了说明网络和名称解析都正常，再去排查具体服务。但也要知道hosts是静态的，服务器IP一旦变更，所有客户端都要同步更新，属于"应急方案"而不是"长期方案"。
最近有个热词提到"Linux修改DNS后重启网络就被还原"，这是非常典型的问题。原因在于NetworkManager会根据DHCP或网卡配置自动重新生成/etc/resolv.conf，手工改动的nameserver条目在重启网络时会丢失。解决办法有两个：偏好做法是直接用nmcli设置DNS，让NetworkManager自己把配置写进去；如果你的网卡配置是传统ifcfg方式，就在ifcfg-ens33里加一行PEERDNS=no，阻止DHCP下发的DNS覆盖本地配置。
2.3 BIND主DNS：named.conf与区域文件写法
自建DNS服务器通常是为了内网解析，把server.example.com、client.example.com这些私有的名字映射到对应IP，而不需要全部依赖外部DNS。安装BIND非常简单：
bash复制yum install -y bind bind-utils
安装完之后要修改/etc/named.conf，核心是让named服务监听所有接口的53端口，并且允许本网段客户端发起查询。配置片段如下：
bash复制listen-on port 53 { any; };
allow-query { 192.168.10.0/24; localhost; };
zone "example.com" IN {
type master;
file "example.com.zone";
};
zone "10.168.192.in-addr.arpa" IN {
type master;
file "10.168.192.zone";
};
区域文件放在/var/named/目录下，正向区域example.com.zone最基本的记录格式是：
text复制$TTL 1D
@ IN SOA ns.example.com. admin.example.com. (
2025010101 ; serial
1D ; refresh
1H ; retry
1W ; expire
3H ) ; minimum
IN NS ns.example.com.
ns IN A 192.168.10.10
server IN A 192.168.10.10
client IN A 192.168.10.20
www IN CNAME server
每次修改区域文件后，一定要记得执行两步验证：
bash复制named-checkconf /etc/named.conf
named-checkzone example.com /var/named/example.com.zone
这里有一个初学者最容易踩的坑：区域文件默认属主是root，但named进程以named用户身份运行。如果区域文件权限是600且属于root，named进程根本读不到；正确做法是让文件属主为root，属组改成named，权限设成640。否则服务启动不报配置错误，但日志里会频繁出现open: permission denied，然后区域一直加载失败。确认无误后启动服务：
bash复制systemctl enable named
systemctl start named
然后用本机验证解析结果：
bash复制dig @127.0.0.1 www.example.com
dig命令能直观显示DNS响应时间和答案来源，比nslookup更详细。看到答案部分返回192.168.10.10，说明DNS服务已经正常工作了。
3. VNC远程管理：图形化也能安全交付
3.1 TigerVNC部署与systemd托管
服务器通常没有接显示器，Linux管理员更多依赖SSH命令行。但总有需要图形界面的场景，比如用浏览器登入管理后台、打开图形化性能监控工具，这时候VNC就成了刚需。CentOS 7下最常用的是TigerVNC。
安装命令只有一行：
bash复制yum install -y tigervnc-server tigervnc-server-module
第一步先给运行VNC的普通用户设置独立的VNC访问密码。这里不建议直接用root来跑VNC，因为VNC流量虽然是加密的，但一旦密码泄露，就等于把整个服务器的图形控制台交出去了。用普通用户练手更合理：
bash复制useradd vncuser
passwd vncuser
su - vncuser -c "vncpasswd"
vncpasswd会让你输入两次密码，并询问是否设置只读密码，选no即可。密码文件生成在用户家目录的.vnc/passwd，权限自动是600，不要随意改动。
CentOS 7用systemd统一管理VNC服务，提供了模板单元vncserver@.service，将@替换成显示编号。端口号从5900开始算，:1对应5901端口。复制模板并修改：
bash复制cp /lib/systemd/system/vncserver@.service /etc/systemd/system/vncserver@:1.service
编辑该文件，把<USER>占位符替换成实际用户名：
ini复制[Unit]
Description=Remote desktop service (VNC)
After=syslog.target network.target
[Service]
Type=forking
User=vncuser
Group=vncuser
WorkingDirectory=/home/vncuser
PIDFile=/home/vncuser/.vnc/%H%i.pid
ExecStartPre=/bin/sh -c '/usr/bin/vncserver -kill %i > /dev/null 2>&1 || :'
ExecStart=/usr/sbin/vncserver %i -geometry 1280x800
ExecStop=/usr/bin/vncserver -kill %i
[Install]
WantedBy=multi-user.target
重新加载服务并启动：
bash复制systemctl daemon-reload
systemctl enable vncserver@:1.service
systemctl start vncserver@:1.service
验证端口是否正常监听：
bash复制ss -tlnp | grep 5901
看到5901端口处于LISTEN状态，VNC部分就成功了。
3.2 VNC的常规坑：黑屏、端口与认证
VNC连接时最常见的现象是：客户端能连上，但屏幕是黑灰一片。这通常不是VNC本身的问题，而是系统里根本没有安装桌面环境。最小化安装的CentOS默认没有GNOME或者KDE，VNC起了一个空壳。解决办法是安装一个桌面组：
bash复制yum groupinstall "GNOME Desktop"
安装完桌面后重启VNC服务，再次连接就能看到完整的图形界面了。这一步比较耗时，建议在配置其他服务之前先装好，避免反复重启等待。
端口放行也是高频坑点。如果不开放5901端口，VNC客户端连过来会一直卡在连接超时。用firewalld放行时，既可以直接按端口操作，也可以按服务名操作：
bash复制firewall-cmd --permanent --add-port=5901/tcp
firewall-cmd --reload
修改VNC密码之后，一个容易被忽略的步骤是重启vncserver服务，因为密码文件在会话启动时读取，改了密码不重启，旧密码依然生效。另外家目录下.Xauthority文件的权限也经常惹麻烦，如果启动日志里提示认证错误，先检查.vnc目录和.Xauthority的属主与权限是否属于vncuser本人。
4. Samba与vsFTP：文件共享双通道
4.1 Samba配置要点与SELinux文件上下文
Samba是一套面向内网的Windows文件共享服务，用的也是SMB/CIFS协议。它和FTP最大的区别在于：Samba面向局域网，讲究用户凭证和域环境，Windows资源管理器可以直接挂载；FTP则更通用，适合跨平台的文件下载和上传。在这套配置里两个都要装，因为它们的应用场景不同。
安装Samba：
bash复制yum install -y samba samba-client
Samba的配置集中在/etc/samba/smb.conf，一个最小可用的共享配置如下：
ini复制[global]
workgroup = WORKGROUP
security = user
passdb backend = tdbsam
[share]
path = /opt/share
browseable = yes
writable = yes
valid users = smbuser
security = user表示每个访问共享的用户都需要在Samba中建立独立的账户密码。系统用户与Samba密码并不是自动同步的，所以要单独用smbpasswd登记：
bash复制useradd smbuser
smbpasswd -a smbuser
共享目录需要提前建好：
bash复制mkdir -p /opt/share
chown smbuser:smbuser /opt/share
chmod 2770 /opt/share
注意这里用的是2770，其中的2是SGID位，让新创建的文件自动继承所属组，多人协作时特别好用。
Samba在SELinux环境下的坑非常隐蔽。一个常见的现象是：Windows能看到共享目录，但点进去提示没有权限，系统日志里却查不到明显的拒绝记录。原因多半是SELinux上下文不对。自定义的/opt/share目录默认继承的是default_t类型，而Samba进程只能访问samba_share_t类型标记的目录。解决办法是用semanage定义上下文再恢复标签：
bash复制yum install -y policycoreutils-python
semanage fcontext -a -t samba_share_t '/opt/share(/.*)?'
restorecon -Rv /opt/share
之后用ls -dZ /opt/share看一下，类型应该变为samba_share_t。验证配置后重启服务：
bash复制testparm
systemctl enable smb
systemctl start smb
防火墙放行Samba的139和445端口，可以直接用服务名：
bash复制firewall-cmd --permanent --add-service=samba
firewall-cmd --reload
客户端测试时，Linux下用smbclient，Windows下直接在资源管理器地址栏输入\\192.168.10.10\share，然后输入smbuser的密码。
4.2 vsftpd安全配置与被动端口收口
vsftpd是CentOS自带的高安全性FTP服务，配置起来比Samba更直接。安装：
bash复制yum install -y vsftpd
/etc/vsftpd/vsftpd.conf里需要关注这几个参数：
ini复制anonymous_enable=NO
local_enable=YES
write_enable=YES
local_umask=022
chroot_local_user=YES
allow_writeable_chroot=YES
pasv_min_port=30000
pasv_max_port=30100
anonymous_enable=NO是必要的安全底线，默认关闭匿名访问。chroot_local_user=YES把用户限制在自己的家目录里，不让登录用户跑到系统其它目录闲逛，提升安全性的同时也能避免很多越权操作。
这里要特意强调allow_writeable_chroot=YES这个参数。vsftpd从3.0.2版本开始，如果chroot目录本身可写，会导致用户一登录就收到500 OOPS: vsftpd: refusing to run with writable root inside chroot()的报错。FTP用户的家目录默认恰好就是可写的，所以必须显式允许这个行为，否则服务等于瘫痪。这是一个极高频的报错，属于一问一个准的坑。
FTP的被动模式是另一个必须提前规划的点。默认vsftpd被动模式端口范围是1024以上的随机端口，防火墙根本没法精准放行。把范围收窄到30000到30100，防火墙里就只需要放行这两个区间加21端口：
bash复制firewall-cmd --permanent --add-service=ftp
firewall-cmd --permanent --add-port=30000-30100/tcp
firewall-cmd --reload
SELinux这边，最简单的设置是打开ftpd_full_access布尔值：
bash复制setsebool -P ftpd_full_access 1
但这属于比较粗放的放行方式，生产环境更推荐按需调整，比如ftpd_use_passive_mode对应被动模式，allow_ftpd_full_access对应上传下载权限。练习环境用全量布尔值不影响理解，但你要知道它放宽了什么。上传失败时，最常见的问题就在目录权限和SELinux上下文上，去/var/log/audit/audit.log里查AVC记录基本都会有准确提示。
5. Apache Web服务：业务流量入口
5.1 虚拟主机与自定义目录的SELinux上下文
Apache是整套配置里最容易被验证的服务，因为浏览器本身就是现成的测试客户端。安装：
bash复制yum install -y httpd
默认安装后，只要放行80端口并启动服务，浏览器访问服务器IP就能看到Apache测试页：
bash复制systemctl enable httpd
systemctl start httpd
firewall-cmd --permanent --add-service=http
firewall-cmd --reload
实际使用中很少直接拿默认根目录跑业务，一般要配置虚拟主机。在/etc/httpd/conf.d/下新建一个server.example.com.conf，内容如下：
apache复制<VirtualHost *:80>
ServerName server.example.com
DocumentRoot /srv/www
ErrorLog logs/server.example.com-error_log
CustomLog logs/server.example.com-access_log combined
</VirtualHost>
这里如果DocumentRoot指向的不是默认的/var/www/html，而是一个自定义目录比如/srv/www，SELinux就会出手拦截。Apache进程只允许读取标记为httpd_sys_content_t类型的内容，普通目录默认是default_t，浏览器访问时看到的是403或者空白页。解决办法：
bash复制mkdir -p /srv/www
echo "<h1>Test Page</h1>" > /srv/www/index.html
semanage fcontext -a -t httpd_sys_content_t '/srv/www(/.*)?'
restorecon -Rv /srv/www
然后curl http://192.168.10.10/做本地验证。如果自定义目录没有正确设置上下文，curl多半会直接拿到403，同时/var/log/httpd/error_log里会留下权限相关错误。
还有一个容易混淆的点：SELinux的布尔值控制的是"是否允许越界访问"这类策略行为，文件上下文控制的是"哪个目录能以哪种身份被访问"。自定义目录的访问权限问题优先查文件上下文，不要一上来就开httpd_can_network_connect这种全局布尔值。
5.2 Apache启动失败的常见原因
最近热词里反复出现"Apache启动失败，请检查相关配置"之类的话，实际上Apache启动失败的原因就那么几种，是可以快速排查的。
首先是配置文件语法错误。每次修改httpd.conf或虚拟主机配置后，在重启之前先跑一次：
bash复制httpd -t
这个命令会直接输出配置语法检查结果，如果有错误会精确到文件名和行号。语法错误是最容易发现的问题，报错信息直白，按提示修复即可。
其次是端口占用。80端口一旦被其它进程占用，Apache就会报Address already in use。排查命令：
bash复制ss -tlnp | grep :80
如果被占用，优先查是什么程序占用了端口，不要盲目kill进程。很多同学之前在练习环境里残留了nginx或其他Web服务器，正好卡在80端口，改配置改半天也没用。
第三是SELinux上下文问题。这一点前面提到过，启动通常没有问题，但客户端访问时权限不足。严格来说这不属于"启动失败"，但对使用者来说行为一致：网站完全打不开。定位技巧是看Apache的错误日志和时间节点，配合SELinux AVC日志，基本能确定是上下文还是布尔值的问题。
第四是DocumentRoot目录不存在或者无读权限。Apache在语法检查阶段会对目录做存在性校验，如果目录缺了会直接warning，启动后访问则是404。目录权限要给到Apache运行用户可读，自定义目录不要用700这种把自己锁死的权限。
6. firewalld与SELinux：安全机制实战收口
6.1 firewalld区域理解与规则持久化
firewalld是CentOS 7默认的动态防火墙，它的逻辑不是简单的"端口开/关"，而是按区域划分信任等级。默认区域是public，这是一个低信任区域，外部流量只有显式放行的服务才能进来。还有internal、trusted这些区域，信任级别从低到高。
理解三个关键概念就够用了：zone、service、port。zone是一组规则的集合，service是常见端口/协议的封装，比如http服务对应80/tcp，ftp对应21/tcp外加一些额外端口。操作示例：
bash复制firewall-cmd --state
firewall-cmd --get-active-zones
firewall-cmd --list-all
firewall-cmd --permanent --add-service=http
firewall-cmd --permanent --add-port=30000-30100/tcp
firewall-cmd --reload
这里最核心的坑在--permanent和--reload的配合。不带--permanent的规则只修改运行时配置，立刻生效但一旦reload或重启就没了；带--permanent的规则写入持久化配置，但要reload才在运行时生效。很多同学配完服务后忘记加--permanent，当时测试一切正常，重启防火墙后规则全部丢失，然后跑来问"为什么我明明放行了还是连不上"。
还有一种场景是放行服务之后，还想限定只有特定IP能访问。比如VNC只允许内网网段访问，可以用rich-rule做到：
bash复制firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.10.0/24" service name="vnc-server" accept'
firewall-cmd --reload
这样即使5901端口对全网开放也不至于暴露到模拟外网环境中，安全策略的精细化程度能高一个档次。
6.2 SELinux排查方法论：从AVC日志到解决
SELinux一直是被新手吐槽最多的组件。不少同学实际操作中遇到"明明是root身份、权限也给了、服务就是访问不了"的情况，最终都指向SELinux。解决SELinux问题的完整方法其实就三步。
第一步，确认当前模式：
bash复制getenforce
如果输出是Enforcing，说明SELinux正在强制拦截；如果是Permissive，说明只记录不拦截；如果是Disabled，说明没启用。这里要注意，SELinux的三个模式切换一般都要求重启系统，尤其是从Disabled切到Enforcing，否则文件标签不会自动补齐，反而会制造出一大堆奇怪的问题。
第二步，查日志。所有被SELinux拦截的事件都会记录在/var/log/audit/audit.log里，或者/var/log/messages里也会有关键提示。常用命令：
bash复制ausearch -m avc -ts recent
grep "SELinux" /var/log/messages | tail -20
如果装了setroubleshoot-server，还可以用sealert把日志里的原始消息翻译成人话：
bash复制yum install -y setroubleshoot-server
sealert -a /var/log/audit/audit.log
它会直接告诉你"建议执行setsebool -P httpd_can_network_connect 1"或者"建议给目录打上httpd_sys_content_t标签"。
第三步，根据提示执行对应操作。两类最常用的操作是布尔值和文件上下文。布尔值控制的是进程的"越界能力"，比如：
bash复制setsebool -P httpd_can_network_connect 1
setsebool -P ftpd_full_access 1
-P表示持久化，不加-P只对当前生效，重启后丢失。文件上下文控制的是目录的"身份标签"：
bash复制semanage fcontext -a -t httpd_sys_content_t '/srv/www(/.*)?'
restorecon -Rv /srv/www
遇到SELinux问题最忌讳的就是直接setenforce 0甚至干脆在/etc/selinux/config里写SELINUX=disabled。临时关闭确实能让服务跑起来，但等于把最后一道安全闸拆了，而且这种"关掉就完事"的思路对技术成长没有任何帮助。正确做法是把每个AVC告警当成一次安全策略适配的机会，搞清楚到底是被文件上下文拒绝还是被布尔值策略拒绝。
7. 常见问题排查实录：全流程踩坑清单
7.1 服务起不来的通用排查法
把几个服务都叠在一起后，出现问题时最怕没有方向。我总结了一个通用的服务故障排查顺序，几乎可以应对80%的"服务起不来"场景。
第一步，看服务状态和日志：
bash复制systemctl status 服务名
journalctl -xe
systemctl status会显示服务是否启动失败，以及最近的错误日志位置。journalctl命令虽然输出量大，但配合-u 服务名就能精确过滤。
第二步，做配置语法检查。每个服务都有对应的检查命令：
bash复制httpd -t
named-checkconf /etc/named.conf
testparm
这些命令不会实际启动服务，只会检查配置文件是否合法，定位语法问题非常快。
第三步，查端口占用。服务启动失败如果报Address already in use，基本就是端口冲突：
bash复制ss -tlnp | grep 端口号
第四步，确认SELinux上下文。尤其在自定义目录、自定义端口、自定义用户场景中，SELinux拦截的概率很高，优先看ausearch输出。
我把几个服务的典型失败场景整理成表格，方便对照：
| 服务 | 常见启动失败原因 | 优先排查命令 |
|---|---|---|
| httpd | 80端口占用；httpd -t语法报错 | httpd -t；ss -tlnp |
| named | 区域文件权限不足；named.conf语法错 | named-checkconf；named-checkzone |
| vsftpd | chroot目录可写报500 OOPS；被动端口范围错误 | 查看日志；tail /var/log/messages |
| smb | smb.conf语法错或路径不存在 | testparm；ls -ld 共享目录 |
| vnc | 模板服务文件未改User；密码文件权限错 | systemctl status；tail .vnc日志 |
7.2 客户端访问不通过的定位
服务端看起来一切正常，但客户端就是连不上，这类问题在综合配置练习里出现频率最高。定位思路可以按"四层"逐层往下查。
第一层，网络通不通。在同一网段的客户端上ping一下服务器IP：
bash复制ping 192.168.10.10
ping不通，说明链路层或者IP配置有问题，先查网卡地址和网关。ping通了，进入下一层。
第二层，端口通不通。很多服务在防火墙层面被拦时，ping是通的但连接就是超时。测试工具用telnet或者nc：
bash复制nc -vz 192.168.10.10 445
端口连不上，大概率是firewalld没有放行对应服务，检查firewall-cmd --list-all。端口能通，进入下一层。
第三层，服务是否真的在监听。有时候服务状态显示active，但端口没有绑定，可能是配置里listen字段写错了或者只监听了回环地址127.0.0.1。在服务端执行ss或者netstat确认。
第四层，SELinux和安全上下文。如果前三层全通了，客户端还是访问异常，那就要回来看SELinux的AVC日志。比如Samba共享能连但打不开目录、Apache能访问但页码显示403、FTP能登录但传不了文件，这类"半通不通"的诡异现象，八成都是SELinux在起作用。
这套四层排查法几乎可以覆盖所有客户端侧的故障场景。更重要的是，它给了一个稳定的思考框架，不会让你在多个服务之间来回瞎试。
7.3 配置丢失、重启失灵的坑
配置在重启后丢掉的经历，几乎每个Linux使用者都遇到过。归纳起来，最常见的丢失陷阱有三个。
第一个陷阱是firewalld规则没有持久化。不带--permanent的规则，reload或重启防火墙后全部消失。解决办法是加--permanent后reload，或者如果已经配了一堆临时规则想保留，直接执行：
bash复制firewall-cmd --runtime-to-permanent
第二个陷阱是/etc/resolv.conf被NetworkManager覆盖。这个问题在第2章提过，手工修改的DNS解析在重启网络后被打回原形。解决方案是用nmcli设置DNS，或者在ifcfg里写入PEERDNS=no。
第三个陷阱是SELinux布尔值没持久化。setsebool命令如果不加-P参数，重启后策略回到默认值。养成习惯：所有布尔值调整都带-P。
还有一个小细节是关于服务的enable和start。很多同学只start不enable，当场服务能用，服务器一重启服务就消失。凡是需要开机自启的服务都要显式执行：
bash复制systemctl enable 服务名
systemctl start 服务名
或者用一条命令合并执行：
bash复制systemctl enable --now 服务名
这套综合配置练完之后，我个人的一个体会是：最重要的收获不是记住了多少命令，而是建立了一套"从现象到根因"的排查路线。VNC黑屏先看桌面组件，FTP报500 OOPS先看chroot目录是否可写，Apache 403先看SELinux上下文，Samba连不上先看135/139/445端口和smb.conf，DNS解析不了先看named区域文件权限——这些判断不是靠背出来的，是靠把每个服务的原理和常见失败模式串起来形成的直觉。
最后再说一个练习时的实用建议：完成整套配置后，可以故意制造一些故障，比如把SELinux里的某个目录上下文改掉、把firewalld的某个服务移除、把一个服务的配置文件改错，然后从头到尾用日志和命令去定位。这个"故意破坏再修复"的过程，比照着教程敲一遍命令有用得多。它逼着你去读日志、理解服务的启动和访问流程，也会让你在真正应对生产环境故障时，心里有底，不慌张。