@whitegerry

这个办法也不是没有想过，但是既然始终都要在 nas 上额外做些什么了，不如直接再写个服务丢到 nas 上去，专门用来做这个事情，然后服务本身跑在一个低权限的 local 账户上确保安全。

这里姑且叫它“开门人”服务，这个服务本身收到消息后用私钥解出消息，拿到 ip 和有效时间，开通白名单后自己再管理这个 ip 的白名单过期时间，到期后 iptable -D 移除记录。

这样依赖 proxy-knocker 可以移除对 ssh 的依赖，更轻量化；而且还顺手解决了当前版本没有管理和移除过期白名单记录的问题。

@myqoo

其实 30x 方案也不是完美的，主要一点就是 http 协议的 redirect 如果重定向出现跨域，那么 header 中的 Authorization/WWW-Authenticate/Cookie 是不会跟随重定向的。

所以今儿早上我手机客户端 Seafile 测试的时候，https api 拉取一直失败，随后 debug 发现 seafile 的 web api 要求在 header 中使用 Authorization 发送 token 做身份验证。

当然，机智如我，在 proxy-knocker 中增加了检查，如果有上述 header，那么将其转换为 GET 参数拼接到 请求的 uri 中，然后在真实服务器（ nas ）那边套了一层 nginx，判断如果 GET 中有这些特殊参数，那么将其转换为 header，并且用 proxy_set_header 专递给 proxy_pass 后端服务器。

最后问题解决了，手机客户端正常使用中。

回头再优化一些其他问题吧，譬如 ssh 连 nas 开 iptables，我觉得不安全；还有每次请求仍然会走一次 vps 做 redirect，性能上感觉有点不完美。

@myqoo 来自手机客户端的 API 接口请求怎么用 iframe ？注意审题……

：）

@noahzh 超大流量的问题，我在主题的“缺点”第 3 条中已经提到了，我自己的应用场景没有那么大的持续流量。：）

@myqoo 打哑谜可就没意思咯。

@whitegerry

理论上是可以的，如果只有 ipv6 的话，需要注意的地方有 2 个：

1 、REDIRECT_URL = 'https://nas.yourdomain.com:1443'
重定向目标的域名你要自己解析到 nas 的 ipv6 地址上。

2 、SSH_ADDR = '127.0.0.1'
NAS 的 SSH 地址这里，你填写 nas 的 ipv6 地址试试看？ paramiko 的手册上 connect 方法我没有看到明确说是否支持 ipv6，只能你试试看了。


其他就没什么了。

@baozhuo

小星星拿来吧，哈哈，详见 APPEND 。

@baozhuo 预计今天会出个第一版吧。会比较粗糙，但是主要功能可用这样。

@milkme

首先，我并不考虑你假设的这种情况，然后就是即便同城市，同 ISP，同在一个广域网，2 个 IP 也是无法访问的，有 IP 隔离存在。

@talarax7

1 、端口映射这个操作本身没有难度，主要是我不希望开放太多空白端口，哪怕这些端口本身没有任何卵用。

2 、境内波动是小，但是境内的 vps 一来价格贵，二来需要备案才能用域名；所以我这个方案中提到的 vps 一般都指国外那种非常非常廉价的 vps，而境外 vps 的话波动就难说了。 再有一个哪怕 vps 是境内的，但是既然 nas 要提供服务了，如果有多个人在线拉视频流的话，网关上出现丢包也在所难免，毕竟端口敲门这个方案没有什么可用性保障设计，丢包就是丢了。（ ps：我测试 port knocking 的时候发现，如果丢包导致顺序出错，重发的时候第一个包会被上一个未完成的队列用来进行 check，然后抛出 error，也就是说短时间内的重试时第一个敲门包会无效化）

3 、js 这个方案也是我正在做的这个东西的最初想法，但是我思考之后决定放弃，一来纯 js 编写的话，端口敲门顺序是暴露的，我正在做的这个东西希望能支持一些简单的认证后再进行敲门和 302 。所以目前是 python 在写，提供一个 web server 监听，允许配置简单的认证（ get/post 参数，或 header 头字段，或 basic auth ），认证通过后再通知 nas 开放白名单，并且还会验证是否开放成功，最后才 302 到 nas 上。

总的来说，我目前这个方案各个环节我本地已经跑通，就等慢慢撸代码然后开源发布了。

@lifanxi

你是怎么测试的？

我这里 Seafile 的 /api/auth 认证登录接口也是 POST 的，但是可以跟随 302 跳转。

我是先做了一个地址 A，然后 302 到新的地址 B，用客户端时填写 A 地址，然后发起请求，最后地址 B 上也有 access log 。

@andynet 如果我没看错的话，你这个方案和 FRP 大同小异，最终流量都是走的 VPS 。

我的方案如果部署完毕的话，VPS 只是相当于初期的一个“可信介绍人”，完成“介绍”（即白名单开启）动作后 VPS 不参与后续的事情。

@jiangyang123 是的，又一个看懂我意思的。：）

理论上我这个方法可以让任意访问者无感直连 nas，且第三方即便抓包知道了 nas 的 ip 、port 、domian 。也无法在第三方客户端复现访问。

@leafleave
@hymzhek

提到端口敲门的，我统一回复一下吧，经测试，port knocking 有一些局限性：

1 、需要在目标机器开多个端口，如果我程序跑在 nas 上的话，需要在网关路由器做多次端口映射。

2 、经测试，端口敲门逐一连接端口时，如果由于网络波动导致丢包的话，端口敲门失败率非常高。（中间有一个包没收到，顺序就会出错，导致敲门失败）

3 、端口敲门程序，成功敲门后白名单开放的是敲门人的 IP 地址（即我文中的 vps 地址），而我希望是另一个由 vps 指定的 ip 地址，即真正访问者的 IP 地址。

再说一次，我的目的不是单纯为了让我自己访问，而是让其他任意人都能便捷访问。

@lifanxi 等了 30 楼了，可算有一个看明白我的诉求和想法的了。

我刚刚测试过了，Seafile 客户端在进行 https 登录认证的时候是支持 302 跳转跟随的。

@ghostwwg 非固定设备，其实我折腾这些主要是家里 nas 上现在在循环录制宝宝的监控视频，然后我又希望我的家人父母可以异地通过手机、PC 等方式随时查看监控或者视频回放。

所以开篇就直接 pass 掉了 frp vpn $$ 等手段。

@brMu 程序我已经在写了。

至于抓到 https 通信就判定滥用的话，我觉得可能性不大吧，我先做个小白鼠试试看。

@BlackHole1 从 VPS 302 到 NAS 的时候，ISP 抓包都是在电信宽带侧抓包，所以抓到的包只是 Client to NAS 的包，那么这个 HTTPS 里面的 server_name 是具有白名单无法直接访问的。

@jiangyang123
@CheekiBreeki

注意审题。