运维烂笔头

一个 SA 老兵的工作日志

发表于 更新于

在现代网络架构中，VPN（虚拟专用网络）技术的应用越来越广泛。本文将探讨在我司 IDC 中，使用 WireGuard 实现的 VPN 连接中遇到的一个有趣现象。

场景描述

我司在 IDC 中有一台运行 Debian 的服务器 L1，有两个上联口：E-a 和 E-b，分别连接到运营商 I-a 和 I-b。IP 地址为 ip-a 和 ip-b。L1 上的策略路由很简单：

  • 源地址为 ip-a 的数据包通过 E-a 口走 I-a
  • 其他数据包则通过默认出口 E-b 走 I-b（源地址自然是 ip-b）

此外，L1 还通过网口 E-c 连接内网，IP 地址为 ip-c。L1 上运行 WirGuard，绑定 0.0.0.0 的 udp 端口 12345。

在办公室，我司还有一台运行 Debian 的机器 L2。由于 L2 位于内网中，没有公网 IP。L2 上也运行着 WireGuard，绑定在 0.0.0.0 的（udp）端口 12345。同时，我在办公室的路由器上做了端口映射，将 udp 12345 端口映射到 L2（虽然这完全没什么用）。

L2 的 WireGuard 配置中，peer 的 endpoint 指定为 L1 的 IP 地址 ip-a。由于 L2 没有公网地址且出口地址不固定，因此在 L1 的 WireGuard 配置中并没有指定 L2 的 IP 地址。就这样，L1 和 L2 上的 WireGuard 的连接顺利建立，一切都如预期般正常运行。

异常现象

其实，L2 上还运行着一个 SmokePing，监测着 ip-a、ip-b 和 ip-c，当然也还有其他，不过那些跟这里没啥关系，也就不提了。

某天我在 Smokeping 监控中发现，ping ip-c 的（时间）值明显高于 ping ip-a 的值，且与 ping ip-b 的相近。这一现象让我感到困惑，因为到 ip-c 的数据包走的逻辑链路（通过 WireGuard 隧道）实际上应该与到 ip-a 的物理链路完全相同，所以 ping ip-c 的数据应该跟 ping ip-a 的几乎一样才对。

我的第一反应是，可能是办公室的网络接入商或 I-a 对 UDP 包进行了 QoS 限速，因为 WireGuard 使用的是 UDP 协议。经过与客服的沟通，确认并没有针对 UDP 包的限速策略。

接着，我使用 iperf3 在 L1 和 L2 之间进行了测速，发现走 UDP 和走 TCP 的测试结果数据引并没有显著差别，这表明问题并不在于 UDP 包有被干扰。随后，我在 L2 上使用 tcpdump 监听 WireGuard 的数据包，结果让我大吃一惊：所有的数据包都是与 ip-b 的端口 12345 进行交互，而不是预期中的 ip-a！这也解释了为什么 ping ip-c 的延迟与 ping ip-b 的延迟相近，因为数据实际上是通过到 ip-b 的物理链路进行的。

深入分析

面对这一现象，我感到百思不得其解。于是，我记录下当前的状况，并重启了 L2 上的 WireGuard，结果一切又都恢复正常：WireGuard 的数据交互对端 IP 变回了 ip-a，ping ip-c 的延迟也降到了与 ping ip-a 相同的水平。

进一步查阅资料后，我发现 WireGuard 具有 endpoint 自动更新的机制。虽然 L1 上没有 L2 端的 endpoint 数据，但 L2 上有 L1 的数据。当 L2 第一次连接 L1 时，L1 会记录下 L2 的 endpoint 数据。如果 L2 使用了不同的 IP 地址连接 L1，L1 会更新 L2 的 endpoint IP 地址。反之亦然。这意味着，当 L1 从 E-b 口以 ip-b 作为源地址连接 L2 时，L2 也会更新 L1 的 endpoint IP 地址。

最终，我意识到问题的根源在于 L1 突然使用源 IP 为 ip-b 从 E-b 口发送 WireGuard 数据包给 L2。期间，我发现办公网的网络曾经闪断过几分钟。真相逐渐浮出水面：当 L2 的上联公网链路断开时，L1 由于长时间未收到来自 L2 的 WireGuard 数据包，可能出于某种原因主动向 L2 发送 WireGuard 包，查找 L2 的 endpoint IP 和端口数据。此时，由于源地址未定，数据包直接通过 E-b 口发送，源地址被设为 ip-b。这些数据包持续发送到 L2，直到 L2 的上联网络恢复。L2 收到来自 ip-b 的 L1 的 WireGuard 数据包后，触发了更新 L1 的 endpoint 数据，从而开始与 L1 的 ip-b 进行 WireGuard 数据交互。

结论

通过这一系列的分析，整个逻辑变得自洽了。这一现象不仅揭示了 WireGuard 的灵活性和自动化特性，也提醒我们在设计网络架构时，需考虑到各种可能的网络状态变化。希望这篇文章能为您在使用 WireGuard 或其他 VPN 技术时提供一些启示。

发表于 更新于

背景介绍

最近要做个 log server，把所有服务器的系统日志都收上来。我现在的服务器，操作系统有两种：Amazon Linux 2023 和 Ubuntu，但其实 Ubuntu 又有 22.04 和 24.04 两种，所以，其实是一共有三种操作系统。

好在这三种系统，其缺省跑的日志应用，Amazon Linux 2023 是 systemd-journald，而 Ubuntu(22.04 和 24.04) 都是既跑有 systemd-journald，又跑的有 rsyslogd。这两种日志应用，都是支持集中的日志服务器的，或者很容易支持。但是为什么不就用一套 rsyslogd 的日志服务器呢？毕竟大家都支持 rsyslogd 的。主要是因为 systemd-journald 相对于 rsyslogd 是很新的东西，所以这里也拿出来练练手。

阅读全文 »

发表于 更新于

简介

这是之前有一家公司招 SRE，我投了简历，然后被给了份题让先做一下，于是便有了这篇“水”文。

当然，最终我并没有拿到这个 offer，最早是说一周内安排面试的，后来又说是这个岗位暂停了。

阅读全文 »

发表于 更新于

简介

这是之前有一家海外公司招 DevOps 工程师，我投了简历，期望薪资写了薪资范围的最下限，然后被给了份题让先做一下，于是便有了这篇“水”文。

当然，最终我并没有拿到这个 offer，甚至连下一轮见 CTO 的机会都没有。（关于这个，我其实心里还是有一点小小的不服气的。）

阅读全文 »

发表于 更新于

起因

在搭建新环境时，我们选择了 OpenTofu——这是在 Terraform 更改了 license 之后从 Terraform 代码库分支并且开放源码的工具——用于构建VPC、RDS、Redis等基础设施。

但当基础设施就位、开始部署应用程序时，问题出现了。每次部署都不成功，查看日志说是 JDBC 相关错误，DB Proxy 的日志中充斥着诸多 “internal error”，却若隐若现关于具体错误原因的描述。尝试直接通过 MySQL 客户端连接 DB Proxy 时，大多数命令执行都引发错误（help 命令除外）提示：

ERROR 1105 (HY000): Unknown error

错误截图参见：

阅读全文 »

发表于 更新于

背景

项目有一些非常重要的后台应用是跑在 AWS 的 lambda 上的，老板和产品非常关注这些应用的执行情况，一旦出错，都会是很严重的故障。

方案变迁

前面做过一些基础设施级别的监控报警，如：监控 AWS 的 RDS 并通过企业微信来报警，那个完全是利用基础设施自动打到 CloudWatch 的基础的 metrics 来做的。

于是，我这里下意识的就想利用现有的 CloudWatch 里现成的 Metrics 来做这个事情，于是我就弄了三个（种）监控：

阅读全文 »

发表于 更新于

缘起

本来这台 HP Chromebook 11A G6 EE( 加了一张 128G 的 TF 卡 )，我安装好了 Arch Linux(Xfce)，都弄好了的，但最近在知乎上老被安利说装 Debian 的 testing 版，于是我又开始折腾，把 Debian 13 testing(trixie) 安装到这台 Chromebook 上。

安装时，使用 lvm 分区不成功，系统报错：

partman-lvm: pvcreate: error while loading shared libraries: libaio.so.1: cannot open shared object file: no such file or directory

现在想想可能还有其他办法，比如想办法把这个需要的包注入进去，但当时选择了先用 ext4 分区安装系统自带的 16G 的卡里，装完以后再想办法转成 lvm 并把 TF 卡的空间加进来。

阅读全文 »

发表于 更新于

引言

监控在云资源管理中占据了核心地位，它可以帮助我们实时追踪资源状态，从而快速发现并处理潜在的问题。本文将介绍如何利用 AWS CloudWatch 监控云数据库服务RDS，并通过企业微信发送报警通知，以达到高效运维的目的。

阅读全文 »

发表于 更新于

缘起

大家好，我是老杨。在这篇文章中，我将带大家深入了解如何利用 GitHub Action 自动化部署 Chalice 应用到 AWS Lambda。这不仅是一个技术实践，也是对 CI/CD 流程优化的一次探索。

在现代软件开发中，快速迭代和持续部署是提高开发效率的关键。Chalice 是一个用于部署 Python 应用到 AWS Lambda 的框架，而 GitHub Action 提供了一个强大的自动化平台。结合这两者，我们可以创建一个无缝的部署流程。

阅读全文 »
0%