ysmox

买 HK 节点的轻量服务器吧，30Mbps

@crownor 组网设备的拥塞控制算法是不是 cubic ？如果是的话，改下 bbr 试试

@cndenis

你的业务场景其实不复杂，当前企业内部使用的系统通常都有身份认证这套系统，即“访问前登录”。但由于各种原因，内部开发的业务系统以及购买、订阅的第三方系统均无法证明足够安全。

业界通常如何解决这种问题呢？这里我讲一下我所知道的一种解决方案，即在业务系统前套一层「零信任」的网关。

先讲一下用户登录访问的流程，这里以本地用户（业务系统本身创建的用户）和 IAM 身份源举例：

- 本地用户：访问 Web->未登录重定向业务系统登录页面->登录成功进入 Web 应用。
- IAM 身份源：1. 访问 Web->2. 未登录重定向业务系统登录页面->3. 重定向至 IAM 登录页->4. 登录成功重定向到业务登录页面->5. 进入 Web 应用

注：如果不清楚 IAM 是什么的话，你可以将上面的第 3 步的 IAM 登录页理解为“微信扫码登录”、“钉钉扫码登录”、“google 登录”、“github 登录”等登录方式。

这种情况下，发布在公网的业务系统在登录前是可以被爆破的，无法确保哪些 API 不会存在漏洞。

「零信任」是怎么做的呢，简单来讲就是在业务系统前加了个「零信任网关」，用户访问业务系统均由「零信任网关」代理访问业务系统。如果你熟悉 nginx ，可以将「零信任网关」想象为一个具有身份鉴权能力的增强版 nginx 。

任何访问业务系统请求的流量，均会经过「零信任网关」，未登录的流量均会被拦截。只要当用户在「零信任」上线后，被“授权”的用户才能顺利地经过「零信任网关」访问到业务系统。这是一种关键的安全机制，它在网关层面拦截所有不可信的访问请求。

使用「零信任」后的用户访问流程：1. 访问 Web -> 2. 「零信任网关」判断请求无“身份”信息重定向至「零信任」的登录页面 -> 3. 「零信任」登录后放通请求，重定向至业务系统登录页面 -> 4. 业务系统登录成功进入 Web 。

一般人看到这里会觉得第 3 步和第 4 步都要登录，用户用起来很麻烦需要登录两次，但绝大部分情况下只需要登录一次，怎么做到的呢？这里我讲两种常用的方案：

1. 上面提到过的 IAM 身份源，如果「零信任」和业务系统的身份源都是同一个 IAM 系统，那么登录一次后，当用户访问其他业务系统时，会重定向跳转至 IAM 页面，此时会自动完成登录再回到登录后的业务系统页面。例如：我们访问 A 服务用的是 google 的身份，第一次需要登录 google 账号，后面访问 B 服务、C 服务等，若业务系统本身默认使用 google 账号登录，那么访问时便自动完成这个登录动作。

2. 对业务系统进行简单改造，用「零信任」的身份登录系统。什么意思呢？当第 3 步完成后，用户已经成功上线「零信任」系统了，此时用户访问业务系统，业务系统本身并不知道当前用户是谁，但业务系统可以去请求「零信任」拿到身份信息，完成用户上线。

以上两种方案本质上其实是同一种，对于用户而言它只需要登陆一次即可，当然厂家提供的登录方式不止于此。

「零信任」是个理念，上述是「零信任」的一种实现、一种解决方案。

至于你问的有没有成熟好用的产品推荐，并且满足体制内的安全要求（例如等保、信创）。在网络安全厂商里是可以找到相应的「零信任」解决方案的，尤其是国内头部的网络安全厂商如“深信服”、“奇安信”，又或者其他互联网大厂，你可以直接联系他们了解更多。

其实前面有不少朋友都提到了“零信任”甚至“oauth2-proxy”，但只是提及个名词就作罢，实质上核心都是“访问控制”。

传统的 VPN 打通了局域网与内网，但如果 ACL （访问控制列表）没做好，一旦工作人员的设备被侵入，公司内网将面临危机，对于入侵者而言就是一览无余。

「零信任」的核心理念就是八个字：“永不信任、持续验证”。在业界，厂商的简单实现通常就是做好“访问控制”。

站在应用角度，主要分为以下两种应用场景：

- Web 代理应用：“编辑想在公司外访问内容管理平台”，如果「内容管理平台」是一个 Web 应用，那么只需在 Web 应用前面的网关加上“认证”机制。当公网上访问 URL 时，未登录用户无访问权限，将被重定向到登录页面；登录后才能访问「内容管理平台」。这解决了「零信任」中的一种场景。

- 隧道应用：这种场景是将应用隐藏在公司防火墙后面，不对外暴露服务。通常的解决方式是安装厂商提供的客户端（适用于 Windows 、Mac 、Linux 、Android 、iOS ），用户登录后，设备只会和“被授权”的内网应用建立隧道连接。这样，只有授权的人才能知道内网应用的存在并访问到。因为这需要建立隧道才能访问，没有登录的人自然无法发现「内容管理平台」，即使登录了没有权限也是一样，这也是「零信任」能解决的另一种场景。

综上所述，对于暴露在公网的 Web 应用，我们应只允许“授权用户”访问，并通过网关为当前会话连接赋予“身份”；对于不想暴露在公网的应用，就像传统 VPN 一样，使用隧道技术，只允许与“授权应用”建立连接，当然要比传统的 VPN 做得更好。

类似 oauth2-proxy 、authelia 这样的开源组件，都是不错的解决方案，但不一定能提供最佳体验。例如，如果有一个 docs 应用隐藏在 authelia 的网关之后，未登录的用户会被重定向到 authelia 的登录页面，但由于 authelia 目前仅支持账号密码、LDAP 方式登录，并不支持主流的 OAuth2.0 、OIDC ，因此在公司层面可能难以推广，这毕竟只是一个开源项目。

当然还有很多其他方面值得注意，但先就这样吧。

```bash
root@pve:~# lscpu | grep 'Model name' | head -n 1
Model name: AMD Ryzen 7 7840H w/ Radeon 780M Graphics
root@pve:~# hostnamectl
Static hostname: pve
Icon name: computer-desktop
Chassis: desktop 🖥️
Machine ID: e620797c076246c7b272dc75ae9f7xxx
Boot ID: 78782e567beb448a8e611af600d63xxx
Operating System: Debian GNU/Linux 12 (bookworm)
Kernel: Linux 6.2.16-3-pve
Architecture: x86-64
Hardware Vendor: Machenike
Hardware Model: Machenike DT Computer
Firmware Version: 101
root@pve:~# uptime
01:55:42 up 27 days, 16:02, 2 users, load average: 0.08, 0.16, 0.17
root@pve:~# date -R
Mon, 06 Nov 2023 01:55:47 +0800
```

不用新特性的话，没必要用那么新的内核

可以

arXiv 平台的存在就是解决 idea 和数据被剽窃的问题。

arXiv 是由康奈尔大学运营维护的一个非盈利的数据库，由于免费，学术研究人员可以在其他顶会或者期刊没有录用之前，将自己最新的研究成果发布到该平台上，一方面是为了扩大宣传提升自己的影响力；另外一方面是为了保护自己的科研成果，因为无论会议和期刊从投出到最终可以检索，都需要长时间的等待，很难保证期间自己成果不被别人剽窃，arXiv 可以证明论文的原创性。——来源：某乎

@yiXu 我本人！