V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  maybeonly  ›  全部回复第 8 页 / 共 10 页
回复总数  191
1  2  3  4  5  6  7  8  9  10  
2023-08-16 15:21:53 +08:00
回复了 bg226316 创建的主题 宽带症候群 校园网问题 Cpe+内网
找个电脑(最好是路由器)同时连接 cpe 和学校内网,然后大家把网关指向这个电脑。
(所以说最好是路由器,可以直接下发)
这个电脑(路由器)的默认网关在 cpe 上,但是学校免费 ip 段走学校的网口。
学校的免费 ip 段通常是固定的。至于 v6 ,用 cpe 还是校园网看你喜好了。
2023-07-19 16:16:36 +08:00
回复了 ppbaozi 创建的主题 宽带症候群 关于 pppoe 下 ipv6 的 wg 隧道需不需要优化 MTU
当分片太大的时候,v4 可以路由器帮你分片,但是 v6 就要求路由器给发送方返一个 icmpv6type2 ( too big ),要求源站分片后重发。
这样的话,即使 mtu 设置不正确,也可以最终送达才对,只是在最初建立连接的时候多花了不超过 1rtt 。

mtu 的那个所谓卡住的“bug”往往是这么发生的:
你的 syn 到了服务端,然后服务端返了 syn/ack 给你,再然后你 ack 过去。到这里都没问题。
接下来就有问题了。你发出去的第一个带载荷的数据包可以到达服务器(最多就是被路由之类的戳一下 too big ),但是服务器返回的包就没那么幸运了。
典型的场景是这样的:服务器那边的 ip 是个虚拟 ip ( vip ),然后负载均衡器( vs )没有正确转发给真实服务器( rs )(对于 dr/tun/nat ),甚至压根就不能转发( toa )。
或者比较少见的情况,服务器那边配置了防火墙,根本就没允许 icmpv6type2 过。
结果都是,服务器收不到 too big ,没机会调整分片大小重发,最后就卡住了。

直接喊 1280 是可以“通”的,因为 ipv6 要求的最小 mtu 就是 1280——所以诸多压根不能转发的 toa 实现就直接做成了强制 1280——但是能不能“好”就是另一回事了。

出现隧道的时候,就更复杂了。隧道外边和里边是两层,可能会有不同大小的 mtu 。如果外层都 1280 了里层怎么过啊?又得分片反而不是什么好事情。至于 Clamping ,其实在一边双向 clamping 也是可以的。

最后,mtu 对所有 ip 报文都适用,clamping 或者说 mss 只用于 tcp ,也就是说,一些其他场景还是需要 too big 。
目视可及的话首选无线网桥
有条件甩光纤的话也可以光纤
2023-06-30 15:07:28 +08:00
回复了 lemonTreeTop 创建的主题 宽带症候群 软路由的最佳实践
@thereone 主备实现不难,关键是意义在哪儿……如果旁路由这些都能干了,他还安心当个旁路由吗……为什么不直接升级为主路由呢,网络更简单清晰。当然,如果作为主路由备份是为了过渡到主路由的话,我双手赞成。

多线场景是极限自定义的场景。只有作为主路由,才好充分利用多条宽带的能力。因为流量是双向流过的,才好建立 conntrack 。
简单的说,如果有个 vps ,然后自己有两条宽带 a 和 b ,再乘上 v4 和 v6 ,就变成 4 条线路了。
这一点旁路由完全没办法决定自己出去的直连数据包从哪里出去……如果要同时用两条不同的线路和远端建立两条链路做主备,旁路由最多最多只能一个 v4 一个 v6 然后让主路由写路由表了吧。
但是在主路由上直接搞的话,一切都可能实现。
以及前面说过的,端口映射,也需要在主路由上有相对复杂的配置,这一点旁路由很可能是个干扰。
再考虑 v6 的话,旁路由就更难受了。

其实就是说,当网络结构越来越复杂的时候,旁路由需要越来越多地与主路由交互。这时候就更显得旁路由多余甚至有点难受了。
当然重复一下观点,作为学习练手,或者由于条件所限使用旁路由是很合适的。除此之外长期稳定使用特别是重度使用的话,建议直接做在主路由上。
2023-06-30 14:41:03 +08:00
回复了 lemonTreeTop 创建的主题 宽带症候群 软路由的最佳实践
@thereone 双向经过一个设备的话可以用(有点复杂的) conntrack 解决。单向经过的话就没什么好办法了。
2023-06-30 14:30:45 +08:00
回复了 lemonTreeTop 创建的主题 宽带症候群 软路由的最佳实践
@thereone 来回路径不一致可能还是小事,端口映射确实可能会出问题:
假设内网用户是 192.168.100.200 ,主路由 192.168.100.1 ,旁路由 192.168.100.9
映射(包括各种映射)了 8888 端口到外网端口 198.51.100.100:8888 。
此时有来自 203.0.113.2 的用户访问了你的公网端口,然后他给你发了一个包。
203.0.113.2:12345->198.51.100.100:8888
进行 nat 以后,通过主路由转发到了客户机,到这里还没问题。
然后客户机需要给他回包:
192.168.100.200:8888->203.0.113.2:12345
这时候这个包首先被发送到旁路由。这个时候说不定(看策略)就被走其他路径“劫走”了,
然后可能通过 vps 的出口发给了对端的机器,对端看起来数据包是这样的:
192.0.2.33:27428->203.0.113.2:1234
这数据包哪儿来的……于是就扔掉了,通信失败。

单点故障的场合,不认为家庭环境有那么多需要热备的,要坏的话主路由一样会坏,主路由更需要热备吧……光猫也可能坏,怎么热备呢?局方给你套个 SDH 大圈圈吗……不可能的吧……连链路都只有一条的说……
虚拟链路的话……就只有一条吗……就算只有一条,主路由一样可以临时禁用(如果这是希望的结果的话)。不要默认旁路由容易坏,更不要默认特殊功能的设备就容易坏。如果设置正确、运维得当是没问题的。当然,如果是刚上手的学习阶段,还是可以用旁路由练手的。

接下来就是性能,转发性能确实比不上硬件但是在家用场合下可以忽略。2023 年了,就算还在用 j1900 ,nat 性能会成为问题吗?小包转发确实有可能会没法千兆线速,但是家庭网络您在干啥会有那么多小包?家庭网络最大的 cpu 开销,一是 pppoe ,二才是加解密。pppoe 是个跟不上时代的古董协议,特别耗费资源。再说,升级个设备其实也没多少钱,考虑下宽带费用电费可能还有其他按月计价的费用……设备成本可是可以摊销的。

透明网桥我实现过,整体上还不错但是有点其他问题,现在 broute 表都被拿掉了,以后不知道该怎么搞。可是那也是条件所限拿不到路由的时候才用的,拿得到路由的话用路由舒服多了。企业应用也一样,管理设备要串行接入网络的话要物理操作要断网,但是路由指过去的话就可以远程操作,也可以屏蔽,还可以部分应用。

至于配置方便程度就更不要说了,拿着主路由权限可以下发各种东西,你要给多少设备设置网关啊?我家的电脑×n 、手机×n 、pad 、电视、虚拟机×n ,都要一个个爬上去设置 dns 吗……我家下发的 dns 的 ip 都是一样的,但是会根据策略拉到不同的服务,返回的东西也可能不一样,这些用旁路由……不是做不到,而是,还是算了。

最后,多线上联(不同运营商多条宽带)这一条,旁路由被薄纱。
2023-06-29 16:24:09 +08:00
回复了 lemonTreeTop 创建的主题 宽带症候群 软路由的最佳实践
作为入门的话,旁路由或许还好啦
或者某些条件受限,比如路由器房东的 /搞坏网络会被老婆要求跪主板,那也就旁路由吧
时间长了还是主路由的好,流量自然流过,对下游设备完全透明,能实现的东西也更多
不稳定?最大的可能是操作不当,我家核心路由不停电都不重启的
性能? n100 来一个,路由场景没有什么 hold 不住(过剩了)
至于网络分层……运行在 ip 层有什么行,完全可以。

所以,“多数用户”到底是谁啊。

最后那句倒是很同意。
2023-06-28 10:17:29 +08:00
回复了 strp 创建的主题 宽带症候群 北京移动家宽能有公网吗?
@hadoop 和无公网 ip 的家宽没区别的感觉,跨网一定程度上会被 QoS
2023-06-28 08:41:46 +08:00
回复了 coooke1 创建的主题 宽带症候群 深圳电信公网 IP 一个月 100!
一般来说搬家搞丢了可以免费要回来吧。
2023-06-22 08:50:00 +08:00
回复了 lns103 创建的主题 宽带症候群 很多正常网站的 cloudflare cdn ipv4 被墙
@admin13579 大炮打的所谓“境外反动网站”是 github 。
以下内容转载自 wikipedia https://zh.wikipedia.org/wiki/%E5%A4%A7%E7%82%AE_(%E7%BD%91%E7%BB%9C%E6%94%BB%E5%87%BB%E5%B7%A5%E5%85%B7)


大炮的第一个目标是 GreatFire 运营的“依附的自由”相关项目, 首次攻击是对 GreatFire 运营在内容分发网络上的镜像站点,出现在 2015 年 3 月 14 日。之后 GreatFire 报告大规模的攻击出现在 3 月 17 日。对镜像站点的攻击在 3 月 25 日终止。

之后在 3 月 26 日,被 GreatFire 用于托管反审查项目的 GitHub 也受到攻击。
参见:对 GitHub 的审查和封锁 § DDoS 攻击

多次技术报告显示,对 GitHub 的攻击的方式是采用了 HTTP 劫持,通过向百度注入恶意的 JavaScript 代码,其功能是每隔 2 秒加载一次 GreatFire 或其运营的纽约时报中文网镜像站点的账号主页,以使从中国大陆以外访问百度网站及广告的流量转换为 DDoS 攻击发送至目标。对 GreatFire 运营的镜像站点也使用了了类似的方法。百度已否认自身产品存在安全问题。

这次攻击导致 GitHub 在全球范围内的访问速度下降。

根据系统状态消息页面的显示,已于 3 月 31 日停止了网络攻击,该日凌晨 0:09 ( UTC )已经稳定。GitHub 在其 Twitter 与微博予以了证实。至此,此网络攻击共持续了五天。Google 的研究人员观测到 HTTP 劫持在 4 月 7 日终止。
世界,加钱可及——中国电信
换小鸡
用机场
买中转
2023-06-05 17:32:55 +08:00
回复了 willwon1 创建的主题 宽带症候群 购买软路由是否真的有必要?
家用路由等级
Level0 什么都不会,运营商光猫解决一切。
优点:简单,省心。缺点:什么都做不到。
Level1 最基本的硬路由。
优点:简单,但是不如 lv0 简单。缺点:就是没有优点。
以上为入门级别,出现问题的时候呼叫 10000/10010/10086 。
Level2 刷 openwrt 的硬路由。
优点:相对简单,容易购买,上限高,可以翻墙、可以实现部分 NAS 功能。缺点:可能面临性能不足的问题。
Level3 旁路由软路由。
优点:不怕坏,可以折腾,适合学习。缺点:网络架构不够优雅。
Level4 软路由做主路由。
优点:All in boom 。缺点:All in boom 。
Level5 自由发挥。
优点:自己研究,需要什么就自己搞。缺点:自己研究,需要什么就自己搞。

本质上是看自己需求了。
对于绝大多数只会上网的普通用户来说,Lv0 是最佳的。
对于想要翻墙的用户来说,Lv2 可能是最合适的。
对于想要学习的用户来说,Lv3 是非常适合折腾的环境,但是这种场合下恐怕会慢慢自发向 Lv4 演进。
对于想要实现一些和别人不一样的东西,做一些自己需求,并且有足够水平的才考虑 Lv5 。
至于 Lv6 ?或许自己设计硬件算 Lv6 ,还是 Lv5.5 呢?
2023-05-25 17:14:52 +08:00
回复了 q84055472 创建的主题 宽带症候群 如何查看 IP 是否是否是公网 IP
在机器上抓包
找外边的别人 ping 你
你能收到那边过来的 ping 包
那就是公网
2023-05-25 10:13:49 +08:00
回复了 luozu 创建的主题 宽带症候群 关于联通宽带 对海外 IP 断流 QoS
看看日历
过两周再看看
万一它就自己好了呢
2023-05-23 14:36:32 +08:00
回复了 Rooger 创建的主题 宽带症候群 中国移动的宽带真便宜,有什么坑吗?
北京联通+移动
默认路由指联通
都有公网 v4+v6 (移动要+20/月,价格合理童叟无欺)
日常无问题,出海看线路,通常是移动亚太好联通欧美好
两个都是光猫要桥接直接根师傅说后台下发
有过推销电话让提速还有推 fttr 的,都无视了……
网线退休我是不信的,光纤坏了没法自己修,网线透明胶请战(至少能撑几天)
光纤还有伤眼的潜在风险,网线……漏电? 48vpoe 虽然理论上会电人……但是皮也没那么脆吧。
所以网线还能跑 poe ,这一点是光纤无论如何都解决不了的。
其他,光纤自己问题,就 sc lc 口,都能恶心半天的。
就不说组网了,绝大多数用户分不清接入和组网。

另外,fttr 对于不会弄但是不差钱的客户是有用的,对这个论坛的用户基本上都是负面价值。
当年北京联通割接掉公网,早上发现,直接 10010 就“您好,公网 ip ,谢谢”,然后对面“您十分钟后重新拨号即可”,然后过了 10 分钟重新拨号就回来了,相当干净没有废话。
话说现在感觉一个月 ip 没变过了……
1  2  3  4  5  6  7  8  9  10  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2711 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 28ms · UTC 10:05 · PVG 18:05 · LAX 02:05 · JFK 05:05
Developed with CodeLauncher
♥ Do have faith in what you're doing.