warp导致的日志发送node2失败
1.问题背景
这个是一个操作，以下是案例
1.案例内容
需求：基于node1中的/var/log/下的messages和secure日志， 完成将日志发送到日志服务器（node3）， 进行统一保存，要求保存到node3服务器的/var/log/messages和/var/log/secure
思路：
2.案例思路
第一步： 修改 node1的日志配置文件， 将对应写入到messages和secure日志对应规则配置， 将其目的地变更为发送到远端服务器方案 【建议选择：TCP方案】
第二步： 重启node1的系统日志服务
第三步： 修改 node3的日志配置文件， 将用于接收远程日志的模块打开【tcp模块】
第四步： 重启node3的系统日志服务
第五步： 在node3中开放端口号
第六步：
测试message日志： 在node1中通过logger生成日志数据， 分别观察node1的系统日志和node3的系统日志， 哪个日志文件中会产生新的日志【正常:node3打印】
测试安全日志： 通过MX连接下node1，然后在关闭， 观察在这个过程中， node1和node3的安全日志谁会打印新的日志【正常:node3打印】
2.出现的问题
我当时用的是node2和node3，把node1替换成node2了
1.node2配置文件
- 打开vi /etc/rsyslog.conf这个文件，然后修改一些地方，图中红圈有一个地方圈错了，应该圈的是有@@的那几行，也是要追加的
2.重启日志文件
systemctl restart rsyslog
ststemctl status rsyslog
3.node3文件
和node1的文件是同一个，在模块中把tcp协议放行
4.node3端口和服务放行
firewall-cmd --add-port 514/tcp --permanent
firewall-cmd --reload
firewall-cmd --list-all
systemctl restart rsyslog
ststemctl status rsyslog
5.出现问题
我在测试的时候，发现一个问题，没有通过
他报的这个错误我当时很迷，ai让我把setforce设置0，但是已让没有ok，就比较麻烦，当时折腾了许久，就是搞不定，当时也比较晚了，我就直接睡了
3.问题原因
第二天早上，我仔细有复现了一边，就很离谱，这一次，竟然成功了，配置和昨天一样的，只不过，报了这行文字，我当时想我的虚拟机并没有打开warp这个客户端，为何虚拟机会出现这行文字呢
我问了一下，ai她给我说是这样的，因为，我在打开warp客户端的时候，这个软件会修改计算机的路由表，DNS把DNS设置为它自己的：127.0.2.2 和 127.0.2.3（这是 Cloudflare 在本地建的 DNS 代理）,因为昨天我可能设置完setfoce=0之后呢，没有立即生效，需要重启才会，当时我可能来回开关这个软件，导致由表处于"脏状态"，今天冷启动后，WARP 的虚拟接口和路由规则重新初始化，恰好没有干扰到虚拟机的桥接网络。
核心原因剖析：用了 TCP，日志为什么还会"凭空消失"？
很多人（包括当时的我）都有一个误区：“我用了 TCP 转发，TCP 是可靠传输，日志不可能丢啊？” 但这次事故告诉我：TCP 的可靠性，只在"连接已建立"的前提下才生效。 这次故障是三层问题叠加的结果：
1. 环境层：Cloudflare 客户端重置宿主机网络（根本诱因）
宿主机上的 Cloudflare One Client（WARP）是全局代理/隧道工具。当它处于不稳定状态（客户端自己都在提示"Internet 连接不稳定"）或后台重连时，会重置宿主机的路由表和网络栈。这是整起事故的"第一张多米诺骨牌"。
2. 链路层：虚拟机网卡被连带闪断（触发条件）
VMware 虚拟机的虚拟网卡依托宿主机网络存在。宿主机网络一重置，虚拟机网卡跟着断。日志里的铁证——node2 和 node3 同一秒同时出现：
Aug 5 07:14:45 node2 kernel: e1000: ens33 NIC Link is Down
Aug 5 07:14:47 node3 kernel: ens33 NIC Link is Up 1000 Mbps Full Duplex
两台机器不可能约好一起坏，问题只能出在宿主机层面。
3. 传输/应用层：TCP 握手失败 + rsyslog 默认不缓存（直接原因）
TCP 要握手，链路断了就是断了。 闪断期间，node2 与 node3:514 的三次握手无法完成，连接建立不起来，数据一个字节都过不去。（这点比 UDP 更"诚实"：UDP 还会盲目往外发包，TCP 直接告诉你连接失败。）
rsyslog 默认不缓存断连期间的消息。 rsyslog 转发动作默认使用 Direct 队列，没有配置内存/磁盘缓存队列。连接不可用时，这个窗口期内产生的日志默认直接丢弃，网络恢复后也不会补发。
所以"TCP 可靠"救不了你——它保证的是连接建立后不丢不乱，救不了"连接根本不存在"期间产生的消息。
💡 一句话总结根因
WARP 不稳定 → 宿主机网络重置 → 虚拟机网卡闪断 → TCP 连接无法建立/维持 → rsyslog 默认无队列，断连窗口期的日志被丢弃 → 接收端什么都看不到。 早上冷启动后链路全程稳定，TCP 握手一次成功，可靠性机制正常上岗，于是"开着软件也一切正常"。
4.解决问题
其实第二天我一起来，又做了一边实验就顺利了，问题自己解决了
和图中的一样，只不过我当时调整的是本地发一份，远端发一份
解决对策
做实验前退出所有代理 / VPN / WARP，控制变量再排障；
转发地址写 IP 不写主机名，避免 DNS 故障牵连日志发送；
防火墙、SELinux 常规三件套别忘：
firewall-cmd --permanent --add-port=514/tcp
firewall-cmd --reload
setenforce 0 # 实验环境临时关，生产请配策略
systemctl restart rsyslog
- 排障工具包，一步区分"配置问题"还是"环境问题"：
tail -F /var/log/messages # 接收端看日志
tcpdump -i ens33 port 514 # 接收端看包到没到
ss -ulnp | grep 514 # 看监听起没起
tcpdump 有包没日志 → 接收端服务/配置问题；tcpdump 没包 → 网络/链路层问题。
解决对策： 核心是三层入手。环境层：实验前退出宿主机上的 Cloudflare WARP 等代理软件，消除网络重置、虚拟网卡闪断的根因。应用层：保持 TCP 转发，并在发送端启用缓存队列（queue.type="linkedList"、action.resumeRetryCount="-1"），使断连期间的日志先入队、网络恢复后自动补发，不再丢弃；转发地址写 IP 不写主机名，防火墙放行 514/tcp，临时关闭 SELinux，改完用 rsyslogd -N1 校验语法并重启服务。验证层：用 tcpdump -i ens33 tcp port 514、ss -tlnp | grep 514、tail -F /var/log/messages 逐层确认"包到了、端口在听、日志显示"，形成闭环。
5.总结
``当时我的warp连接是不稳定的，我没有在意，就比较麻烦，做这个实验一直搞不定，很捉急，但是第二天好了，其实应该就是与我的这个软件有关.
写在最后
很多初学者（包括曾经的我）在遇到服务不通时，总是习惯性地怀疑自己：“是不是我 rsyslog 配置写错了？”“是不是 SELinux 没关？”“是不是防火墙没放行？” 但这次事故告诉我：在真实的运维世界里，80% 的“玄学”故障，根源都在你看不见的基础网络环境里。 一个宿主机代理软件的抽风，足以让你的虚拟机网络经历“闪断-重连”，从而在应用层制造出“配置全对但就是不工作”的假象。能写出正确的配置文件只是基本功，能敏锐地察觉环境变化、熟练运用 tcpdump 抓包定界、懂得在复杂干扰中控制变量，才是一个成熟运维工程师的真正壁垒。 踩坑不可怕，把坑填平并总结出方法论，就是最大的成长。希望这篇复盘，能帮你在未来的 Linux 学习之路上少走弯路。如果觉得有用，欢迎点赞收藏，我们评论区交流！💪``
评论