困扰我的一些错误日志技术
一些错误，如果要解决，需要找到各个软件的核心开发者，这样的成本巨大，所以修复意义不大。就好比一个实物，成本也没有多贵，坏了重新买一个，修复就完全没有意义。软件也是如此，有些时候软件互相影响，系统配置混乱，唯一的解决方案就是多几台机器。
第一个，CF 的 connector 改成了 docker 方式，导致 503，实在是不知道为什么，因为另外两个链接也是 docker 方式，一样的操作，不理解。
2026-02-23T08:20:29Z WRN No ingress rules were defined in provided config (if any) nor from the cli, cloudflared will return 503 for all incoming HTTP requests 2026-02-23T08:20:39Z WRN No ingress rules were defined in provided config (if any) nor from the cli, cloudflared will return 503 for all incoming HTTP requests 2026-02-23T08:20:50Z WRN No ingress rules were defined in provided config (if any) nor from the cli, cloudflared will return 503 for all incoming HTTP requests 2026-02-23T08:20:50Z WRN No ingress rules were defined in provided config (if any) nor from the cli, cloudflared will return 503 for all incoming HTTP requests 2026-02-23T08:20:57Z INF Tunnel connection curve preferences: [X25519MLKEM768 CurveP256] connIndex=3 event=0 ip=198.41.200.53 2026-02-23T08:20:57Z INF Registered tunnel connection connIndex=3 connection=7f9da373-51ea-4e6a-903c-06cbe12a645f event=0 ip=198.41.200.53 location=sjc10 protocol=quic 2026-02-23T08:21:00Z WRN No ingress rules were defined in provided config (if any) nor from the cli, cloudflared will return 503 for all incoming HTTP requests
OpenVPN 死活无法获取流量，研究了 iptables 很长时间，因为默认都是 ACCEPT，POSTROUTING 也不存在冲突，不存在问题啊，证书过期时间是 2033 年，真的搞不明白为什么不行。
2月 23 19:29:45 raspberrypi ovpn-server[15658]: 192.168.31.1:34321 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) 2月 23 19:29:45 raspberrypi ovpn-server[15658]: 192.168.31.1:34321 TLS Error: TLS handshake failed 2月 23 19:29:45 raspberrypi ovpn-server[15658]: 192.168.31.1:34321 SIGUSR1[soft,tls-error] received, client-instance restarting 2月 23 19:29:55 raspberrypi ovpn-server[15658]: 192.168.31.1:40818 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) 2月 23 19:29:55 raspberrypi ovpn-server[15658]: 192.168.31.1:40818 TLS Error: TLS handshake failed 2月 23 19:29:55 raspberrypi ovpn-server[15658]: 192.168.31.1:40818 SIGUSR1[soft,tls-error] received, client-instance restarting 2月 23 19:30:34 raspberrypi kernel: Under-voltage detected! (0x00050005) 2月 12 13:04:41 raspberrypi kernel: Under-voltage detected! (0x00050005) 2月 12 12:59:39 raspberrypi kernel: Voltage normalised (0x00000000) 2月 12 12:59:39 raspberrypi sshd[10994]: Connection closed by 170.64.175.190 port 26948 [preauth] 2月 12 12:59:39 raspberrypi ovpn-server[516]: 115.236.25.114:59670 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) 2月 12 12:59:39 raspberrypi ovpn-server[516]: 115.236.25.114:59670 TLS Error: TLS handshake failed 2月 12 12:59:39 raspberrypi ovpn-server[516]: 115.236.25.114:59670 SIGUSR1[soft,tls-error] received, client-instance restarting 2月 12 12:59:45 raspberrypi kernel: Under-voltage detected! (0x00050005) 2月 12 12:59:49 raspberrypi kernel: Voltage normalised (0x00000000) 2月 12 12:59:50 raspberrypi ovpn-server[516]: 115.236.25.114:54505 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) 2月 12 12:59:50 raspberrypi ovpn-server[516]: 115.236.25.114:54505 TLS Error: TLS handshake failed 2月 12 12:59:50 raspberrypi ovpn-server[516]: 115.236.25.114:54505 SIGUSR1[soft,tls-error] received, client-instance restarting 2月 12 12:59:58 raspberrypi sshd[10996]: Invalid user tidb from 170.64.175.190 port 29468 2月 12 12:59:59 raspberrypi ovpn-server[516]: 115.236.25.114:57357 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) 2月 12 12:59:59 raspberrypi ovpn-server[516]: 115.236.25.114:57357 TLS Error: TLS handshake failed 2月 12 12:59:59 raspberrypi ovpn-server[516]: 115.236.25.114:57357 SIGUSR1[soft,tls-error] received, client-instance restarting
iptables 默认 filter 表内容，不知道为什么 FORWARD 最后两个 10 网段永远无法获取流量。其实入口是可以，就是 10 网段流量无法出来。
pi@raspberrypi:~ $ sudo iptables -L -v -n
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
1466K 321M ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:1194
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
164M 114G DOCKER-USER all -- * * 0.0.0.0/0 0.0.0.0/0
164M 114G DOCKER-ISOLATION-STAGE-1 all -- * * 0.0.0.0/0 0.0.0.0/0
70M 57G ACCEPT all -- * docker0 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
759 594K DOCKER all -- * docker0 0.0.0.0/0 0.0.0.0/0
94M 57G ACCEPT all -- docker0 !docker0 0.0.0.0/0 0.0.0.0/0
5 1640 ACCEPT all -- docker0 docker0 0.0.0.0/0 0.0.0.0/0
1439K 240M ACCEPT all -- * * 10.8.0.0/24 0.0.0.0/0
2220K 2618M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain DOCKER (1 references)
pkts bytes target prot opt in out source destination
4 196 ACCEPT tcp -- !docker0 docker0 0.0.0.0/0 172.17.0.2 tcp dpt:12406
Chain DOCKER-ISOLATION-STAGE-1 (1 references)
pkts bytes target prot opt in out source destination
94M 57G DOCKER-ISOLATION-STAGE-2 all -- docker0 !docker0 0.0.0.0/0 0.0.0.0/0
164M 114G RETURN all -- * * 0.0.0.0/0 0.0.0.0/0
Chain DOCKER-USER (1 references)
pkts bytes target prot opt in out source destination
168M 117G RETURN all -- * * 0.0.0.0/0 0.0.0.0/0
Chain DOCKER-ISOLATION-STAGE-2 (1 references)
pkts bytes target prot opt in out source destination
0 0 DROP all -- * docker0 0.0.0.0/0 0.0.0.0/0
94M 57G RETURN all -- * * 0.0.0.0/0 0.0.0.0/0
就是随便怎么移动位置，都不行啊。服务重启过，机器确实没法重启。
pi@raspberrypi:~ $ sudo iptables -L -n -v -t filter
Chain INPUT (policy ACCEPT 5598 packets, 677K bytes)
pkts bytes target prot opt in out source destination
120 13680 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:1194
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- * * 10.8.0.0/24 0.0.0.0/0
93042 69M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
116 7160 DOCKER-USER all -- * * 0.0.0.0/0 0.0.0.0/0
116 7160 DOCKER-ISOLATION-STAGE-1 all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- * docker0 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
0 0 DOCKER all -- * docker0 0.0.0.0/0 0.0.0.0/0
116 7160 ACCEPT all -- docker0 !docker0 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- docker0 docker0 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT 5080 packets, 596K bytes)
pkts bytes target prot opt in out source destination
Chain DOCKER (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp -- !docker0 docker0 0.0.0.0/0 172.17.0.2 tcp dpt:12406
Chain DOCKER-ISOLATION-STAGE-1 (1 references)
pkts bytes target prot opt in out source destination
116 7160 DOCKER-ISOLATION-STAGE-2 all -- docker0 !docker0 0.0.0.0/0 0.0.0.0/0
116 7160 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0
Chain DOCKER-USER (1 references)
pkts bytes target prot opt in out source destination
116 7160 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0
Chain DOCKER-ISOLATION-STAGE-2 (1 references)
pkts bytes target prot opt in out source destination
0 0 DROP all -- * docker0 0.0.0.0/0 0.0.0.0/0
116 7160 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0
附上 nat 表，随便怎么开关，随便怎么移动顺序，10 网段 POSTROUTING 无法获取流量。
pi@raspberrypi:~ $ sudo iptables -L -n -v -t nat
Chain PREROUTING (policy ACCEPT 211 packets, 14720 bytes)
pkts bytes target prot opt in out source destination
18 1902 DOCKER all -- * * 0.0.0.0/0 0.0.0.0/0 ADDRTYPE match dst-type LOCAL
Chain INPUT (policy ACCEPT 49 packets, 4712 bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 701 packets, 42928 bytes)
pkts bytes target prot opt in out source destination
0 0 SNAT all -- * * 10.8.0.0/24 !10.8.0.0/24 to:192.168.31.165
162 10008 MASQUERADE all -- * !docker0 172.17.0.0/16 0.0.0.0/0
0 0 MASQUERADE tcp -- * * 172.17.0.2 172.17.0.2 tcp dpt:12406
Chain OUTPUT (policy ACCEPT 701 packets, 42928 bytes)
pkts bytes target prot opt in out source destination
1 60 DOCKER all -- * * 0.0.0.0/0 !127.0.0.0/8 ADDRTYPE match dst-type LOCAL
Chain DOCKER (2 references)
pkts bytes target prot opt in out source destination
0 0 RETURN all -- docker0 * 0.0.0.0/0 0.0.0.0/0
0 0 DNAT tcp -- !docker0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:51900 to:172.17.0.2:12406
前前后后折腾了两周时间了，回来了更方便，也是依然搞不明白。算了，重新换一台机器吧。
最后再尝试了一把，把网线拔了，只用无线，一切又正常了！🤦♂️🤦♀️
# Generated by xtables-save v1.8.2 on Thu Feb 12 14:19:05 2026 *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :DOCKER - [0:0] :DOCKER-ISOLATION-STAGE-1 - [0:0] :DOCKER-USER - [0:0] :DOCKER-ISOLATION-STAGE-2 - [0:0] -A INPUT -p udp -m udp --dport 1194 -j ACCEPT -A FORWARD -j DOCKER-USER -A FORWARD -j DOCKER-ISOLATION-STAGE-1 -A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A FORWARD -o docker0 -j DOCKER -A FORWARD -i docker0 ! -o docker0 -j ACCEPT -A FORWARD -i docker0 -o docker0 -j ACCEPT -A FORWARD -s 10.8.0.0/24 -j ACCEPT -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT -A DOCKER -d 172.17.0.2/32 ! -i docker0 -o docker0 -p tcp -m tcp --dport 12406 -j ACCEPT -A DOCKER-ISOLATION-STAGE-1 -i docker0 ! -o docker0 -j DOCKER-ISOLATION-STAGE-2 -A DOCKER-ISOLATION-STAGE-1 -j RETURN -A DOCKER-USER -j RETURN -A DOCKER-ISOLATION-STAGE-2 -o docker0 -j DROP -A DOCKER-ISOLATION-STAGE-2 -j RETURN COMMIT # Completed on Thu Feb 12 14:19:05 2026 # Generated by xtables-save v1.8.2 on Thu Feb 12 14:19:05 2026 *nat :PREROUTING ACCEPT [0:0] :INPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :DOCKER - [0:0] -A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER -A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE -A POSTROUTING -s 10.8.0.0/24 ! -d 10.8.0.0/24 -j SNAT --to-source 192.168.31.165 -A POSTROUTING -s 172.17.0.2/32 -d 172.17.0.2/32 -p tcp -m tcp --dport 12406 -j MASQUERADE -A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type LOCAL -j DOCKER -A DOCKER -i docker0 -j RETURN -A DOCKER ! -i docker0 -p tcp -m tcp --dport 51900 -j DNAT --to-destination 172.17.0.2:12406 COMMIT # Completed on Thu Feb 12 14:19:05 2026
怀疑问题出在 POSTROUTING 的 to-source 上，后面修改这条记录试试。
最后发现，不是 iptables 的问题，是 default via 的问题，最后在 openvpn server config 文件中添加了一行 local 指定 wlan0 解决。
port 1194 proto udp dev tun sndbuf 0 rcvbuf 0 ca ca.crt cert server.crt key server.key dh dh.pem auth SHA512 tls-auth ta.key 0 topology subnet server 10.8.0.0 255.255.255.0 ifconfig-pool-persist ipp.txt push "redirect-gateway def1 bypass-dhcp" push "dhcp-option DNS 192.168.31.1" keepalive 10 120 cipher AES-256-CBC user nobody group nogroup persist-key persist-tun status openvpn-status.log verb 3 crl-verify crl.pem float local 192.168.31.165
因为 eth0 metric 比较低，优先级高，出口都走了 eth0，导致协商出现错误。于是指定 wlan0 的 ip 搞定。
最后看看 ip route 。没有插网线和插入网线的对比：
pi@raspberrypi:~ $ ip route default via 192.168.31.1 dev wlan0 proto dhcp src 192.168.31.165 metric 303 10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.1 169.254.0.0/16 dev vethe63b148 scope link src 169.254.123.145 metric 234 169.254.0.0/16 dev veth067e10d scope link src 169.254.83.173 metric 236 169.254.0.0/16 dev vethfdd2a9b scope link src 169.254.149.20 metric 257 172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 192.168.31.0/24 dev wlan0 proto dhcp scope link src 192.168.31.165 metric 303 pi@raspberrypi:~ $ ip route default via 192.168.31.1 dev eth0 proto dhcp src 192.168.31.166 metric 202 default via 192.168.31.1 dev wlan0 proto dhcp src 192.168.31.165 metric 303 10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.1 169.254.0.0/16 dev vethe63b148 scope link src 169.254.123.145 metric 234 169.254.0.0/16 dev veth067e10d scope link src 169.254.83.173 metric 236 169.254.0.0/16 dev vethfdd2a9b scope link src 169.254.149.20 metric 257 172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 192.168.31.0/24 dev eth0 proto dhcp scope link src 192.168.31.166 metric 202 192.168.31.0/24 dev wlan0 proto dhcp scope link src 192.168.31.165 metric 303
算是搞定了，还是没有完全明白，为什么只有 openvpn 出问题，其他的连接，包括 SS，CF 的 三个 connector 在随意插拔网线的情况下都能正常运作。单单 openvpn 这么娇贵呢！
最后发现 SS 服务测试无法连接上网，查看 iptables nat 的修改，如下：
pi@raspberrypi:~ $ diff work/iptables.txt work/iptables.txt.bak 36,38c36 < #-A POSTROUTING -s 10.8.0.0/24 ! -d 10.8.0.0/24 -j SNAT --to-source 192.168.31.165 < -A POSTROUTING -s 10.8.0.0/24 -o wlan0 ! -d 10.8.0.0/24 -j MASQUERADE < --- > -A POSTROUTING -s 10.8.0.0/24 ! -d 10.8.0.0/24 -j SNAT --to-source 192.168.31.165
没有改动 172 的网段啊，照理应该不影响的，但是恢复之后就都正常了，这也真是奇了怪了。没有精力再改成上面的测试怎么回事了。先这样吧。
附加 Google Gemini AI 的回答：
openvpn server connect fail when cable eth0 has connect and get a static ip Gemini Overview OpenVPN connection failure on a static IP eth0 interface often results from incorrect gateway routing, firewall blocking, or binding issues. Ensure your server firewall allows UDP 1194 (or TCP 443), confirm port forwarding on your router points to the new static IP, and ensure the local directive in server.conf matches the eth0 IP. OpenVPN OpenVPN +2 Key Troubleshooting Steps: Verify Gateway Routing: Ensure the default gateway is set correctly for eth0. If the static IP configuration lacks a gateway, traffic cannot return to clients. Use ip route to verify. Check local Binding: In /etc/openvpn/server.conf, explicitly set local [your_static_ip] to force OpenVPN to bind to the correct interface rather than the first available one. Update Port Forwarding: Your router must port forward VPN traffic to the new static IP, not the old DHCP IP. Firewall Rules: If using ufw, explicitly allow traffic on your configured port (e.g., ufw allow 1194/udp). Restart OpenVPN: Always restart the service after IP changes: systemctl restart openvpn@server. OpenVPN OpenVPN +4
测试一下 百度 文心快码 AI 的回答：
openvpn 连接失败当电缆eth0连接并获得一个静态ip OpenVPN 连接失败可能是由于多种原因引起的，尤其是当涉及到以太网接口（eth0）的配置和静态IP地址分配时。以下是一些步骤和检查点，可以帮助你诊断和解决OpenVPN连接问题： 1. 检查网络接口状态 首先，确保你的网络接口（eth0）已经正确启动并且配置了正确的静态IP地址。你可以使用以下命令来检查接口状态： bash Copy Code ip addr show eth0 确保显示的IP地址是你的静态IP地址。 2. 检查路由表 确认路由表是否正确设置了网关（Gateway）和默认路由： bash Copy Code ip route show dev eth0 3. 检查防火墙设置 确保防火墙规则允许OpenVPN的流量通过。例如，如果你使用的是iptables，你需要允许UDP或TCP流量（取决于你的OpenVPN配置）。例如，允许UDP端口1194（假设这是你的VPN端口）： bash Copy Code sudo iptables -A INPUT -p udp --dport 1194 -j ACCEPT sudo iptables -A FORWARD -p udp --dport 1194 -j ACCEPT 4. 检查SELinux状态 如果你的系统使用SELinux，确保SELinux没有阻止OpenVPN的运行。你可以暂时将SELinux设置为宽容模式来测试是否是SELinux引起的问题： bash Copy Code sudo setenforce 0 如果这解决了问题，你需要调整SELinux策略而不是永久禁用它。例如，添加一个规则允许OpenVPN： bash Copy Code sudo setsebool -P virt_use_tun 1 5. 检查OpenVPN配置文件 确保你的OpenVPN配置文件（通常是openvpn.conf）中的设置正确。特别是server、port、proto（UDP或TCP）、dev（通常是tun或tap设备）等设置。例如： plaintext Copy Code proto udp port 1194 dev tun server 10.8.0.0 255.255.255.0 6. 查看日志文件 查看OpenVPN的日志文件以获取错误信息： bash Copy Code sudo tail -f /var/log/openvpn.log 7. 重新启动OpenVPN服务 在做了上述更改后，尝试重新启动OpenVPN服务： bash Copy Code sudo systemctl restart [email protected] 8. 检查DNS设置 确保你的VPN客户端或服务器配置了正确的DNS服务器。在OpenVPN配置文件中，你可以指定DNS服务器： plaintext Copy Code push "dhcp-option DNS 8.8.8.8" push "dhcp-option DNS 8.8.4.4" 9. 网络硬件和驱动程序检查 确保你的网络硬件（如网卡）和驱动程序是最新的，并且兼容你的操作系统。有时候，旧的或损坏的驱动程序可能会导致网络连接问题。 通过上述步骤，你应该能够诊断并解决大多数OpenVPN连接问题。如果问题仍然存在，可能需要更深入地检查网络配置或咨询具体硬件和网络设备的支持。
看来 百度的 文心快码 真的不懂 openvpn 是没有真的理解，而 Google Gemini 是真的理解了一个 openvpn 产品，这个是本质的区别。AI 能回答的问题，在网络上一定能找到相关的网页，问题是 AI 根据这些内容能不能融会贯通，理解一个产品，Gemini 是真的做到了。文心快码还是根据网络回答胡乱总结一番，对于一个产品是真的没有理解。
暂无