一些新网络技术实测(下)

续前文:一些新网络技术实测(上)

安全的国内中转代理

众所周知的事实:墙只安在国境线上,国内网站另有一套更加严密的监管系统。由于每个网站每个域名都要实名备案,找到负责人很容易,因此不会大费周章去监控国内流量。

而之前的方案中,直连的方式是:

国外公网←nginx←websocket←国外网站
⬇
墙
⬇
国内公网→家庭宽带/4G→websocket→本地代理→浏览器

而这一方式中,本地设备穿墙到国外服务器这一条线路其实并不稳定,尤其是家用光猫和4G网。

而国内的正规机房到国外的线路则要好得多,如果加入一个国内中转,快速和稳定都可以保障。

但也有缺点:

最大的是安全性,毕竟这玩意在国外搞还管不到你,国内一切都是实名,一抓一个准;

其次是价格,国内服务器在带宽流量上报价从来不含糊,按G收钱,比起国外那种包月按T算的简直是两个星球;

然后还有方案问题,究竟是在原有的这方案上再套一层二级代理,还是拆开原先的nginx←websocket这一块,把nginx放到国内?

针对所有可能使用的技术,我做了一系列测试:

  • 国内nginx明文直连国外的websocket服务(×)

毫无悬念地失败了,甚至可以说是公开作死。

还好我用一台全新的临时主机,发送极小的流量后就被掐断,并中断连接几分钟。还好没有影响到国外的IP彻底被封,这么小的异常行为应该也不至于触发什么风控预警。但我还是告诫自己以后不要擅自做这种行为。要做也做得更隐秘些。

  • 国内nginx套二级代理(×)

换句话说就是双层https,等于代理一个远程的https网站,看起来倒是挺适合,但我在实际测试中总是失败,而且失败得很莫名其妙。

当初次失败后,我改用这种双层代理试验了访问静态网页,成功。

用一个自建的websocket聊天室,成功,可以在国内外两个域名上互相发送信息。

但唯独代理websocket失败,可能因为它毕竟不是真正的websocket吧。总之反复测试失败后这个方案只好放弃。

  • wireguard点对点VPN(×)

使用wireguard也是灵光一现,虽然warp方案中我不用它,但可以用它来把国内外两台服务器连接起来。

配置很简单,生成两对密钥,两边各写一个配置文件就行。

结果,第一次连接成功了,第二次之后就再也没成过。

果然,网上一查,很多人提过wireguard的安全性没问题但数据特征极其明显,早就是墙的重点盯防对象了。我之前一直用ss而不是vpn,所以没关注过。

看到有人曾经给官方提议除了加密还可以加入混淆,但被拒绝了。看来这种“不仅要保密还不能让你看出我在保密”的需求确实不是哪个国家都有。

  • wireguard+phantun(×)

phantun是RUST写的一个UDP over TCP加密工具,走UDP的wireguard正适合用它来包装一层。

但加入phantun之后配置文件变得相当复杂,要额外添加一个虚拟网卡,要在iptables里添加DNAT规则在多个网卡间转发。最过分的是,起初我在两台服务器间都配置成功过,但从某个时候开始却无论如何也连不上了,而且和墙无关,在两台国外服务器间仍然无法连接。

我在iptables和网络这方面的知识实在薄弱,只能从表层检查一下,比如路由和监听端口,而没法更细致地抓包查找里面的具体错误在哪。反复失败后只好放弃了这个看起来很不错的方案。

  • wireguard+udp2raw(✔)

除了phantun之外,udp2raw也是个功能类似的工具,但配置起来简单得多。

有了前者的经验,udp2raw一次成功并且令人很安心地从未失败过,而且也没有出现网上一些教程所写的性能下降问题。

这两个工具都是国人编写的,看来只有需求才能催生出好的工具。

总之最后的结果是:在一台国内服务器上搭建了中转服务(仍然隐藏在网站里,而且是实际运行的网站),可以本地websocket直接连接。

对比一下效果:

第一张图是一台服务器用了cloudflare CDN入口和warp出口之后的效果。可能是选择了更近的线路,下载速度很快;

第二张图还是这台服务器,但经过了国内中转,也没有加warp。可能是这个原因导致下载速度没有优势,但ping和响应时间快了一倍不止,在中美线路中算是第一等的速度了。

看起来,在国内外两台服务器之间建立一条隐蔽的TCP加密连接,并在其中走ss流量这回事,是有其存在意义的。

我现在保持了三条常用线路。日常使用可以全流程Cloudflare,速度不错且保密;需要固定IP时用原生连接;需要快速响应时走国内中转,平时不用它,毕竟国内还要额外加一份流量费。

容器化

shadowsocks+v2ray-plugin+nginx这一套可以很容易装在容器里。之所以我在自己的服务器上没做,当然是服务器配置太差,不想再用docker占一大块容量。

但不代表其它地方不能做。

现在各家云服务,无论是AWS、Azure、阿里腾讯这种大而全的,还是一些主打轻巧快捷的小服务商,都在搞容器化和函数计算服务。而且为了争抢客户,几乎都提供一定量的免费体验。

这个免费服务能使用的资源不多,如果当作日常翻墙肯定不够用。但我灵机一动:如果免费免的不是开启服务的数量,而是消耗的资源数量,那我完全可以在不同地域多开几个,需要使用时再启用,平时它会根据使用情况自动伸缩,甚至完全关闭,没有任何费用。

有什么作用呢?可以模拟不同地区的IP。除了解锁那些仅限某些国家才能开启的网站服务、临时隐藏身份外,目前想到的应用就是在国内网站整活,比如炫富时可以挂阿联酋IP,哭穷时可以挂南非,聊足球时挂巴西……

总之,我尝试了将shadowsocks+v2ray-plugin+nginx三者塞进一个容器后,放到azure自己的镜像服务(也是终身免费,但容量较小),容器内部无需https,监听80端口即可。

容器服务自动分配了一个很长的域名,而且带https,正好能代替原本的nginx proxy。

其实我本想去掉容器中的nginx,但为了让它适用性强些就留下了,性能损失不大。

目前的结果是这样的:需要临时启用哪个国家的IP时,开启代理,用代理访问一个IP检测网站,靠这个请求激活容器,容器启动大概需要10秒左右,等网站加载出来,显示指定国家的IP,就可以使用了。而空闲几分钟后它就会自动关闭,容器的自动缩放机制可以设置,我设置的就是0~1,极简方案。

速度么,日本香港的节点快点,印度非洲的慢点,跟普通的VPS差不多。

顺便也试过腾讯和阿里的容器服务,都可以运行,但这仅仅是个测试,谁敢在那种地方常驻一个翻墙节点呢?据说已经无论你安不安所谓的云盾或安全加固,都躲不过扫描。就算人家不上报只是封你号也够严重了。

总结

其实算不上什么总结,只是近期一些个人的实验,既没有教程也没有指南。

特别是在墙逐步加高的情况下,想多尝试一些更灵活的方案。自己的技术栈也需要更新,毕竟之前的ss+v2ray+nginx tls这个方案已经用了近三年,在独立IP和谨慎行事的加持下暂时没有大问题,但隐患终究是在的,多几个备选总不至于和国外彻底失联。

日后我甚至可能把翻墙类的所有文章都迁移到别处,本博客虽然在国外,但也只保留尽可能安全的内容。

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注