0%

Switch联机加速研究

Switch联机加速研究

接上一篇,研究了switch设置中的代理设置和如何自己实现一个简陋的Switch全局代理

Switch代理情况及解决方案

之前和大姐联机的时候wireshark抓到的包和其在switch上连接测试显示的ip是一致的

尝试直接使用clash代理端口转发的时候,发现在STUN第一步的时候就变成了switch直接连接STUN服务器,而不是把流量转发给代理,TCP的流量都全部转发给代理了,所以在连接测试这一步的时候switch所显示的IP就是代理ip,地理位置台湾。
而实际玩耍的时候根据流量包来看UDP流量都是直接和对端通信的,从和STUN服务器的通信状态中可以看见,我注册了一个153开头的ip上去,查一下,江苏南京联通,铁校园网,计划完全失败。

抓包研究表明,Switch设置代理的时候只转发TCP流量,而UDP流量不走代理,正如设置代理选项那一栏上写的,某些软件并不支持代理,而实际的结果却是只有eshop走代理。。。

通过网关接管全流量

如果说Switch的代理设置不转发UDP的话,那之前挂加速器的大姐和我联机我就不可能看到我这边的通信清一色是和她的代理IP一致的,因此单纯的设置代理服务器肯定不能实现UDP代理,需要新的实现方案
下了个灵缇试了一下,看看他是怎么做的
灵缇的实现方案为手动设置switch网关,DNS,和代理服务器三个选项

把手机设为switch网关,让所有流量到达手机之后让手机进行处理,即可强行接管UDP流量。一个简单的旁路由思路(我是网络垃圾呜呜呜)
因为发送流量都是看路由表的嘛,然后我把默认路由填到手机地址,那数据包第一跳就稳定到手机上,手机监听网卡,接管全流量,再选择Switch的流量进行转发,的确是个很棒的想法
之前也看到clash上说过使用TAP或TUN模式接管全流量,使得不走代理的软件也可以走代理

游戏联机通信情况

确实如榜一大哥曾经和我说的,Switch使用STUN服务器使玩家互相发现,若玩家之间NAT类型较好,通信质量佳,即可让其直接通信,如果双方通信质量不佳,比如存在D类NAT,则使用STUN服务器辅助传输数据。
没开加速器用D类玩玩了一把,整场通信下来发现我既在和房主UDP通信,时不时也会穿插一些和任天堂STUN服务器通信的TRUN包,wireshark中显示这个包的协议仍是STUN,不过后面的附加内容写的是TURN,是用来数据传输

TURN协议,用来解决P2P问题的,具体看百科吧。

clash TUN全局接管

2021.4.19 update

该方案似乎在实践上有些问题,后来发现了一个电脑开热点的网络共享解决方案,以及优雅arp劫持方案,弃置这个方案,用新的
Switch自建NAT优化指北
现在这个方案只是留着记录一下当初研究的思路

2021.8.6 update

最近又学了一点网络知识,突然想起来是不是因为windows机器没开路由转发所以连不上网?可以试一下把机器的路由转发开了再试试,不过现在switch不在手边并不能做测试了,文末参考链接中有启动windows10路由转发的教程

后经测试,好像还是不行。。。后文内容将更改为对该方案失败原因的研究

2022.2.12 update

看到了全新的解决方案,我开始对我当初的记忆产生怀疑,为什么当初我那个很奇怪的方案成功实现了?究竟是哪里发生了玄学的问题?遵循其他大佬的足迹走到了这步,发现了一个实现方案及其优雅,且并不繁琐,甚至不需要全局接管,我一直在寻找的其实就是这样子的一个软件。也许这个才是最为正确的思路。整合更新也同步到了上面提到的《Switch自建NAT优化指北》中,本文后续内容理论上作废,这个思路的出发点并没有太大的问题,但由于对网络的浅薄认识,并不能指出问题所在的点
后续仅可作为clash tun配置教程

但若PC不开启路由转发功能,就算有机器将其作为网关,又能实现转发吗?我觉得似乎不行,这也就是switch显示DNS查询失败的原因
启动wireshark,可以发现switch实践上判断是否联网就是在连接WiFi的时候对几个任天堂域名进行DNS查询,而从wireshark的结果可以看出,在未开启路由转发的情况下,虽然确实拿到了请求包,但PC对此无动于衷,该数据包被简单的抛弃,当然就无法完成DNS查询,导致失败

但是如果启动PC的路由功能呢?就会出现clash上行流量几百兆,CPU内存暴增,以及疯狂创建本地socket连接等情况。。。简单抓包发现clash自己那块网卡里面炸了。每秒上百兆的流量就是从那里面来的,目前猜测是可能路由转发导致了奇怪的类似环路的流量,然后原地反复跑导致的

2022.4.21 update

仔细翻了一下cfw的issue,似乎有很多人尝试使用clash在windows机器上充当网关进行流量转发,但我之前提过一个issue时作者便告知无法在windows上实现。。。现在翻了一下类似的issue贼多,所以我当初是怎么跑起来的。。。(记忆出现了紊乱?)
因此,windows机器下网关接管方案彻底废弃(但从有一个地方看到有人说win机器可以用surge做旁路由。有兴趣的可以去试试那个)
tun模式下如何实现网关模式 #1622
TUN使用问题 #1649
clash windows tun模式 作为网关 没有转发其他设备的请求 #1865

win和mac都可以转发,但是因为windows的interface-name绑定是设置local address实现的,转发打开之后这个这个连接就被转发回来,然后回环。

也许尊贵的Mac能用呢

至此,原网关流量接管计划完全失败

原文章部分

————————————–分割线———————————–

思路

和灵缇实现类似,通过在物理机上新加一个网卡,接管全局流量(物理机的也全接管了,QQ什么的都接管了。。。)
然后在switch上设置网关DNS为物理机,这样子Switch的全部流量第一跳也会到达物理机上的Clash网卡,被接管,不走UDP的流量也就在我们的掌控之中啦
然后Clash网卡上的流量会按照Proxy里面的规则转发

实现

直接搜Clash TUN有官方教程,下载dll安装服务,小地球变绿
配置mixin,让开关mixin来启动TUN,这里只有一个坑点,官方教程里的mixin样例少了一行。。。
导致缩进和内容都不对就不能正常启动

mixin: # object
  dns:
    enable: true
    enhanced-mode: redir-host
    nameserver:
      - 1.1.1.1 # 真实请求DNS,可多设置几个
      - 119.29.29.29
      - 223.5.5.5
  tun:
    enable: true
    stack: gvisor
    dns-hijack:
      - 198.18.0.2:53
    macOS-auto-route: true
    macOS-auto-detect-interface: true # 自动检测出口网卡

直接复制粘贴就行,具体选项可以去看文档

这里稍微多提一下enhanced-mode的redir-host和fake-ip的区别
redir-host是在进行dns查询时通过代理同时向多个dns服务器查询,并返回得到的结果作为结果。而fake-ip则是在查询时立即返回一个保留网段的ip,并在clash中存一个fake-ip和域名的映射,再由clash进行查询并返回
使用fake-ip时可能会遭遇到下级软件本身缓存了dns查询结果,导致clash挂了或者某些特殊情况时就上不了网了,可以简单的看openClash的wiki
常规设置

然后开关mixin开关就能看见自己多了一个Clash网卡
用route print命令查看本机路由表
TUN开启之前

IPv4 路由表
===========================================================================
活动路由:
网络目标        网络掩码          网关       接口   跃点数
          0.0.0.0          0.0.0.0     10.203.128.1   10.203.236.138     45
     10.203.128.0    255.255.128.0            在链路上    10.203.236.138    301
   10.203.236.138  255.255.255.255            在链路上    10.203.236.138    301
   10.203.255.255  255.255.255.255            在链路上    10.203.236.138    301
    ......

网关为校园网网关,接口为本机WiFi网卡的IP地址
TUN开启后

IPv4 路由表
===========================================================================
活动路由:
网络目标        网络掩码          网关       接口   跃点数
          0.0.0.0          0.0.0.0     10.203.128.1   10.203.236.138     40
          0.0.0.0          0.0.0.0            在链路上        198.18.0.1      0
     10.203.128.0    255.255.128.0            在链路上    10.203.236.138    296
   10.203.236.138  255.255.255.255            在链路上    10.203.236.138    296
   10.203.255.255  255.255.255.255            在链路上    10.203.236.138    296
    .....

显然可以看见,新增了一条指向198.18.0.1的路由,而这个IP正是clash创建的Clash网卡的IP,也就是说本机的所有流量都会按照这个路由表转发到对应的网卡上,再进行下一步处理
这时clash就已经接管了全部流量了,然后所有流量都会按照proxy的规则转发

愚蠢的思考

之前一直在想为什么网关能直接设置,两个主机间通信应该是需要端口的,而这里我并不设置端口监听,也没让switch选择通信端口,虽然我感觉这个通信的确是属于网络层而不在传输层,但我一瞬间没能想通通信是怎么完成的。。。
然后还问了下学长。。。。他突然和我说监听网卡,我才想起来网卡才是机器接受信息的最原始接口,端口只不过是区别不同进程间的通信罢了。

小小的困难

因为我之前的设置是不开系统代理的,Clash就作为一个简单的HTTP代理用,所以Proxy直接选的GLOBAL,浏览器上设置规则,而现在开了TUN之后还走全局代理未免显得有些愚蠢,那就得去看看Rule是怎么写的
当然是抄的机场写好的规则,但是规则分到最后涵盖的不全面,除去几个知名网站剩下的都是其他流量。
如果想给switch加速的话,其他流量都走代理是最好的,不然你也不知道你的联机对端是谁,也不知道任地狱服务器是啥,好像能设置检测switch的Mac地址然后对来源匹配的进行转发,不过太麻烦了懒得研究了。。。但是这样子其实绝大多数软件的流量肯定是不在知名网站的匹配范围内的,这样子就也会有很多不必要的流量被转发,就很烦,比如QQ就会顺理成章的变成在香港登录。。
如果其他流量不走代理,switch加速计划直接破产。。。

最终暂时决定,维持不变,就直接全局代理,在玩游戏的时候再开ClashTUN就是,不玩游戏就关掉
有时间再研究一下怎么配置规则

update

考试考完回家躺尸一个星期后更新,期间被出云大佬联系,学习了一些新名词。不过本废物暂时还不想动手去学,稍微调了一下clash的DNS设置就拉倒了,目前似乎能在体感上稍微感觉到好了一点点(大概),并不知道实际上好在哪

大佬和我说游戏流量遇到的一大问题在于UDP流量容易被运营商丢弃,俗称“断流”,所以还要在外面再套一层TCP。总觉得好麻烦哦。。
clash关于TUN模式的DNS设置的话官方文档好像有点问题,官方mixin里面dns配置的是redir-host但是TUN里面选了一个dns-hijack,这个只在fake-ip模式中有用,如果本身的配置文件就有fake-ip的配置的话,可以只添加TUN来完成流量接管

相关链接

请教TUN模式下UDP转发
TUN模式开启后无法接管系统流量
Windows 10上开启路由转发及添加路由
Nintendo Switch:~联机加速方案的研究与折腾~
Nintendo Switch:~使用Pcap2Socks给主机联机加速~