maybeonly 最近的时间轴更新
maybeonly

maybeonly

V2EX 第 193338 号会员,加入于 2016-09-25 08:10:24 +08:00
今日活跃度排名 11495
maybeonly 最近回复了
1 天前
回复了 8675bc86 创建的主题 宽带症候群 最近几天宽带丢包率极高
有 bug (物理)
不过我以前租房的时候也是那样,那些设备发热,小强喜欢往暖和的地方聚集
更有甚者在里边产卵的,小小强长大了出不来在里边活活饿死的也有
解决方法就是……换一个,没办法,喷药没用。
后来搬家了,家里没有小强,也就没有这种问题了。
旁路由和 ipv6 兼容很成问题。建议有 v6 刚需的情况下换成主路由使用,或者 v4 和 v6 场景分开(二级路由)
和梯子本身支持不支持双栈关系不是那么大,根本原因是 v4 和 v6 的网关是没关系的,dns 的获取途径有多种( dhcp ,ra ,etc ),解析结果是分开的( a ,aaaa ),旁路由要兼容 v6 的话你得把各种 v6 网关都指过去还要避免收到主路由的 ra

然后在梯子那里把所有去墙外的 v6 都 reject 掉就行了,客户端会自动用 v4 尝试。
@milkman155
这种看着有可能是单向绕路,也就是联通到电信走北京,电信回联通直接在本地解决
12 天前
回复了 yyysuo 创建的主题 宽带症候群 终极的分流策略
我现在的实现是这样的:
基础的还是白名单+ip 分流+自建递归
+黑名单直接用 1111 解析的
然后每天在 gww (宽带出口)上收集来自递归服务器的访问 udp 53 端口的请求
夜里解析这些域名,然后动态扩充白名单。

这些累积的白名单目前是 3 个月校对一次

基本逻辑还是那个:有任何一层权威在墙内的就算墙内域名。
实际上遇到过的问题:有些域名在 dnspod 或者 ali 上,但是只能通过海外访问,这些就得手工配置了……
20 天前
回复了 chaniqure 创建的主题 宽带症候群 请教一下关于访问家庭网络的一些事
有公网 ip 直接 wireguard/openvpn 回家
用一般的梯子也可以
然后所有流量直接从家里出,顺便过墙
22 天前
回复了 devli 创建的主题 宽带症候群 旁路由真的不稳定吗?
@basncy
@huihuilang

所以主路由的话方便很多,可以卡住 v6 流量上策略
下发真实地址或者 fd 开头的地址都可以,也可以直连 v6 直出/过梯子走转发或者 nat66
甚至可以下面不开 v6 但是给梯子开

最后说个旁路由无论如何解决不了的:多线
23 天前
回复了 devli 创建的主题 宽带症候群 旁路由真的不稳定吗?
@basncy
搞复杂的策略显然还是上主路由靠谱啊,我家除了 coturn 这些都在主路由上实现了
旁路由开 v6 ,反正我是想不出来除了 nat66 以外的方法

@lihaohenqiang
你说的后半段是指家用吗……家用能长时间高负载,pcdn 也不行吧?
以及,完全想不出来正常家用环境能小包跑满带宽的
现在六百块买个 n100 ,跑满千兆梯子+pppoe 都毫无压力

最后,主路由设计好照样有折腾空间。当然,no zuo no die 。
23 天前
回复了 devli 创建的主题 宽带症候群 旁路由真的不稳定吗?
旁路由并没有不稳定,而是旁路由结构比主路由还要复杂,驾驭旁路由需要的网络知识更多
当然,如果真的能完美驾驭旁路由的水平,除非一些极端特殊情况,几乎都直接上主路由了
@XXOO133 @xyz3210

20 年前互联互通是网络结构和技术不行,属于与地斗
现在的互联互通是运营商和 pcdn 一起搞的,属于与人斗

我隐约记得 20 年前南京电信的家宽限制流量每月 60GB
领先了 20 年
谁有印象?
运营商推出了省间结算打击 pcdn ,pcdn 使用跨省调度进行回击。
这下把跨网互联直接橄榄了,我必须说,这波操作 666
恢复跨网结算吗?这可比跨省结算难多了,毕竟跨省结算都是一个(集团)公司,大老板一声令下就可以搞了。
跨网……哼哼哼,最要命的是看起来上面是支持 pcdn 的,至少是不反对。
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1544 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 13ms · UTC 17:14 · PVG 01:14 · LAX 09:14 · JFK 12:14
Developed with CodeLauncher
♥ Do have faith in what you're doing.