scp（安全复制）：这是最基础的命令之一，通过 SSH 加密传输，适合快速传输。
scp /path/to/local/file.txt username@remote_ip:/path/to/remote/directory/scp username@remote_ip:/path/to/remote/file.txt /local/path/-r选项，例如 scp -r /local/dir username@remote_ip:/remote/path/
-C选项开启压缩以提高速度制定端口：
使用 -P(大写) 指定端口
1 | scp -P 10022 cxing@turing001:~/gcc15.bashrc . |
Happyn：基于 N2N 的安全、易于使用的虚拟专用网络（VPN）解决方案。客户端已开源。
适用：团队多人、要审计/审批、要零暴露。
优点：
10 分钟 PoC 路线
tsh login（走 SSO/MFA）→ tsh ssh A 直连；在 Web 控制台能看到会话记录。适用：不引入 SaaS，又想快速可控；审计要求适中。
做法：
TrustedUserCAKeys），给运维颁发短期用户证书（建议用 Smallstep step-ca 自动签发/轮换）。tlog/auditd + 日志平台）。cloudflared 出站连边缘；基于 SSO/MFA 的短期证书，审计完善，上线最快。PasswordAuthentication no；必要时 PermitRootLogin no。https://e.huawei.com/cn/products/security
HiSecEngine USG12000 系列 AI 防火墙
HiSecEngine USG12000 系列防火墙（以下简称 USG12000 系列）是华为公司推出的首款T级AI防火墙，在网络边界实时防护已知与未知威胁，通常部署在云计算数据中心，大型企业及园区网出口，为数据中心、企业及园区网络提供领先的安全防护能力。USG12000系列采用先进的硬件架构设计，应用多种绿色节能创新技术，大幅降低设备能源消耗。提供全类型接口板，单槽位接口密度最高可达18x100GE，满足大流量需求。广泛应用于政府，金融，安平，教育，医疗，企业等行业。
提供高达T级的业务处理性能，集成NAT、CGN、VPN、虚拟化以及内容安全等多种安全特性，应对新时代大流量、多业务威胁防御场景。
具备完善的运营商级高可靠性架构和方案，支持双主控、双机热备、NSR、GR等多种可靠性机制。采用基于硬件的软件完整性校验，避免非法软件运行，打造安全基石。用户可以根据不同的网络需求进行灵活的选择。
华为 HiSecEngine USG6700F 系列 AI 防火墙
是华为面向下一代数据中心推出的高性能万兆AI防火墙，通过全新软硬件架构，打造具备智能防御、卓越性能、极简运维三大关键能力的新一代AI防火墙，有效应对挑战。USG6700F系列使用智能技术赋能边界防御，精准阻断已知和未知威胁；内置多个安全专用加速引擎有效提升IPv4/IPv6转发、内容安全检测、IPSec等关键业务处理性能；通过安全运维平台实现防火墙、入侵防御、抗DDoS等多类安全产品的统一管理和运维，降低安全运维OPEX。
HiSecEngine USG6600F 系列 AI 防火墙
华为 HiSecEngine USG6600F 系列是华为面向下一代数据中心推出的万兆AI防火墙，HiSecEngine USG6600F系列基于最新软硬件平台，提供IPv4/IPv6共栈能力，业务性能大幅提升；使用智能技术有效检测高级威胁，增强边界防护能力。支持联动华为乾坤安全云服务，提供边界防护与响应服务，端云联动，立体防御。广泛适用于金融、政府、大企业等行业。
HiSecEngine USG6500F 系列 AI 防火墙
HiSecEngine USG6500F 系列 AI 防火墙是华为面向小型企业、行业分支、连锁商业机构设计开发的新一代AI防火墙，在提供NGFW能力的基础上，联动其他安全设备，增强边界检测能力，有效防御高级威胁。产品提供模式匹配以及加解密业务处理加速能力，使得防火墙处理内容安全检测、IPSec等业务的性能显著提升。支持联动华为乾坤安全云服务，提供边界防护与响应、漏洞扫描、日志审计等服务，端云联动，立体防御，广泛适用于教育、医疗、零售等行业。
华为 HiSecEngine USG6000F-E 系列防火墙
HiSecEngine USG6000F-E系列防火墙是华为面向中小型企业和多分支机构推出的高性能防火墙，适用于各类场景和网络安全建设需求。通过全新软硬件平台来实现功能全面、高性能、低时延的智能防火墙。
华为 HiSecEngine USG6700E 系列 AI 防火墙
华为HiSecEngine USG6700E系列AI防火墙（盒式）是面向下一代数据中心和和大型企业园区网推出的万兆AI防火墙，在提供NGFW能力的基础上，联动其他安全设备，主动防御网络威胁，增强边界检测能力，有效防御高级威胁，同时解决性能下降问题。NP引擎提供快速转发能力，防火墙性能显著提升。广泛适用于金融、政府、大企业等行业。
HiSecEngine USG6600E 系列 AI 防火墙
华为 HiSecEngine USG6600E 系列 AI 防火墙是面向下一代数据中心推出的万兆AI防火墙，在提供NGFW能力的基础上，联动其他安全设备，主动防御网络威胁，增强边界检测能力，有效防御高级威胁，同时解决性能下降问题。NP提供快速转发能力，防火墙性能显著提升。广泛适用于金融、政府、大企业等行业。
HiSecEngine USG6500E 系列 AI 防火墙
华为 HiSecEngine USG6500E 系列 AI 防火墙是面向中小企业和连锁机构推出的企业级AI防火墙，在提供NGFW能力的基础上，联动其他安全设备，主动积极防御网络威胁，增强边界检测能力，有效防御高级威胁，同时解决性能下降问题。产品提供模式匹配以及加解密业务处理加速能力，使得防火墙处理内容安全检测、IPSec等业务的性能显著提升。支持联动华为乾坤安全云服务，提供边界防护与响应、漏洞扫描、日志审计等服务，端云联动，立体防御。广泛适用于教育、医疗、零售等行业。
桌面款
Tailscale 是基于 WireGuard 的虚拟组网工具。提供免费、收费的托管控制服务。
Headscale 是 Tailescale 控制服务器的开源、自托管实现。
Podman 相比 Docker 的好处是，Podman可以经由管理员的权限下放让普通用户也可以操作容器，在服务器上跑容器映射的实验。
自检命令（不需要管理员权限）：
1 | podman info --debug | sed -n '1,120p' |
podman info 里如果显示 rootless 正常、存储/网络组件齐全，基本就能开干。/etc/subuid / /etc/subgid 没你的条目，很多情况下会导致功能受限或直接失败，这就需要管理员加。1 | host: |
以上的信息说明：
security.rootless: true ✅（你现在就是以普通用户在用 Podman）idMappings 里有一段 65536 的 uid/gid 映射 ✅（说明 subuid/subgid 也配了，rootless 功能比较完整）cgroupVersion: v2 + cgroupManager: systemd ✅（资源隔离走 systemd/cgroup v2）networkBackend: netavark 且 rootlessNetworkCmd: pasta ✅（rootless 网络也能用）需要注意的几个“普通用户限制点”
cgroupControllers 只有 memory 和 pids（没有 cpu）。所以像 --cpus、CPU quota 这类参数可能不生效或会报错；内存/进程数限制一般是可用的。selinuxEnabled: true）。挂载宿主机目录时，常见要加 :Z：podman run --rm -it -v "$PWD:/work:Z" ubuntu:22.04 bash-p，但 <1024 的端口在 rootless 下通常不行（除非管理员改过系统策略）。临时起一个交互容器做实验（推荐）
1 | podman run --rm -it ubuntu:22.04 bash |
进已经在跑的容器
1 | podman ps |
准备目录
1 | mkdir -p ~/headscale/{config,lib,run} |
下载对应版本的示例配置：
1 | curl -fsSL \ |
示例配置里包含 server_url、listen_addr、数据库路径、dns.base_domain 等关键项。
用你熟悉的编辑器改（例如 vim ~/headscale/config/config.yaml），至少改这几处：
server_url: 改成你客户端要连的地址（推荐 HTTPS 域名）listen_addr: 容器里建议用 0.0.0.0:8080（否则只监听 127.0.0.1，端口映射进不去）dns.base_domain: 改成你的 MagicDNS 域名（注意示例里强调要和 server_url 域名不同）
dns.base_domain 不是 headscale 服务器的公网域名（那个是 server_url），它是给 MagicDNS 用的“内网后缀域名”：开启 MagicDNS 后，你 tailnet 里的每台设备都会有一个形如laptop.tailnet.example.com 这样的名字来互相访问。tailnet.<主域名>--accept-dns=true。database.sqlite.path: /var/lib/headscale/db.sqlite 保持即可（我们会把它映射到宿主机 ~/headscale/lib）。如果准备放到反代后面并让反代处理 TLS，也可以按文档把
tls_cert_path/tls_key_path置空并确保 WebSocket 正常转发。
1 | podman pull ghcr.io/juanfont/headscale:v0.27.1 |
说明：
:Z 是 Rocky/SELinux 环境常用的卷标处理（不加可能权限报错）。9090 是 metrics/debug 端口，我这里绑定到 127.0.0.1，避免公网暴露（容器文档也提到 8080/9090 的发布方式以及 0.0.0.0 vs 127.0.0.1 的差异）。看日志确认启动：
podman logs -f headscale
检查是否能跑起来
1 | podman ps |
对 rootless（普通用户）Podman 来说，podman pull 下来的镜像不会变成当前目录里的一个 .tar 文件，而是被写进 这个用户自己的本地镜像存储（image store） 里（按层存储、内容寻址）。
$HOME/.local/share/containers/storageXDG_RUNTIME_DIR（常见是 /run/user/$UID；你机器上看起来可能被设到 /tmp/cxing-runtime/...）podman info 里显示：
store.configFile: /home/cxing/.config/containers/storage.conf 说明实际路径可能被这个配置文件覆盖了。直接查看“它到底下到哪里了”（最准）
podman info --format 'GraphRoot={{.Store.GraphRoot}}'
podman info --format 'RunRoot={{.Store.RunRoot}}'
想看镜像占了多少、有哪些
1 | podman images |
Podman 的 -p 参数用于端口映射，语法格式如下：
1 | podman run -p [主机IP:][主机端口:][容器端口] [容器名] |
示例：将容器80端口映射到主机8080端口，只允许本机访问
当指定了IP地址后，意味着，特定了网络接口。
1 | podman run -p 127.0.0.1:8080:80 nginx |
范围映射：
1 | podman run -p 2000-2005:1000-1005 镜像 |
创建用户：
1 | podman exec -it headscale headscale users create cxing |
生成preauth key：
1 | podman exec -it headscale headscale preauthkeys create --user [ID] --reusable --expiration 24h |
然后在客户端执行：
1 | tailscale up --login-server http://你的headscale域名 --authkey 填上面生成的key |
用 Quadlet 做开机自启（rootless）
Podman 的 Quadlet 支持把 .container 文件放到 ~/.config/containers/systemd/ （用户级）并由 systemd 生成 service 来管理。
创建文件：
1 | mkdir -p ~/.config/containers/systemd |
填入（按需改版本/端口/路径）
1 | [Container] |
加载并启动：
1 | systemctl --user daemon-reload |
反代 / 443 / Cloudflare 的关键提醒
在 macOS 上装 Tailscale，最稳的是装 官方 Standalone 版本（推荐），其次是 App Store 版本。官方要求 macOS 12.0 (Monterey) 或更高。
.pkg）。备注：Standalone 版本会用到系统扩展；App Store 版本则不需要系统扩展、只装 VPN 配置。
安装 GUI 版（cask）：
brew install --cask tailscale-app
open -a Tailscale
打开 Tailscale 应用 → Settings → CLI integration → Show me how → Install Now，输入 mac 管理员密码。装完后会有：
/usr/local/bin/tailscale测试：
1 | tailscale status |
1 | tailscale up --login-server <headscaleAddress> --authkey <yourpreauthkey> |
先确认客户端可以访问到headscale这个端口（默认8080或者自定义的8111）
1 | nc -vz DomainName port |
如果超时，说明是port端口没对公网开放，或者是服务器防火墙没配，或者是反代没配
先在服务器上确认：Headscale 的 8112 现在到底通不通
在服务器上直接跑（强制不走代理）：
1 | curl --noproxy '*' -sv http://127.0.0.1:8112/health | head |
1 | [cxing@turing001 ~]$ curl --noproxy '*' -sv https://127.0.0.1:8112 |
8112 是 HTTPS 自签名，服务器不信任证书
把 headscale 的证书加到系统信任（Rocky 9）：
1 | openssl s_client -connect qiyan.fund:8112 -servername qiyan.fund -showcerts </dev/null 2>/dev/null \ |
公司有5个同事
1 | podman exec -it headscale headscale users create alice |
users list 里会显示 ID，后面生成 preauth key 常用这个 ID（官方示例就是 --user <id>）。
示例（给 alice，假设 alice 的 user ID 是 1）：
1 | podman exec -it headscale headscale preauthkeys create --user 1 --expiration 24h --reusable |
--reusable 是指 允许在有效期内多次添加设备。
把 key 发给 user，让他在自己的设备上执行：
1 | tailscale up --login-server=http://qiyan.fund:8112 --auth-key=xxx --hostname=... |
1、都需要登陆服务器，起码要访问到自己的home目录下做开发。其中有一个hnie是root用户。cxing是普通用户，但是要管理tailscale。
2、不需要互相访问彼此电脑。
hnie、cxing、u1、u2、u3（按真实用户名来）tag:servertag:server:22（SSH）hnie、cxing）可以访问服务器更多端口（可选）alice 的 home 默认权限就是 700/750（建议统一 chmod 700 /home/<user>），同事无法读写彼此目录在宿主机（你挂载的 config 目录）创建一个 acl.hujson，比如放在：
$HOME/headscale/config/acl.hujson
内容示例（把用户名替换成实际的）：
1 | { |
然后在 headscale 的 config.yaml 里启用这个 ACL 文件：
policy / acl 字段指向文件路径config.yaml 里搜 policy 或 acl，把路径指到容器内路径：/etc/headscale/acl.hujson$HOME/headscale/config 挂载到容器 /etc/headscale 了，所以容器内就是 /etc/headscale/acl.hujson改完后重启 headscale 容器：
podman restart headscale
1 | curl -fsSL https://tailscale.com/install.sh | sh |
结果：以后 cxing 作为普通用户就能跑 tailscale up / status / down 等管理命令（不需要 root）。
先在 headscale 里找 cxing 或 hnie 的 user ID（假设管理员 user ID 是 1），生成一个 给服务器用 的 key：
1 | podman exec -it headscale headscale preauthkeys create --user 1 --expiration 1h |
然后在服务器上（由cxing来执行也可以）把服务器节点注册进去，并打tag：
1 | tailscale up \ |
用于管理员日常加人/删机/看节点/改路由，省的再podman exec进容器。
在服务器上创建API key
1 | podman exec -it headscale headscale apikeys create --expiration 90d |
管理员电脑终端下载同版本headscale二进制版本。如果是macOS，则下载darwin后缀的。
配置Remote CLI 连接参数
可以通过ymal 文件配置Remote CLI连接参数：
Headscale CLI 会按照顺序找config.yaml：/etc/headscale → $HOME/.headscale → 当前目录；也可以用 -c/--config 或 HEADSCALE_CONFIG 指定路径。
推荐放这里：
1 | mkdir -p ~/.headscale |
写入：
域名:端口 即可1 | cli: |
Remote CLI 要求 gRPC 启用 + 走 TLS（加密连接），默认 gRPC 端口是 50443。
现在 login-server 用的是 http://...:...，这通常意味着还没把 headscale 的 gRPC/TLS 管理口准备好。建议把 gRPC 管理口 只开放在 tailnet 内（最安全）：要么只监听 127.0.0.1 再用 SSH 隧道访问，要么只允许 Tailscale 网段访问。
在服务器生成自签证书（放到挂载的 config 目录）
在服务器（turing001）上执行：
1 | mkdir -p ~/headscale/config/certs |
改 Headscale 的 config.yaml ：打开 gRPC + 指向证书
在 Headscale 的配置文件里加/修改这几项：（这里面的路径指的是容器里的路径，这些文件映射的是挂载的目录~/headscale/config）
1 | grpc_listen_addr: 0.0.0.0:50443 |
注意：Remote CLI 需要“有效证书”。没有受信任证书时，要么把自签证书加入系统信任，要么在 CLI 里
insecure。
最后一步，需要在headscale的podman run里加一条端口映射（示例）
1 | -p 0.0.0.0:50443:50443 |
如果现在的 headscale 容器是跑着的，通常做法是：
1 | podman stop headscale |
然后用带 50443 映射的命令重建（数据都在 volume 里不会丢）
1 | podman run -d --name headscale \ |
确认端口监听：
1 | ss -ltn | egrep '(:8112|:50443)' |
如果服务器有防火墙/安全组，也要放行 TCP 50443，或至少放行给你的办公网段。
测试：
1 | headscale nodes list |
如果超时，则测试50443端口是否可达
1 | nc -vz DomainName 50443 |
nc 超时，而服务器上确实在监听，那就几乎肯定是 防火墙/云安全组sudo firewall-cmd --add-port=50443/tcp --permanent && sudo firewall-cmd --reload在服务器上确认：headscale 是否真的在监听 50443 + podman 是否映射出来。在服务器（turing001）上跑：
1 | podman port headscale | egrep '50443|8112' |
应该能看到类似：
0.0.0.0:50443 -> 50443/tcp（podman port）LISTEN ... :50443（ss）如果 看不到 50443，那 Remote CLI 永远连不上。
确认 Headscale 配置中 启用了 gRPC + TLS（headscale 的 config.yaml）：
1 | grpc_listen_addr: 0.0.0.0:50443 |
Remote CLI 走的是 gRPC over TLS，不是你现在的 HTTP
8112。只有 HTTP 的话，Remote CLI 连接一定会超时。
上面的Remote CLI只是省去了SSH + 进容器的步骤，但是仍然不够直观。
社区有很多 Headscale 的Web UI 项目。
以 Headplane 为例。
在服务器（cxing目录下）
1 | mkdir -p ~/headplane/{data,config} |
生成Headplane 的 cookie_secret（必须32字符）
1 | COOKIE_SECRET="$(openssl rand -base64 48 | tr -d '\n' | head -c 32)" |
写 Headscale 配置文件
1 | cat > ~/headplane/config/config.yaml <<'YAML' |
然后把 cookie_secret 替换进去：
sed -i "s/__REPLACE_ME__/${COOKIE_SECRET}/" ~/headplane/config/config.yaml
用Podman 跑 Headplane
先检查服务器的 3000 是否占用：
1 | ss -lnt | grep ':3000' || true |
启动容器（暂时只绑定到本机，避免直接暴露公网）：
1 | podman run -d --replace --name headplane \ |
看日志确认起来了：
1 | podman logs -f headplane |
客户端：
从 管理员客户端 访问 UI （SSH隧道）
1 | ssh -N -L 9300:127.0.0.1:3000 cxing@turing001 |
浏览器打开：http://127.0.0.1:9300/admin
登录时需要 Headscale API key（不是 preauth key）。Headplane 文档明确：登录要提供 Headscale API key。
服务器上生成 API key：
podman exec -it headscale headscale apikeys create --expiration 90d
Headplane 配置校验是“强制要求 integration.agent 里必须提供 pre_authkey 或 pre_authkey_path”，哪怕把 enabled: false 也照样会报错（它会把 agent 的默认字段补齐后再校验）。所以容器启动就直接退出了。
解决方法：
给 integration.agent 补一个 pre_authkey_path（放一个 key 文件），即使 agent 不启用也能通过校验，从而 UI 正常启动。
在 headscale 里生成一个 preauth key（给“占位用”）
用已有的 cxing 用户（ID为1）
1 | podman exec -it headscale headscale preauthkeys create \ |
这个 key 本质是“给 agent 或其他节点自动注册用”的。你现在 agent 不启用，它不会自动跑，但 Headplane 校验必须要有一个。
把 key 写到 文件，同时权限收紧
1 | mkdir -p ~/headplane/keys |
修改~/headplane/config/config.yaml
把 integration 段改成下面这样（关键是补 pre_authkey_path）：
1 | server: |
重建 Headplane 容器（把key 文件挂进容器）
1 | podman rm -f headplane 2>/dev/null || true |
检查是否跑起来：
1 | podman ps --filter name=headplane |
在浏览器前端页面提交apikey报错为：
1 | 2025-12-22T10:25:49.378Z [server] INFO: Running Node.js 22.20.0 |
这个报错的意思很明确：Headplane 在用 HTTPS 去请求 Headscale 的 HTTP API 时，遇到了“自签名证书”，Node.js 默认不信任，于是把 API key 校验直接判失败。
Headplane 本身就支持这种场景：如果 Headscale 用了 TLS 且不是 Let’s Encrypt，需要在 Headplane 配置里给 headscale.tls_cert_path。
在服务器上跑（重点是分别试 http/https）：
1 | curl -vk https://127.0.0.1:8112/ |
http://...，不要走 TLS。如果 Headscale 的 8112 是 HTTPS（自签名）——让 Headplane 信任证书
导出 Headscale 的证书到文件（在服务器上）
之前
openssl s_client看到CN=qiyan.fund，所以这里用-servername qiyan.fund。
1 | mkdir -p $HOME/headplane/certs |
修改 Headplane 配置（关键是2点：url 用 https + tls_cert_path）
$HOME/headplane/config/config.yaml 里把 headscale 段改成这样（注意 url 用域名，不要用 IP，否则下一步可能会踩“证书域名不匹配”）：
1 | headscale: |
tls_cert_path只有在url是https://时才生效。
重启 headplane 容器，并把证书 mount 进去
1 | podman rm -f headplane 2>/dev/null || true |
这里加了 --add-host qiyan.fund:192.168.2.151：
qiyan.fund然后再进 Web UI 提交 API key，就不该再报 self-signed certificate 了。
那就把 Headscale 的 HTTP API 确保是纯 HTTP（Headscale 配置里别启用 tls 相关），并在 Headplane 用：
1 | headscale: |
这种情况下 不要配 tls_cert_path（配了也没用）。
1 | [cxing@turing001 headplane]$ podman logs -f headplane |
证书校验通过了“自签名”这一关，但失败在“域名不匹配”。
错误信息非常明确：
IP: 192.168.2.151 is not in the cert's list
也就是说：headplane 现在去连的是 https://192.168.2.151:8112（IP），但证书的 SAN（Subject Alternative Name）里没有这个 IP。证书大概率只包含 qiyan.fund（或者其它域名），所以必须 用域名访问，不能用 IP 走 HTTPS。
解决方法：
Headplane 用域名 + 容器内把域名解析到内网 IP（走内网又不破坏证书）
把 headplane 配置里的 headscale.url 改成域名（不要用 192.168.2.151）
1 | headscale: |
启动headplane 时加 --add-host 强制容器内把域名指向内网 IP
在用证书挂载的基础上，重跑（注意：--add-host 要放在镜像名前）：
1 | podman rm -f headplane 2>/dev/null || true |
这样做的效果是：
qiyan.fund ✅（匹配 SAN）然后再提交 API key，就应该不再报 SAN mismatch。
如果现在的 headscale 容器是跑着的，通常做法是：
1 | podman stop headscale |
然后用带 50443 映射的命令重建（数据都在 volume 里不会丢）
1 | podman run -d --name headscale \ |
podman logs -f headscale
1 | curl --noproxy '*' -sv http://qiyan.fund:8112/health | head |
1 | podman port headscale | egrep '50443|8112' |
以下是通过SSH隧道转发对端8112端口到本机8112端口
1 | ssh -N -L 8112:127.0.0.1:8112 cxing@turing001 |
headplane客户端：
从 管理员客户端 访问 UI （SSH隧道）
1 | ssh -N -L 9300:127.0.0.1:3000 cxing@turing001 |