Internet

Packet Switching（分组交换）原理解析

一、引言 现代互联网建立在 Packet Switching（分组交换） 的基础之上。这一设计使得全球网络能够在分布式环境中稳定运行，并具备极强的容错能力和扩展能力。 与早期电话网络的 Circuit Switching（电路交换） 不同，Packet Switching 将数据拆分为多个独立的数据包，通过网络中的不同路径传输，最终在接收端重新组合。 本文介绍 Packet Switching 的基本概念、传输过程以及其在互联网架构中的重要作用。 二、Packet Switching 概念 Packet Switching（分组交换） 是一种网络通信方式，其核心思想为： 将完整的数据拆分为多个数据包（packet），分别在网络中独立传输，并在接收端重新组合。 每个 packet 通常包含两部分： 数据部分（payload）控制信息（header） Header 中通常包含以下信息： 由于每个 packet 都携带目标地址，因此它们可以在网络中独立路由。 三、数据传输过程 在 Packet Switching 网络中，数据并不会沿着固定路径传输，而是由网络中的路由设备动态决定路径。 例如，从日本访问美国服务器时，数据可能经过多个网络节点： 客户端 ↓本地路由器 ↓ISP ↓国际骨干网络 ↓目标服务器 在这一过程中，不同的数据包可能走不同路径，例如： Packet1: Osaka → Tokyo → Los Angeles …

TLS

Linux 命令行查看 SSL 证书有效期的方法

在服务器运维过程中，经常需要确认 SSL 证书是否即将过期。尤其是在使用 Let’s Encrypt 自动签发证书的环境中，如果未及时发现证书失效，可能导致 HTTPS 服务中断。 本文记录一种 完全基于命令行 的证书有效期检查方法，适用于任何 Linux 系统。 一、证书文件结构 典型的证书目录如下： 说明： 查看证书有效期时，仅需要 fullchain.pem。 二、查看证书生效时间与过期时间 使用 openssl： 示例输出： 字段含义： 字段 含义 notBefore 证书开始生效时间 notAfter 证书过期时间 其中 notAfter 是最需要关注的字段。 三、仅查看证书过期时间（常用） 如果只关心证书何时失效： 输出示例： 适合脚本检测或快速人工确认。 四、查看完整证书信息 当需要排查 HTTPS 或 TLS 问题时，可以查看完整证书内容： 可获得： 该方式常用于反向代理或 TLS 握手问题分析。 五、计算证书剩余有效天数 服务器自动化运维中，通常需要判断证书还剩多少天过期。 可使用： 示例输出： …

SSH

Tabby vs Termius：SSH 客户端的两种设计哲学

本文对比 Tabby 与 Termius 在 SSH 使用场景下的设计理念、安全模型与长期可维护性。文章不涉及具体个人环境细节，聚焦工具本身的结构性差异。 一、问题背景 在多主机运维、个人服务器或实验环境中，SSH 客户端往往会逐渐从“工具”演变为“基础设施的一部分”。 这时，一个关键问题会浮现： SSH 客户端应当只是 OpenSSH 的外壳，还是一个自成体系的连接管理平台？ Tabby 与 Termius，正好代表了这两种截然不同的路线。 二、核心设计理念对比 Tabby：OpenSSH 的 UI 外壳 Tabby 的核心定位非常克制： 换句话说： Tabby 不试图“接管 SSH”，而是选择“服从 SSH”。 Termius：自包含的 SSH 平台 Termius 的设计目标明显不同： 在 Termius 中： SSH 不再是系统能力，而是应用能力。 三、安全模型差异 Tabby 的安全边界 Tabby 的安全边界在操作系统层： Tabby 本身： 这意味着： Tabby 的安全性 …

SSH

Linux 下生成与管理 Ed25519 SSH Key 的实践笔记

背景 在现代 Linux 系统中，SSH 公钥认证已成为远程登录与自动化运维的基础设施之一。随着密码学实践的演进，Ed25519 已成为 OpenSSH 官方推荐的默认算法。本文记录在 Linux 环境下生成 Ed25519 SSH key 的最小且安全做法，并澄清若干常见误解，重点面向： 全文仅涉及事实与机制，不包含个人偏好或架构建议。 一、推荐的算法选择 当前时间节点（2025–2026 年前后），在 OpenSSH 环境中： 因此，以下示例均以 Ed25519 为前提。 二、生成 Ed25519 SSH Key 的标准命令 在 Linux 命令行下，生成一把偏安全取向的 Ed25519 key： 参数说明 执行后将生成： 三、关于 passphrase 生成过程中会提示输入 passphrase： 是否设置 passphrase 不影响 key 的数学有效性，但会影响私钥泄露后的风险等级。 四、公钥最后的“名字”是什么？ 典型的 Ed25519 公钥内容如下： 其结构为： 其中： …

SSH

Android SSH 客户端选择与长期可控方案

目标：在 Android 平台上选择一个 长期可用、离线、可控 的 SSH 登录方案，避免云绑定、避免停更风险，并与桌面端使用习惯保持一致。 一、问题背景 在 Android 上寻找 SSH 客户端时，常见诉求包括： 部分流行客户端在实际使用中暴露出以下问题： 因此需要重新评估 Android 上 SSH 客户端的长期可行性。 二、评估维度 本文主要从以下维度进行筛选： 其中，前 3 条为硬条件。 三、常见方案分析 1. 商业型一体化客户端 特点： 问题： 结论： 不适合作为长期、可控的基础设施工具。 2. 已停止维护的 Android SSH 客户端 特点： 问题： 结论： 停更即不可用，应直接排除。 3. 终端型方案（如完整 Linux 用户态环境） 特点： 问题： 结论： 适合重度用户或统一桌面/移动端工作流，但不符合“轻量点击登录”的需求。 四、最终选择：轻量、离线、长期可用的 SSH …

Network

FRPS 中 QUIC 监听端口的协议类型与配置取舍分析

背景 在使用 FRP（Fast Reverse Proxy）进行内网穿透时，FRPS（服务器端）的通信端口配置直接影响系统的稳定性、安全性以及后续的运维复杂度。 随着 FRP 新版本引入基于 QUIC 的传输方式，配置项中新增了 QUIC 相关监听参数，这使得服务器端可能同时存在多种控制通道实现方式，有必要对其协议属性与实际影响进行明确分析。 QUIC 监听端口的协议属性 结论明确： FRPS 中用于 QUIC 的监听端口基于 UDP 协议 原因在于： 协议层级关系如下： 因此： 传统控制端口与 QUIC 控制端口的差异 FRPS 提供两种功能等价的控制通道实现方式： 项目 传统控制通道 QUIC 控制通道 底层协议 TCP UDP 连接可靠性 由 TCP 提供 由 QUIC 协议实现 网络兼容性 高 依赖 UDP 质量 运维复杂度 较低 …

Network

Asahi 勒索事件与 MFA 安全模型分析

事件背景 近期，日本大型企业 Asahi 集团披露其内部系统遭到勒索软件攻击。多个安全媒体确认，该事件并非简单的自动化攻击，而是一次具备明确目标、持续渗透和横向移动特征的 人工入侵型勒索事件。攻击者被认为与 Qilin 勒索软件组织有关。 从已公开的信息可以确认： 目前并无可靠公开信息披露具体赎金金额，亦无法确认受害方是否支付赎金。 是否会被法律追责 从法律层面看，勒索软件攻击属于严重刑事犯罪；但在现实中，类似 Qilin 的跨国勒索组织 极少真正受到司法追责。主要原因包括： 因此，“违法”与“能否被追责”在现实世界中存在明显落差。 入侵路径分析：SSH 还是 Web？ 截至目前，没有公开证据确认 Asahi 是通过 SSH 还是 Web 服务被直接攻破。但结合企业环境特征与勒索组织的常见攻击模式，可以做出较为可靠的排除与判断。 排除可能性较高的路径 更可能的真实入口 攻击者能够长期稳定地外传大量数据，本身就说明其获得的是 持续、可信的内部访问权限。 MFA（多因素认证）的现实意义 MFA（Multi-Factor Authentication，多因素认证）指登录验证不再只依赖单一密码，而是组合以下至少两类要素： 在现实安全模型中，MFA 的作用并不是“提高一点安全性”，而是 直接切断绝大多数常见入侵路径： 因此，在 VPN、远程管理、邮件系统、云控制台等关键入口未启用 MFA 的情况下，企业几乎处于高风险状态。 一个重要的现实结论 从大量企业勒索案例可以观察到： 攻击者并不依赖“技术上一定能攻破”，而是选择最省成本、最容易得手、最容易横向扩散的入口。 这意味着，安全的核心并不是假设攻击者会被法律阻止，而是： 总结 Asahi 事件并不说明“大企业不懂安全”，而是揭示了现实世界的安全边界： 从工程视角看，多因素认证 + 最小入口原则，依然是对抗现实勒索威胁最有效、性价比最高的防线。

Network

OpenWrt LuCI 是否支持两步验证（2FA）？以及更安全的实践方案

一、问题背景 在使用 OpenWrt 作为家庭或个人网络核心时，一个很自然的问题是： LuCI 管理界面是否支持两步验证（2FA / TOTP）？ 这个问题在“公网 IP + 自建服务 + 长期运行”的场景下尤其常见，因为一旦路由器被入侵，后果往往是灾难性的。 本文将从事实、原因和现实可行的安全实践三个层面，系统回答这个问题。 二、结论先行 结论很明确： OpenWrt 官方的 LuCI 管理界面，并不原生支持两步验证（2FA）。 而且这并不是功能缺失，而是一个有意的设计取舍。 三、为什么 LuCI 没有原生 2FA LuCI 的设计目标与典型的 Web 后台系统完全不同： 技术上，LuCI 的认证模型通常是： 在这个模型下： 因此，官方并没有为 LuCI 设计内建 2FA，也没有计划添加。 四、一个重要认知：LuCI 是否真的“需要”2FA？ 在实际运维中，几乎没有人依赖 LuCI 自身来承担公网安全责任。 原因很简单： 真正的安全，从来不是在“最后一层登录页”加功能，而是从入口设计开始。 对 LuCI 而言，安全的关键问题不是： 而是： 五、更现实、更可靠的安全实践（推荐方案） 以下方案按照安全收益 …

SSH

OpenWrt 配置 SSH 使用密钥登录（关闭密码认证）

在 OpenWrt 路由系统中，SSH 默认使用 Dropbear 作为服务端，并允许密码登录。在具备公网访问、端口转发或远程运维场景下，切换为仅密钥登录可以显著降低暴力破解与误入侵风险。 本文记录 OpenWrt 中将 SSH 登录方式由“密码 + 密钥”调整为“仅密钥”的完整过程，并附带常见注意事项。 一、OpenWrt 中 SSH 的配置位置 OpenWrt 提供两种主要配置方式： 底层服务均由 Dropbear 控制。 二、通过 LuCI Web 界面配置（直观方式） 配置路径 关键设置项 保存并应用即可生效。 三、通过命令行配置（可控性更高） 1️⃣ 准备 SSH 公钥（客户端） 在客户端生成或查看公钥，例如： 复制输出的整行内容。 2️⃣ 写入 OpenWrt 的 authorized_keys 登录 OpenWrt（此阶段仍保留密码登录）： 创建并编辑公钥文件： 示例内容： 设置正确权限（非常重要）： 3️⃣ 禁用 SSH 密码认证 …

Network

家庭网络自建邮件服务器：关于是否需要固定 IP 的一次完整评估

一、场景说明 在一个典型的家庭自托管环境中，网络结构通常具备以下特征： 邮件服务器并非面向公众提供邮箱服务，而是用于： 是否接收来自互联网的外部邮件，并非初始刚性需求。 二、最初遇到的现实限制 1. VPS 方案的端口问题 常见的做法是使用一台低成本 VPS 作为公网入口或中转节点。然而在实践中发现： 即便 VPS 成本低廉，只要 25 端口被封禁，在邮件接收场景下就会出现功能性不可用的问题。 2. 家庭宽带（MAP-E / IPv4 over IPv6）的天然约束 在未申请固定 IPv4 的家庭宽带环境中，常见网络形态包括： 在这种情况下： 因此，“直接在家庭网络中接收外部邮件”在默认条件下并不可行。 三、被认真评估的解决方案：家庭固定 IPv4 为了解决端口受限问题，评估了运营商提供的固定 IPv4 服务。该方案在技术层面具有明确优势： 成本结构（已脱敏） 与现有 VPS（月费约 500 日元）相比，固定 IP 带来了额外且长期的成本。 四、关键转折：重新界定真实需求 在进一步分析后，一个核心问题被重新提出： 邮件服务器当前是否真的需要接收来自外部的邮件？ 对邮件系统的实际用途进行梳理后，可以明确： 由此可以得出一个重要结论： “无法接收外部邮件”并不会影响当前系统的实际功能价值。 五、工程视角下的理性判断 1. 固定 IP 的技术价值是确定的 …