关于远程那些事

25年8月份组装了一台台式机，265K+48G+RTX5080，用来跑一些 AI 相关的测试，同时也是继 NAS 之后，想了很久的一套计算中心，和 NAS 一样，大部分时间需要远程访问，经过这一个月的折腾体验，也基本稳定了，简单分享下过程。

工作日主要在深圳，节假日在惠州，所以目前网络和设备环境有

1：深圳移动宽带100M，公网IPv6，内网IPv4

2：惠州联通宽带100M，公网IPv6，公网IPv4

3：中兴F50+联通5G，公网IPv6，内网IPv4

4：移动端Macbook Pro、GPD win mini等

而这台台式机暂时放在深圳，两个米家插座分别控制显示器和主机，人在家使用则双开，远程使用则关闭显示器，以节省电力。主机的插座为常开状态，主要用来监控功率，以及防止开机卡失效的一个强制关机办法。

开机卡选择的用机箱内 9Pin USB2.0 插座供电，完全藏在机箱内，连接主板电源开关以及 LED 指示灯（相当于按了机箱电源）。在手机上用米家 App 很方便的开关机，还能区分是本地操作还是远程操作。米家的这些设备也用了很多年，稳定性很可靠。

软件方面主要有DDNS-GO、UU远程、Rustdesk、Tailscale、微软远程服务，均设置开机启动。优先使用微软远程桌面通过 IPv6 直连，当效果不理想时，切换到UU，或者自建节点的 Rustdesk。

因 IPv6 直连在跨运营商（跨城）可能会有严重限速，丢包。而自建节点的 Rustdesk 因为服务器有流量费，也不会优先考虑，但他的控制端可以无需管理员权限运行，dddd。UU目前体验算不错的，就是不知道以后会不会收费，大部分场景使用下来，都是基于UDP P2P连接，应该不会很耗服务器资源，就是在 MAC 系统下控制端不太能灵活缩放，导致字体有点小，虽然能改受控端的分辨率，但 Windows 那个缩放一旦跟着变了，很多程序要刷新，也够受的。

至于 DDNS-GO 用来配置域名解析到本机的 IPv6。Tailscale 则用来访问一些无需图像界面的服务，也能将两个地方的设备纳入一个局域网管理。当然也还有 WireGuard 用来连接 ECS，那就和本主题无关了。

近几年的主板默认都开启了 ErP Ready 会在关机时关闭大多数设备供电，包括USB、PCI-E，故需要在 BIOS 中关闭此功能，以及开启关机时候 USB 供电。通过插座功率监控可知，Enable 功耗 1w 不到，Disable 功耗 4w 左右。

如果你有更好方案，不妨留言讨论。

Windows 11中使用IPv6的一些问题

目前家宽均配置了公网 IPv6，且启用 SLAAC 和 DHCPv6，地址后缀可由用户设备自行分配。经测试观察在 Windows 11 默认设置中拿到前缀会随机一个“固定” IPv6 地址和一个临时 IPv6 地址，访问网站会优先使用临时 IPv6 以保证隐私性，通常此地址有效期较短。

在配置远程访问过程中，发现两个 IP 表现并不一致，确认无防火墙干扰情况下，固定的地址可以 Ping 入，可以收到 TCP  SYN，在 FIN_WAIT_1 超时断开，在客户端远程桌面中使用这个地址，连接会卡在“正在配置中”，服务器日志显示“TCP 套接字写入操作失败，出现错误 121”。临时 IPv6 地址则无此情况，通讯正常。对于部分下载软件，默认使用第一个固定地址，会有速度影响。

关闭临时 IPv6 地址，此时会从 DHCPv6 多拿一个地址，测试也是可以正常通讯，不需要则在路由器上关闭 DHCPv6。此时如果再关闭 Windows 的随机算法，启用基于 MAC 地址的 EUI-64 算法地址，则可以只有一个 IPv6 地址，且通讯正常。但此时再开启临时 IPv6 则又出现相同问题。在 Windows 10 上测试没有上述问题，IPv6 和临时 IPv6 都正常通讯，不清楚是否其他设置引起。

相关命令（Powershell 需管理员权限）

使用EUI-64，关闭随机生成

Set-NetIPv6Protocol -RandomizeIdentifiers Disabled

关闭临时地址

Set-NetIPv6Protocol -UseTemporaryAddresses Disabled

这样操作会牺牲隐私性，请了解。

新玩具：探险家P-1 Mark II

上一个 GPS Logger V990 于18年购买，使用5年之久，稳定性还是很可靠的，没有出现什么大问题，最近决定做一次升级，换成最新款的 P-1 Mark II，主要有以下几点的考虑。

miniUSB 充电接口实在过于老旧，得多带一根线，也有过几次出门忘了的尴尬。仅支持 4GB 的存储卡和 FAT-16 分区也成古董，格式化都麻烦。单星座接收，定位准确度还是差点意思，尤其是长时间静止，那四处漂移的轨迹够慢慢删了。

过去的几年里，探险家也陆续发布了更高端款 P-1 Mark II 和 P-10 Pro，也都增加对中国北斗定位的支持，后者更是拥有全星座接收能力，L1+L5 双频定位，将定位精度推到顶峰。然而考虑到价格和实际使用场景，最后选择了 P-1 Mark II 款，目前还没拿到外面实际使用。在楼顶简单试用了下，确实定位精度比之前好很多，绕2圈，拐角处，斜着走都清晰可见。

简单说下第一印象：

从P系列开始，支持了三防，电池容量增加，体积也有了明显的增加，相比之下V系列则苗条太多。背壳从金属壳换成塑料壳，略显廉价，整体设计“粗犷”了不少。几个指示灯亮度感觉有所提高，夜间有点太亮眼。提示音有所减少，取消插拔卡时滴滴声，取消定位成功后滴滴声。广受诟病的 miniUSB 换成了 microUSB，除充电外还能当 USB GPS Device 使用，都 2023 年了，就不能一步到位 Type-C？

存储卡支持了 FAT-32，最大 32GB，虽然本身记录的 CSV 体积并不大，一天下来也就几个 MB 左右，但我习惯转换成的 KML 也存在上面，长年累月也是不小的存储量。P 系列默认按年月建立文件夹，这个功能还是挺实用的，不然塞满根目录。和大多数三防产品一样，一个橡胶盖覆盖了SD卡插槽和充电口，每次取卡充电，得掰一掰，弯折耐久度有点担心。

作为一个小众产品能不断迭代升级，并且能做到性能极致，还是得先点个赞👍，如果能有个小屏幕显示状态，高度，速度就更完美了。

小程序与移动端图片上传那些事

2022年7月14日，深圳一场绝世晚霞突然出现，而随手拍的一张照片上传到相册，却发现了一些问题，于是回来继续研究，顺便对相册的文件上传做个踩坑总结。

图片上传在各种程序开发中是一个再常见不过的需求。PC端由于对文件管理比较专业和成熟，一个 <input file> 直接搞定，但在移动端，却变得复杂起来。主要来说：第一是格式增多，兼容性难保证，各厂家均有自己的转换思路。第二是出于隐私保护，索性抹去了 EXIF。即刻相簿在做这件事情的时候也是不断的摸索中前进，被坑过数次。

对于相册程序而言，我们需要的是“完整”的“原图”，这里有两层含义，第一是包含完整的 EXIF 信息，从而绘制出带相机型号以及拍摄参数的分享图，第二是未经格式转换和机内后期的原始图像，尽可能的保存原始数据，当然，这一点倒影响其次。

即刻相簿是一个以微信小程序为主的相册，自然首先用到的是微信官方提供的上传功能，即 wx.chooseImage() 和 wx.chooseMedia() 很不幸的是这两者均不能满足要求，均抹去了 EXIF，转换成了 JPG，视频经微信压缩，画质掉渣到不可接受。

后来采用内嵌 webview，通过 H5 页面来实现上传，这样 file 的选择权就完全交由手机系统来决定，随后的测试中发现，在 iOS 系统中，相机拍摄格式中选择了“高效”，即 HEIF 格式时，上传时依然会转换成 JPEG，并抹去 EXIF，但拍摄 ProRAW 格式在自动转换 JPEG 的时候又能保留 EXIF，拍摄格式选择“兼容性最佳”，同样也能保留 EXIF，真是迷之操作。

（iOS 似乎在自动转换的过程中存在 Bug，将方向6转换成1的过程中没有更改宽高像素，导致画面比例错误。在选择照片中选择大、中、小，会丢失方向，竖拍图直接横着显示。前者解决办法判断宽度是否小于高度，竖拍一般宽度小于高度，后者基本无解，估计没多少人会去选大小吧）

既然是 webview，也想过能否在前段通过 JavaScript 来预先获取 EXIF，于是使用了 exif-reader.js 来读取 EXIF，很不幸测试结果中和上述表现一致。很好理解，因为在选择文件那一刻，就已经转换一个临时的 JPEG，开发者侧是无法感知这一过程。

另外有趣的是，手机上将 HEIF 图片通过分享存储到“文件”中，再在上传页面选择“选取文件”找到刚才的文件，是可以上传原始的 HEIC 格式文件并且保留了完整的 EXIF。

综上所述，即刻相簿也提供了PC端上传方式，来避开这些“限制”，以上测试基于 iPhone 13 Pro 系统 iOS 15.5。看来迟早得上 native app。

密钥安全那些事

借着此次上海公安数据库疑似泄密事件，好好梳理下项目中是如何确保密钥安全。密钥大多指 Key-Value 键值对、公私钥、Token 等，从早期的代码中硬编码，到配置文件硬编码，再到各种的配置中心的诞生，例如：携程 Apollo 或者 HashiCorp Vault。不断的演变进化中，安全性与灵活性也极大的提高。

硬编码时代：密钥控制权将完全由开发者决定，一旦代码泄露则密钥也一并泄露，即便泄露不是源代码，而是编译后的 Class 文件，Jar、War 包等也是可以轻松反编译得到源码，所以是最不可靠的方案，实际项目中应绝对禁止，且应在 CI 流程中加入 Checkmarx SAST 检测告警，以避免疏忽大意而导致泄露。配置文件只可存放用于测试的配置，例如连接本地数据库的用户密码，在 CI 流程中进行动态替换，这样一来，密钥则可交由运维人员来管理，与开发者完全隔离。

微服务时代：随着配置项的增多，管理职权分离后，密钥如何存储，更新，授权，管理等一些列问题也孕育而生。携程 Apollo 则是一个较好的解决方案，目前也是国内项目大多数的选择。自身的稳定性，灵活性都还做的不错，有着不错的 Web UI，与 Spring Boot 集成也非常简单。

云原生时代：随着 Kubernetes 的加入，DevOps 发生了较大的变化，对容器而言，推荐使用 Secret 和 ConfigMap 来存放密钥和键值对。同时众多角色的加入，如何安全存放密钥、安全使用密钥以及更好的与基础平台整合，对密钥管理又提出了更高要求。HashiCorp Vault 则是不二之选，通过一套复杂的加密机制可以确保在公有云上能够安全的存储机密信息，且支持密钥轮转，在 CD 流程中拉取密钥挂载到容器中使用，对服务来说可以做到完全透明，缺点是无法实时更改。

当然除了密钥需要正确保管外，环境有效隔离才是最后一道屏障，面对层出不穷的数据泄密事件，无论是有意还是无意，黑客行为，或许应该思考本身是否有必要收集和存储？去中心化的互联网架构或许是未来的出路？

docs：

https://www.vaultproject.io/docs/what-is-vault