你这种情况更合适魔改 DHCP 达到此目的。配置路由端 DHCP 服务，检测到特定 MAC 地址就推送特定 IP 网关和 DNS 。也可以配置不同的 SSID 为不同的 VLAN ，就可以在同一个 MAC 地址下通过不同的 SSID 推送不同的配置。

以前我记得 Windows 端有一些网络 profile 的应用，可以根据预设切换网卡的配置。

@nothing2 除非他们修坏了你的机器
换电池前如果 ast 没跑出问题，换完以后翻车大概率会给你再修好

Reverse proxy 就是做这个的吧，nginx 可以。当然流量会绕路，proxy 会转发所有流量。
要么就做 301/302 ，一个网页的事儿。但 ws 能不能 300 就不知道了。

你说的应该就是上面两条不允许的情况吧。DNS 本身做不到这些。有些 DNS 服务商可以帮你 host 一个特别简单的页面或者做 redirect ，就是上面第二条，省下你一个服务器的钱。

如果你只是为特殊应用提供服务，可以用 DNS 的 TXT 记录数值，然后在应用里提取这个记录所包含的地址和端口号，然后在建立 HTTP 或 WS 连接。

是不是可以等 FLTTH 的 8K 录像？

Mac 支持这个，Windows 默认不行的

https://superuser.com/questions/965385/assigning-a-virtual-desktop-to-a-monitor-in-windows-10

8x16T 有两个盘冗余可靠性方面是够用的，10 个盘用 2 个冗余都是够的。再多就冗余三个盘吧。

四个盘太尴尬了，RZ1 还可以，能避免一些 R5 的缺陷，4TB 也不算太大。但为了更好的可靠性 mirror+stripe 是很主流的选择（ RAID10 ）。

提醒通知也是可以远程 trigger 后台活动的，忘了这种是否会被后台 app 开关屏蔽掉，可以尝试把此应用的通知完全杀掉然后看看是否改善。

商业化的没见过，3D 打印的还是有的，比如 https://www.thingiverse.com/thing:3219354

@hwdef 本来还想推荐他家的 USB150 棒子呢，既然 MT300v2 无法满足你，那个棒子估计也不太行。

不过 USB150 确实是个很有趣，定位很准的产品

@zhailw f2b 正解 此类根据某种特征识别主机并 ban 掉的操作都是 f2b 能搞定的范畴

如果你说的爬虫指的是爬 SSH 弱密码、爬 SMTP 中继的那类，规则可以设置的严格一些，我这边都是直接 ban 终身的

有的时候并不需要在源头上 ban 一个 IP 。资源够的话可以先从应用层面 ban ，然后升级至防火墙 ban 端口，最后彻底 ban ，可以有效减少误杀的可能。

18 年底收的二手 DS1812+，上的还全都是 8TB 的 SMR🤪 都是希捷的，一半是 Archive ，一半是 Barracuda ，从大概 20 年开始就 24/7 了到现在一个坏块都没有，都照样跑的杠杠的。有定期 mdadm+btrfs scrub 的习惯。

SMR 大流量下 IO 阻塞的问题确实存在，但一年到头都遇到不了几次。之前也有重建过 raid ，最久确实是需要跑两三周，挺吓人的。但真正用起来也就那个样子。

补充一点，如果使用了应用的 secret 那么这个 secret 丢失的话数据库里的数据可能就无法解密了（但可以备份这个 secret ）。这种 secret 用来加密 volatile 数据更合适（比如 session key 之类需要加密但丢了也无妨的数据）

或者你可以为对应的数据加 salt ，甚至系统中设置多个 salt ，基本上就能做到楼上上说的必须泄漏三者才会出问题：
- 主密钥（ env ）
- 应用配置 secret 或 salt （ code ）
- 主密钥、应用的 salt 和记录 /用户的 salt 参与数据库中数据加密（ db ）

对称加密可能还会用到 IV 和 nonce ，但 nonce 一般不需要记录（也不应该被复用），IV 保存在密文的开头或结尾是基本操作，在这个问题中不适用。

@julyclyde YubiOTP 不像 U2F ，是需要目录服务器支持的。如果 app 选择使用 YubiOTP ，他们就可以配置服务为仅信任 cc 开头的密钥，即便 Yubico 的服务器上 cc 和 vv 开头的密钥都有提供。

YubiOTP 生成的时候需要在服务端保存一个不公开的密钥。cc 密钥在设备生产的时候就已经生成了，可以理解为密钥没有在公网公开过，信任度更高。vv 密钥生成后需要通过网络传到 Yubico 的服务器，这个过程有可能被破解窃听，所以信任度不如 cc 密钥。

这些对 U2F 和 FIDO2 没有影响，两者是完全不同的技术

@billgong 更正：YubiOTP 原厂 key 是 cc 开头；
自己生成的 key ，需要公开注册的 key 是 vv 开头，其他前缀只能作为私有用途。

U2F 模式仅支持 MFA ，不需要用户端校验，所以每个 app 都生成新的密钥对
https://developers.yubico.com/U2F/Protocol_details/Key_generation.html
然后 yubikey 里再用设备自己的主密钥处理生成的密钥私钥，整个过程 yubikey 不存储任何新创建的信息

新的 FIDO2 支持 resident key 模式，这样就能允许设备存储某一 app 的私钥，实现（更高一级的） passwordless 。

不支持 FIDO2 的 Yubikey （四代及以前）主密钥永远不变。支持 FIDO2 的 Yubikey （五代及以后）重置 pin 会重设主密钥。

FIDO2 模式密钥你看不到的，只有 pin 可以设置（必须设置一个 pin ）抹掉 pin 的话私钥应该也就重置了吧

YubiOTP 的话出厂默认带一个 key 在 slot1 ，默认是锁定的状态，千万不要删掉（自己再生成的 cc key 有 trust 的问题）

大部分功能可以用 yubikey manager 管理，但更高阶的功能需要用 personalization tool ，只是那个工具现在已经 EOL 了