模块6：网络安全、加密及安全通信实战-平芜编程栈

模块6：网络安全、加密及安全通信实战

面向 Linux 云计算工程师的网络安全与密码学实战笔记。所有命令输出均来自真实运行：
概念类脚本在本地bash 5.3.9/OpenSSL 3.5.6/python3实跑；主机侧证据由paramiko实连
你提供的 4 台华为云 ECS（Ubuntu 24.04）+ atomcode 部署机（Ubuntu 22.04）以root 只读巡检+/tmp 下非破坏性加密实战得到。
全程未修改任何生产主机的防火墙、sshd 配置或业务文件。

0. 实验环境与开篇说明

主机	角色	公网 IP	私网 IP	系统	规格
ecs-146b-0001	Web/DNS	113.44.140.3	192.168.0.90	Ubuntu 24.04	8vCPU/16G
ecs-146b-0002	Web(apache2)	123.60.217.187	192.168.0.230	Ubuntu 24.04	8vCPU/16G
ecs-146b-0003	NFS/rpcbind	114.116.226.73	192.168.0.229	Ubuntu 24.04	8vCPU/16G
ecs-146b-0004	基础	120.46.91.123	192.168.0.248	Ubuntu 24.04	8vCPU/16G
atomcode	部署机	117.72.182.3	172.16.0.3	Ubuntu 22.04	—

安全约定：巡检命令全部只读（ufw/iptables/nft/ss/sshd -T/last/lastb/配置cat）；
加密实战在/tmp下生成临时密钥/证书/密文，不触碰任何业务文件与系统配置、不重启服务。

1. 本篇使用的提示词（Prompt）与工具

提示词（即本次任务指令，节选）：

参考教学目标：掌握网络安全、加密及安全通信。 关键技能：对称/非对称加密、哈希、PKI 与数字证书、SSH 安全通信、 防火墙(ufw/iptables)、TLS/HTTPS、主机安全基线、VPN/隧道。 提供 4 台 ECS + atomcode 部署机（root 密码已给）。 需要实操，并且体现实操效果，需要体现提示词，和使用工具， 源码代码仓库地址，输出博客《模块6:网络安全、加密及安全通信实战》， 适合在互联网平台发表。

使用的工具：

本地：Git Bashbash 5.3.9、OpenSSL 3.5.6、python3 3.13、sha256sum、gpg、ssh、curl
远程采集：paramiko（Python SSH 库）——密码 SSH 实连 5 台主机，执行只读命令
被采主机自带：OpenSSL 3.0.13、OpenSSH 9.6p1、ufw、iptables/nft、ss、AppArmor

2. 密码学三支柱：对称 / 非对称 / 哈希

先建立最核心的心智模型，再用脚本把"看不见"的密码学跑出"看得见"的结果。

2.1 对称加密：同一把密钥加解密（本地 XOR 演示）

bashscripts/01_symmetric_demo.sh

明文 : TOP SECRET 2026 明文(hex) : 544f50205345435245542032303236 密钥 : 0x5A (0x5A) 密文(hex) : 0E150A7A091F19081F0E7A686A686C <- 无明文特征，看似随机 解密(hex) : 544F50205345435245542032303236 ✓ 解密hex == 原始hex => 同一个密钥完成加解密（这就是对称加密） 密钥泄露=全盘泄露 => 故需用非对称/DH 安全协商出对称密钥

工业级对称算法是AES（本篇 4.3 在真实主机用openssl enc -aes-256-cbc实跑）。
对称加密快，但"如何安全把密钥分给对方"是难题——交给下一节。

2.2 非对称加密 & 密钥协商：Diffie-Hellman（本地数值演示）

bashscripts/03_diffie_hellman.py

公开参数(可被窃听): 大素数 p=23, 生成元 g=5 Alice 私钥 a=19 (保密); 公开值 A=g^a mod p=7 Bob 私钥 b=7 (保密); 公开值 B=g^b mod p=17 Alice 算出共享密钥 = 5 Bob 算出共享密钥 = 5 双方相等? True 窃听者只知道 p,g,A,B，想反推 a/b 需要解离散对数(大数下计算不可行)=>安全

DH 解决了"在不安全信道上协商共享密钥"的问题；RSA/ECDSA 则用于加密/签名。
真实主机的ssh-keygen -t ed25519（2.3、4.1）用的就是非对称密钥对。

2.3 哈希与完整性 / 数字签名（本地实跑）

bashscripts/02_hash_integrity.sh

原始哈希: 8983e91ded45e38b442ccc659e2e7b6a7522334246fe736a30d8bc02a8768bd0 篡改哈希: 65b53ad27552c6b1458c18a8b7b52543686e9bebf99d0ca3c2109ebd0d089109 ✓ 哪怕改一个字，完整性校验立即失败 正常消息 HMAC: 05b826e435ea4105feb7d820e5828bdf352a6534fc6e23efbd6b6cd4bbcd5703 篡改消息 HMAC: 7b5086965e572e6307b471e28500c45ea3f93c4078fb623ff604cbdb6f0970ee ✓ 内容一改 HMAC 立即不同 => 接收方比对即知被篡改/伪造 ✓ 篡改后验签失败 => 签名绑定原文，无法抵赖/伪造

三种原语职责不同：哈希=完整性；HMAC=完整性+身份认证；非对称签名=完整性+身份认证+不可抵赖。

3. PKI 与数字证书：CA、自签、证书链

3.1 自签 X.509 证书（真实主机 113.44.140.3 实跑）

# 在真实主机 /tmp 下生成 RSA 私钥 + 自签证书（非破坏性）openssl genrsa-out/tmp/demo.key2048openssl req-new-x509-key/tmp/demo.key-out/tmp/demo.crt-days365\-subj"/C=CN/ST=BJ/L=BJ/O=DemoOrg/OU=Sec/CN=demo.example.com"openssl x509-in/tmp/demo.crt-noout-subject-issuer-dates-serial

subject=C = CN, ST = BJ, L = BJ, O = DemoOrg, OU = Sec, CN = demo.example.com issuer =C = CN, ST = BJ, L = BJ, O = DemoOrg, OU = Sec, CN = demo.example.com # 签发者==主体 => 自签名 notBefore=Jul 20 14:10:08 2026 GMT notAfter =Jul 20 14:10:08 2027 GMT serial =2679B55A23168696A6DBFCE600B9FA4B09034191

证书文本关键字段：

Certificate: Data: Version: 3 (0x2) Signature Algorithm: sha256WithRSAEncryption Issuer: C = CN, ST = BJ, ... CN = demo.example.com Validity Not Before: Jul 20 14:10:08 2026 GMT Not After : Jul 20 14:10:08 2027 GMT Subject: C = CN, ST = BJ, ... CN = demo.example.com Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit)

自签名证书的"签发者==主体"，浏览器/客户端默认不信任——只适合内部测试。
生产用证书须由受信任CA（如 Let’s Encrypt、DigiCert、GlobalSign）签发，形成证书链。

3.2 真实公网证书链（真实主机`openssl s_client`实跑）

openssl s_client-connectwww.baidu.com:443-servernamewww.baidu.com</dev/null2>/dev/null\|grep-E"^subject|^issuer|^Verify"

subject=C = CN, ... O = "Beijing Baidu Netcom Science Technology Co., Ltd", CN = baidu.com issuer =C = BE, O = GlobalSign nv-sa, CN = GlobalSign RSA OV SSL CA 2018 Verify return code: 0 (ok) # 证书链受信任、验签通过

第二台主机对www.qq.com抓取，签发者为DigiCert Secure Site OV G2——印证了不同站点由不同受信任 CA 背书。

TLS 握手时，服务器把"站点证书 + 中间 CA 证书"发给客户端，客户端用本地信任库中的根 CA逐级验签，
任一环断裂即报警（如自签、过期、域名不符）。

4. SSH 安全通信：密钥登录与 sshd 加固

4.1 生成密钥对（真实主机 + 本地双实跑）

ssh-keygen-ted25519-f/tmp/demo_ed25519-N""-C"demo@security"cat/tmp/demo_ed25519.pub ssh-keygen-lf/tmp/demo_ed25519.pub

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIAkQ7gGSLF2v2nDBpELdPN/OBIOnL25+ivkAEbilo4KK demo@security 256 SHA256:x7VShcBd5UuDfAClYTS2Mp8vdsYPD6Oeue3QSqQ0GF8 demo@security (ED25519)

免密登录原理（挑战-应答）：服务器持公钥(~/.ssh/authorized_keys)，客户端持私钥；
服务器发随机挑战 → 客户端用私钥签名 → 服务器用公钥验签。验过即证明"你持有私钥"，
全程不传密码，天然抗窃听、抗暴破。

4.2 真实主机 sshd 配置审计（4 台 ECS 巡检一致）

sshd-T|grep-Ei'permitrootlogin|passwordauthentication|pubkeyauthentication|x11forwarding'

port 22 maxauthtries 6 permitrootlogin yes # ⚠ 允许 root 直接登录 passwordauthentication yes # ⚠ 允许密码登录（暴破风险） pubkeyauthentication yes x11forwarding yes # 可关，减小攻击面 permitemptypasswords no

这 4 台主机的 sshd 都允许 root + 密码登录。配合下面的"失败登录"证据，这正是
互联网上 SSH 暴破最爱钻的口子。生产建议：PermitRootLogin no、PasswordAuthentication no、
仅留PubkeyAuthentication yes（见第 8 章加固示例）。

5. TLS/HTTPS：传输层安全实战验证

除 3.2 的s_client外，本地也直接验证了公网 TLS（需联网）：

bashscripts/05_tls_inspect.sh

--- www.baidu.com --- subject=C=CN, ... CN=baidu.com issuer=C=BE, O=GlobalSign nv-sa, CN=GlobalSign RSA OV SSL CA 2018 Protocol: TLSv1.2 Verify return code: 0 (ok) --- www.qq.com --- subject=C=CN, ... CN=www.qq.com issuer=C=US, O=DigiCert, Inc., CN=DigiCert Secure Site OV G2 TLS CN RSA4096 SHA256 2022 CA1 Protocol: TLSv1.2 Verify return code: 0 (ok) * ALPN: server accepted http/1.1 < HTTP/1.1 200 OK

看到issuer=GlobalSign/DigiCert等受信任 CA、Verify return code: 0 (ok)，即说明证书链可信、
TLS 加密通道已建立。现代站点普遍协商到TLS 1.2/1.3（TLS 1.0/1.1 已废弃）。

6. 防火墙：ufw / iptables / nftables

6.1 真实主机防火墙状态（巡检结果）

4 台 ECS 的ufw status均为Status: inactive，iptables各链policy ACCEPT且无规则：

### 防火墙 ufw 状态 Status: inactive ### iptables 规则 Chain INPUT (policy ACCEPT 0 packets, 0 bytes) Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)

⚠4 台生产主机均未启用主机防火墙，安全组是唯一边界。若安全组配置失误，主机直接暴露。

6.2 atomcode 部署机的云厂商 HIDS 链

atomcode(117.72.182.3, Ubuntu 22.04) 的iptables/nft里能看到云厂商注入的
主机入侵检测（HIDS）链JDCLOUDHIDS_*：

Chain JDCLOUDHIDS_IN (1 references) Chain JDCLOUDHIDS_OUT (1 references) table ip filter { chain INPUT { type filter hook input priority filter; policy accept; counter packets 13399947 ... jump JDCLOUDHIDS_IN_LIVE counter packets 13399947 ... jump JDCLOUDHIDS_IN } ... }

6.3 ufw 最小可用规则示例（文档，未在生产执行）

# 默认拒绝入站、允许出站；仅放行 SSH(改端口更佳) 与业务端口ufw default deny incoming ufw default allow outgoing ufw allow22/tcp# 建议改成非 22 端口 + 仅限运维 IPufw allow80,443/tcp ufwenable# 查看ufw status verbose# nftables 等价：nft add rule inet filter input tcp dport 22 accept

7. 主机安全基线：端口 / 服务 / 用户 / 登录审计

7.1 监听端口与暴露面（真实主机`ss -tunap`节选）

主机	暴露的关键服务
ecs-146b-0001	`named`(DNS) 192.168.0.90:53、127.0.0.1:53；`nginx`进程
ecs-146b-0002	`apache2`:80 / :443、`sshd`:22
ecs-146b-0003	`rpcbind`:111、`rpc.mountd`(NFS 暴露)
atomcode	`sshd`:22、`atomcode`代理:13457、多个`python3`(5000/8080/9090…)

rpcbind(111) 与 NFS 直接绑在0.0.0.0上是经典高危面，应限制来源或用nft仅放行内网。

7.2 失败登录 = 真实暴破证据（巡检`lastb`）

ecs-146b-0002 的lastb直接抓到字典式暴破（来源45.156.87.70）：

dev ssh:notty 45.156.87.70 Mon Jul 20 22:08 sharon ssh:notty 45.156.87.70 Mon Jul 20 22:08 ian ssh:notty 45.156.87.70 Mon Jul 20 22:08 user1 ssh:notty 45.156.87.70 Mon Jul 20 22:08

ecs-146b-0001 也出现对root的ssh失败登录（来源114.116.217.165），且ss中可见SYN-RECV态的入向 SSH 连接——
这是正在发生的扫描/暴破。结论：必须关密码登录、改端口、上 fail2ban/云安全组限速。

7.3 强制访问控制

4 台 ECS 均为AppArmor（apparmor module is loaded，121 个 profile、26 个 enforce），
SELinux 未启用——Ubuntu 系默认用 AppArmor，区别于 CentOS/RHEL 的 SELinux。

8. 安全加固实战（示例配置，未在生产执行以免影响业务）

把第 4/6/7 章的发现落成可落地的加固。以下为示例文件，本篇未写入任何生产主机：

/etc/ssh/sshd_config.d/10-hardening.conf

Port 2222 # 改默认端口，减少自动化暴破 PermitRootLogin no # 禁止 root 直登 PasswordAuthentication no # 仅公钥 PubkeyAuthentication yes MaxAuthTries 3 ClientAliveInterval 300 X11Forwarding no

配套防火墙（仅放行业务+新 SSH 端口、限制来源）：

ufw allow from 运维IP to any port2222proto tcp ufw allow80,443/tcp ufw default deny incoming&&ufwenable

再加fail2ban自动封禁暴破 IP，与第 7.2 的真实攻击日志形成闭环。

9. 隧道与 VPN：加密通道的"安全通信"延伸

VPN 的本质 =密钥协商（非对称/DH，第 2/3 章）+ 对称加密数据（第 2 章）+ 路由转发。
下面把"临时隧道（SSH）"和"站点级 VPN（WireGuard / IPsec）"都跑出真实配置与证据。

9.1 SSH 加密隧道（临时安全通信利器）

# 本地转发：把本机 8080 映射到远程内网服务(192.168.0.90:80)ssh-N-L8080:192.168.0.90:80 user@跳板机# 远程转发：把远程 9000 暴露到本机(内网穿透)ssh-N-R9000:localhost:3000 user@公网机# 动态 socks 代理(-D)，浏览器走加密通道出网ssh-N-D1080user@跳板机

真实主机ss里已能看到ESTAB的 SSH 加密会话与SYN-SENT（atomcode 上python3主动连
192.0.2.99:9999的探测）——加密通道就在你眼前跑着。

9.2 WireGuard：极简高性能站点 VPN（真实密钥实跑）

WireGuard 用Curve25519做密钥交换、ChaCha20/AES 做对称加密、无需 PKI/CA，靠"预交换公钥"互信。
本地无wg命令，用openssl X25519直接产出标准 WG 格式密钥（见scripts/06_vpn_demo.sh）：

bashscripts/06_vpn_demo.sh

########## A. WireGuard 密钥对 (Curve25519 / X25519) ########## server priv(Base64,44) = uBcR6osFUcAYdJphaaRJjuZFwS6mRZ0+L796beTCDHQ= server pub (Base64,44) = X64mBXHMpbL/Ch424P0Ofw2H1f4MLxJBcmzKgKfJlhU= client priv(Base64,44) = iPOQHkX03yR56KnpgQT2291H50ntGQW7TL6+tmSAVF8= client pub (Base64,44) = qvNz5zvvNsnrRkrQDaONtJL57JX4rvQacrrXq6Oor2Q=

44 字符的 Base64 正是 32 字节 Curve25519 密钥的标准 WireGuard 格式（wg genkey产物同此）。
把对端pub填进本方[Peer]，即可完成身份认证——没有 CA、没有证书分发。

可运行配置（vpn-configs/wg-server.conf/wg-client.conf，用上面的真实公钥/私钥替换占位符）：

wg-server.conf（中心站点）：

[Interface] Address = 10.0.0.1/24 ListenPort = 51820 PrivateKey = <SERVER_PRIVATE_KEY> # 上一步 server priv PostUp = sysctl -w net.ipv4.ip_forward=1 PostUp = iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o eth0 -j MASQUERADE PostDown = iptables -t nat -D POSTROUTING -s 10.0.0.0/24 -o eth0 -j MASQUERADE [Peer] PublicKey = <CLIENT_PUBLIC_KEY> # 上一步 client pub AllowedIPs = 10.0.0.2/32, 192.168.10.0/24 # 仅放行对端隧道IP + 对端内网(最小权限)

wg-client.conf（分支/移动端）：

[Interface] Address = 10.0.0.2/24 PrivateKey = <CLIENT_PRIVATE_KEY> DNS = 10.0.0.1 [Peer] PublicKey = <SERVER_PUBLIC_KEY> Endpoint = 113.44.140.3:51820 AllowedIPs = 0.0.0.0/0 # 全流量走隧道; 站点互联则只写对端网段 PersistentKeepalive = 25

启停与验证（在真实 Linux 主机，需wireguard-tools）：

cpwg-server.conf /etc/wireguard/wg0.conf wg-quick up wg0# 拉起接口wg show# 查看握手/流量# 预期: interface: wg0 / public key: X64m... / peer: qvNz... / latest handshake: <时间> / transfer: <上行>/<下行>sysctlnet.ipv4.ip_forward=1# 若需互访对端内网

9.3 IPsec（strongSwan）：企业级站点到站点 VPN（真实证书链实跑）

IPsec 走IKEv2 + ESP，站点间用证书双向认证——正好复用第 3 章 PKI。
用scripts/06_vpn_demo.sh的 B 段已实跑出"根 CA → 站点证书"链：

########## B. IPsec PKI：自建根 CA + 两个站点证书 (证书链) ########## --- B1. 根 CA (自签, 仅此一次) --- subject=C=CN, ST=BJ, O=VPN-CA, CN=VPN-Root-CA serial=1F2184AC512F65A8F936E0EB0DB6D0CD27C6FFAB --- B2. 站点 siteA 证书 (由根 CA 签发) --- subject=C=CN, ST=BJ, O=VPN, CN=siteA.example.com issuer =C=CN, ST=BJ, O=VPN-CA, CN=VPN-Root-CA # issuer≠subject => 由 CA 签发(非自签) serial =68FFB1DD9D5A63BEFDAFBFADC9C3307769E30DBB notBefore=Jul 20 14:43:37 2026 GMT notAfter =Oct 22 14:43:38 2028 GMT --- B2. 站点 siteB 证书 (由根 CA 签发) --- subject=C=CN, ST=BJ, O=VPN, CN=siteB.example.com issuer =C=CN, ST=BJ, O=VPN-CA, CN=VPN-Root-CA # 与 siteA 同根 CA

siteA/siteB的issuer 都是 VPN-Root-CA，与第 3 章"证书链"完全对应：两站各持自己的
cert+key，并互信对方根 CA，即可完成 IKEv2 双向认证，无需共享密码。

可运行配置（vpn-configs/ipsec-siteA.conf/ipsec-siteB.conf/ipsec.secrets）：

/etc/ipsec.conf（站点 A 视角，IKEv2 + 证书）：

config setup charondebug="ike 2, knl 2, cfg 2" conn siteA-to-siteB type = tunnel auto = start keyexchange = ikev2 ike = aes256-sha256-modp2048 # IKE SA: 非对称协商(第2/3章) esp = aes256-sha256-modp2048 # IPsec SA: 对称加密数据(第2章) left = 10.0.0.1 leftcert = siteA.crt leftid = siteA.example.com leftsubnet = 192.168.10.0/24 right = 10.0.0.2 rightid = siteB.example.com rightsubnet = 192.168.20.0/24

/etc/ipsec.secrets：: RSA siteA.key（本站私钥，绝不入库/不提交）。
启停与验证（真实主机，需strongswan）：

ipsec start# 或: systemctl start strongswanipsec statusall# 预期: "Connections: siteA-to-siteB"; "Security Associations: siteA-to-siteB: #1, ESTABLISHED"swanctl --list-conns# 现代 strongSwan 也可

证书生成脚本见vpn-configs/gen-ipsec-certs.sh（与 9.3 实跑同源）。

9.4 WireGuard vs IPsec 选型对照

维度	WireGuard	IPsec (strongSwan/IKEv2)
握手/协商	Curve25519，秒级	IKEv2，多轮
加密原语	ChaCha20 / AES-GCM	AES / 3DES / 多种
身份体系	公钥直填（无 CA）	证书（PKI）或 PSK
配置复杂度	极简（十几行）	较复杂（需 PKI/策略）
内核/性能	主线内核模块，快	用户态 charon，较重
典型场景	现代站点互联、移动端、云主机	企业合规、与旧设备互通、硬件 VPN

二者都遵循"非对称协商密钥 + 对称加密数据"这一第 2 章主线；WireGuard 把 PKI 拿掉更轻，
IPsec 借 PKI 更易做大规模互信与合规审计。

10. 真实主机安全巡检报告（汇总）

5 台主机只读巡检 + 2 台加密实战，原始日志见outputs/：

113.44.140.3_sec.log/_crypto.log（全量：密钥对、自签证书、AES、哈希、baidu TLS、openssl 性能）
123.60.217.187_sec.log/_crypto2.log（apache2 + 暴破证据 + qq TLS）
114.116.226.73_sec.log、120.46.91.123_sec.log（NFS/rpcbind、基础基线）
117.72.182.3_sec.log（atomcode：JDCLOUDHIDS HIDS 链、python 服务）

关键发现（真实）：

4 台 ECS 防火墙ufw inactive、iptables 空规则——主机层零防护。
全部PermitRootLogin yes+PasswordAuthentication yes——root 密码 SSH 直登。
lastb显示dev/sharon/ian/user1等字典暴破（来源 45.156.87.70），ss见SYN-RECV入向 SSH。
ecs-146b-0003 的rpcbind:111 / NFS 绑0.0.0.0，暴露面偏大。
atomcode 上云厂商JDCLOUDHIDS链已注入，说明平台侧有 HIDS 兜底。

openssl 性能基准（真实主机，节选）：

type 16 bytes ... 16384 bytes sha256 130774k ... 1788433k # 哈希极快 aes-256-cbc 873594k ... 1027287k # 对称加密快(GB/s 级) rsa 2048 bits sign 4117.7/s verify 61404.5/s # 非对称慢，故仅用于"握手/签名"

这张表解释了工程现实：非对称慢、对称快→ TLS 用非对称做密钥协商、之后切对称加密正文。

11. 源码仓库与复现方法

仓库地址（Gitee）：https://gitee.com/LiaCin/linux-security-practice

注：Gitee 新建仓库默认私有。如需公开，请在仓库Settings → 基本信息中把「是否公开」改为「公开」。本博客内容本身可独立在互联网平台发表。

# 1) 克隆gitclone https://gitee.com/LiaCin/linux-security-practice.gitcdlinux-security-practice# 2) 本地实跑全部密码学/概念演示（无需任何外部依赖）bashscripts/run_all.sh# 3) 对自有云主机做只读安全巡检 + 非破坏性加密实战（需 Python + paramiko）pipinstallparamiko python scripts/diag_security.py# 按脚本内 HOSTS 列表修改 IP/账号

目录结构：

linux-security-practice/ ├── README.md # 项目说明(本文件) ├── 模块6-网络安全、加密及安全通信实战.md # 本博客 ├── scripts/ │ ├── 01_symmetric_demo.sh # 对称加密(XOR)直观演示 │ ├── 02_hash_integrity.sh # 哈希/HMAC/数字签名演示 │ ├── 03_diffie_hellman.py # DH 密钥协商数值演示 │ ├── 04_ssh_key_demo.sh # SSH 密钥对与免密原理 │ ├── 05_tls_inspect.sh # 真实公网 TLS 证书链验证 │ ├── 06_vpn_demo.sh # WireGuard 密钥对 + IPsec PKI 证书链(本地实跑) │ ├── diag_security.py # 真实主机只读巡检 + 加密实战采集器(凭据走环境变量) │ └── run_all.sh ├── vpn-configs/ # 可运行 VPN 配置模板(第9章) │ ├── wg-server.conf / wg-client.conf # WireGuard 中心/分支配置 │ ├── ipsec-siteA.conf / ipsec-siteB.conf / ipsec.secrets # strongSwan IKEv2 │ └── gen-ipsec-certs.sh # 生成 IPsec PKI(根CA+两站点证书) ├── outputs/ │ ├── local_demo.log # 本地实跑输出 │ ├── 06_vpn_demo.log # WireGuard/IPsec 实跑证据(真实密钥与证书链) │ ├── 113.44.140.3_sec.log / _crypto.log │ ├── 123.60.217.187_sec.log / _crypto2.log │ ├── 114.116.226.73_sec.log │ ├── 120.46.91.123_sec.log │ └── 117.72.182.3_sec.log └── docs/ └── diag.md # 采集器使用说明

12. 面试高频考点小结

对称 vs 非对称 vs 哈希—— 对称快(AES)用于加密正文；非对称(RSA/ECC)用于密钥协商/签名；哈希(SHA)用于完整性。
DH 密钥交换—— 不安全信道协商共享密钥，安全性依赖离散对数难题。
PKI/证书链—— 根 CA → 中间 CA → 站点证书；客户端用本地信任库逐级验签。
自签 vs CA 签发—— 自签"签发者==主体"，不被默认信任，仅内部测试用。
SSH 加固—— 禁 root 直登、禁密码、仅公钥、改端口、fail2ban。
TLS 握手—— 协商密码套件 + 证书验签 + 生成会话密钥；现代用 TLS1.2/1.3。
防火墙——ufw(易用)/iptables(传统)/nftables(新默认)；默认拒绝入站。
主机基线——ss看暴露面、lastb看暴破、ufw看边界、AppArmor/SELinux 看 MAC。
NFS/rpcbind—— 勿绑0.0.0.0，限制来源，否则成入侵跳板。
工程取舍—— 非对称慢、对称快 → "非对称协商 + 对称加密"是 TLS/SSH 的通行做法。
VPN 两类—— WireGuard（Curve25519 公钥直填、无 CA、极简快）；IPsec/IKEv2（证书/PKI 认证、企业合规、与旧设备互通）。二者均为"非对称协商 + 对称加密数据"。
WG 密钥格式—— 44 字符 Base64 = 32 字节 Curve25519 私钥（wg genkey与openssl X25519等价）。

本文所有命令输出均来自真实运行（本地bash 5.3.9/OpenSSL 3.5.6/python3，或 4 台 ECS + atomcode 真实主机实采），可放心引用。安全巡检为只读、VPN 概念演示在本地临时目录（.vpn_demo/）与真实主机的/tmp下非破坏生成密钥/证书，未对任何生产主机做写操作。

模块6：网络安全、加密及安全通信实战