A/B

Btt网络相关

2022/04/29

btt/btfs 网络相关

btfs 项目是一个带宽/存储类项目，对于网络的需求是很大的，下面会列举几个关于网络的问题。

先明确一些概念：

  • 内网：指的是机房内网
  • 外网：指的是中国广域网，也就是最常接触到的网络
  • 境外网：指的是海外网络
  • 公网映射：指的是在核心路由上的配置，可以实现从外网到内网的访问

btfs 需要公网映射吗？

问题可以参考 2022-04-27-btfs 的公网映射..最新的测试结果显示，节点不需要配置公网映射，可以在链上交互数据，也持有合理的主机得分。

btfs 需要境外网络出口吗？

推荐要上，官方目前给的三个主网 rpc 都是美国加州的地址，因为国内网络环境复杂，可能存在DNS污染、GFW封锁等原因，心跳信息无法传递，使节点无法正常的运行。（出现此问题后，web面板会显示：网络不稳定，无法连接到 btfs 网络）。下面是这三个 rpc 地址和基础信息。

# https://bttc.trongrid.io/
$ ping bttc.trongrid.io
PING bttc-trongrid-134413502.us-east-1.elb.amazonaws.com (3.217.237.146): 56 data bytes
Request timeout for icmp_seq 0
^C
--- bttc-trongrid-134413502.us-east-1.elb.amazonaws.com ping statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss
$ curl cip.cc/3.217.237.146
IP	: 3.217.237.146
地址	: 美国  美国
数据二	: 美国 | 弗吉尼亚州阿什本Amazon数据中心
数据三	: 美国弗吉尼亚阿什本 | 亚马逊
URL	: http://www.cip.cc/3.217.237.146

# https://rpc.bt.io/
$ ping rpc.bt.io
PING rpc.bt.io (52.7.235.42): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
^C
--- rpc.bt.io ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss
$ curl cip.cc/52.7.235.42
IP	: 52.7.235.42
地址	: 美国  弗吉尼亚州  阿什本
运营商	: amazon.com
数据二	: 美国 | 弗吉尼亚州阿什本Amazon数据中心
数据三	: 美国弗吉尼亚阿什本 | 亚马逊
URL	: http://www.cip.cc/52.7.235.42

# https://rpc.bittorrentchain.io/
$ ping rpc.bittorrentchain.io
PING rpc.bittorrentchain.io (52.7.235.42): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
^C
--- rpc.bittorrentchain.io ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss
$ curl cip.cc/52.7.235.42
IP	: 52.7.235.42
地址	: 美国  弗吉尼亚州  阿什本
运营商	: amazon.com
数据二	: 美国 | 弗吉尼亚州阿什本Amazon数据中心
数据三	: 美国弗吉尼亚阿什本 | 亚马逊
URL	: http://www.cip.cc/52.7.235.42

arp 异常问题

# tail -10 /var/log/syslog
Apr 28 19:16:57 nl-5288-V5 kernel: [365687.050754] neighbour: arp_cache: neighbor table overflow!
Apr 28 19:16:57 nl-5288-V5 kernel: [365687.051954] neighbour: arp_cache: neighbor table overflow!
Apr 28 19:16:57 nl-5288-V5 kernel: [365687.052283] neighbour: arp_cache: neighbor table overflow!
Apr 28 19:16:57 nl-5288-V5 kernel: [365687.074320] neighbour: arp_cache: neighbor table overflow!
Apr 28 19:16:57 nl-5288-V5 kernel: [365687.074871] neighbour: arp_cache: neighbor table overflow!
Apr 28 19:16:57 nl-5288-V5 kernel: [365687.139645] neighbour: arp_cache: neighbor table overflow!
Apr 28 19:16:57 nl-5288-V5 kernel: [365687.146649] neighbour: arp_cache: neighbor table overflow!
Apr 28 19:16:57 nl-5288-V5 kernel: [365687.146961] neighbour: arp_cache: neighbor table overflow!
Apr 28 19:16:57 nl-5288-V5 kernel: [365687.147239] neighbour: arp_cache: neighbor table overflow!
Apr 28 19:16:57 nl-5288-V5 kernel: [365687.147509] neighbour: arp_cache: neighbor table overflow!

arp 是地址解析协定，一般只在内网有效，系统内维护一张 arp 表，对应了ip和mac地址，这样内网的数据传输会很快。在我们的机器内，arp 的数量在 101 个，这是合理的，他包括了 100 个 docker 容器的虚拟地址mac映射和网关的mac映射，按理说不会出现上述问题。这个问题影响范围不好确认。

连接境外方案

因为交互过程中需要连接的 rpc 地址不在国内，在部分操作中可能无法正确连接。尝试用代理的方案进行数据转发。

初步使用的方案为 clash 代理本机数据转发，配置容器内的代理，从而实现数据转发，但实际操作后失败了，原因是 clash 大部分代理走的都是 sockets5（socks5），而 docker 原生的代理配置仅仅支持 http 代理。

但还是记录下整体的方案：

1. 配置 Linux clash

参考：https://einverne.github.io/post/2021/03/linux-use-clash.html
本质上就是安装程序，从机场服务商获取配置文件，程序运行托管到系统，读取配置文件，等待转发

2. 配置 Docker 代理配置

方案很多，在 17.07 之后使用 ~/.docker/config.json 的配置。

cat ~/.docker/config.json
{
  "proxies": {
    "default": {
      "httpProxy": "http://172.17.0.1:7890",
      "httpsProxy": "http://172.17.0.1:7890"
    }
  }
}

这里有一个坑，就是ip的配置。Docker 有多种网络配置，默认的 bridge 模式，会生成一个虚拟网卡，也是一个虚拟的网关 172.17.0.1，这里就是这种情况。如果开启的是 host 模式，那么直接指定 127.0.0.1 即可。

3. 启动 Docker 容器，判断网络状况

这里不需要配置参数，直接运行容器就行。但这里也有坑点，就是容器对于代理配置是有记忆的。换言之：容器启动的时候代理配置是如何的就不会改变；配置代理前的容器重新启动也还是无代理的状态。这里的结论就是无法实现代理，rpc协议可以通过 https/sockets5 进行代理，docker 支持 http/http 代理，clash 支持 http/sockets5 代理，无法达成一致。

参考：

在这种情况下，还有两个思路：

  • 使用 nginx，将 https 的数据转成 http 的数据交给 clash，然后再转发
  • 使用 polipo 做全局代理，解决 clash 的不足

使用 polipo 方案失败，主机数据转发没有问题，但是 docker 相关网卡数据转发显示：Refusing connection from unauthorised net。

# /etc/polipo/config
proxyAddress = "0.0.0.0"
proxyPort = 8183

logSyslog = true
logFile = /var/log/polipo/polipo.log
socksParentProxy = "127.0.0.1:7890"
socksProxyType = socks5
allowedClients = "127.0.0.1"
proxyName = "polipo"

$ curl --proxy http://127.0.0.1:8183 https://www.google.com
# 上述场景下，可以通过 8183 转发到上游的 7890 端口，然后数据正常返回
# 上述配置中，allowedClients 是一个允许转发的变量，但除了设置为 127.0.0.1 之外都无法正常运作。错误显示为：Refusing connection from unauthorised net

至于 nginx 方案，我觉得可行性也不大，需要手动

参考：

Search

    Table of Contents