Firefox 指向 127.0.0.1:8000,N2N 边缘已启动,对等节点在其覆盖地址上响应 ping,浏览器却仍然报告代理拒绝了连接。这条链路里没有任何矛盾。覆盖网络为主机提供一个在私有网络中可达的地址;它不会创建说代理协议的进程。浏览器要的不是通往对等节点的路由。它要的是一个本地监听器。

这里把两条连接混为一谈,分开画就能在一分钟内弄清大部分困惑。

两条连接,不是一条

第一条连接从浏览器通向在 loopback 端口上监听的任何东西。那是一个本地套接字,如果没有任何进程持有它,连接在单个数据包到达 N2N 之前就会被拒绝。第二条从代理进程通向它正在获取的源站。这条路径由代理主机的路由表选择,可能是普通上行链路、另一条隧道,或与覆盖网络无关的策略路由。

对等节点能 ping 通,只能证明覆盖网络可以在边缘地址之间投递数据包。它不能证明 8000 端口上有监听器,也不能证明那台主机能到达源站。不同的故障,不同的修复。

监听器该放在哪里

绑定到 127.0.0.1 的代理是刻意本地化的:它只接受来自运行它的机器的连接。这对个人代理是正确默认值,对跨覆盖网络共享却是错误形态。要服务覆盖网络的对等节点,需要在覆盖接口上绑定地址,或者由一个转发组件终止 loopback 连接并转发它。无论如何,都应由明确的策略决定哪些覆盖来源可以使用该服务,因为共享网络上的开放代理等于邀请。

用套接字列表而不是配置文件来检查实际绑定。覆盖网络启动前启动的守护进程可能仍然绑定在一个已经不存在的地址上。

localhost 不是对等节点

在浏览器的代理字段里,localhost 指向浏览器自己的机器。它不是边缘,不是超级节点,也不是隧道远端的主机。如果代理运行在另一个对等节点上,请把该节点可达的覆盖地址和端口填入字段,然后确认监听器接受来自你边缘地址的连接。

超级节点帮助边缘互相发现;它们不是代理服务。把超级节点地址当作代理端点,只会得到同样的拒绝,外加一步困惑。

路由无法完成握手

即使地址正确,路由也不等于代理。HTTP 代理连接以 CONNECT 请求或绝对形式的请求行开始,SOCKS 代理则以版本和方法协商开始。路由器或覆盖网络只转发字节;它不解析这些消息,也不会替你打开后续连接。这就是为什么对 ping 和 SSH 有效的路由,对浏览器代理仍可能失败:浏览器需要的是一个配合的进程,而不只是可达性。

如果目标只是到达对等节点上的某个服务,请去掉代理设置,直接使用该服务的覆盖地址。

按顺序测试边界

确认覆盖地址有响应,然后确认配置端口上存在监听器并记下它的绑定地址。发一个受控请求并读取代理日志,以便知道故障在监听器还是在后续获取。最后,检查代理主机的路由和针对源站的 DNS 策略。

N2N 项目把边缘和超级节点记录为覆盖网络的组件。它不会把边缘变成应用代理,也没有任何路由配置能添加一个没人启动过的协议处理器。

相关文章