V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  LnTrx  ›  全部回复第 18 页 / 共 41 页
回复总数  805
1 ... 14  15  16  17  18  19  20  21  22  23 ... 41  
楼里提了很多其他软件,如果楼主觉得自己的解决方案更胜一筹,不妨用后做个详细对比
2022-09-04 17:00:48 +08:00
回复了 jyeric 创建的主题 宽带症候群 关于电信 sdn 网关 ipv6 网络裸奔问题
@jyeric 同一主机内为不同应用单独分配 IPv6 是一个值得研究的问题,目前比较成熟的经验还比较少。
对于服务端场景,可以沿用多 IPv4 主机的经验,例如在写端口监听时直接指定 IPv6 地址。
对于应用端场景,我能想到的做法主要还是虚拟化。例如 VMware 下开的虚拟机,设为桥接模式就会获得与主机不同的 IPv6 地址,从而实现分离。对于 Docker 来说固定前缀比较好配,动态前缀可能需要依赖脚本,例如 https://github.com/wido/docker-ipv6 (未验证过)。
2022-09-03 23:40:56 +08:00
回复了 jyeric 创建的主题 宽带症候群 关于电信 sdn 网关 ipv6 网络裸奔问题
所谓“IPv6 扫不到”是跟 IPv4 相比的。在 IPv4 下,扫遍全网是可行的。如果常用端口配置薄弱,分分钟就被人端了。IPv6 地址空间非常大,除非掌握很具体的信息,扫段几乎是不现实的。

楼主指出 IPv6 可能通过应用主动暴露,这个风险是真实存在的。安装各类应用的设备,主要是有用户操作的( PC )或者本来就面向外网的设备( NAS ),这些设备基本都有安全机制。即便没有,攻击面相比公网 IPv4 还是小很多,攻击的实现和范围受到很多限制。就像是在 IPv4 下的 DMZ 主机,很多人把常用端口调到非标准端口就完事了。尽管十分草率,但被攻陷的概率也会小很多。

当然,更高的安全性是值得追求的。个人认为 IPv6 时代的不应该继续假设内网是安全的,而应该基于“零信任”,做好机器本身的安全防护和验证。特别是对于经常移动的设备,它们的上级网关本来就不可控,虚幻的安全感可能反而导致翻车。如果还是担心,也可以借助 IPv6 超大地址空间的优势,给 bt 、ipfs 这类应用分配独立的地址(如虚拟机),从而仅把安全的的、与敏感数据隔离的服务暴露给外部。
2022-09-03 22:50:23 +08:00
回复了 jyeric 创建的主题 宽带症候群 关于电信 sdn 网关 ipv6 网络裸奔问题
用户设备很多是可移动的,把安全寄托于网关可能反而被偷袭
Windows 自带的防火墙就可以限制入站为本地子网
2022-09-01 21:25:05 +08:00
回复了 youx 创建的主题 宽带症候群 FTTR 光纤到房间 最大的好处是 方便和邻居共享宽带
@wangyuyang3 有些学校是直接接入教育网的,其中有的收费、有的不收费。根据教技〔 1996 〕 55 号,教育网是非赢利性的,因此可能不适用《电信业务经营许可证管理办法》。
2022-08-30 19:06:04 +08:00
回复了 touchfishcc 创建的主题 NAS NAS 有什么好玩的功能吗?
自建同步云盘,回避百度、WPS 被封的风险
2022-08-30 18:22:51 +08:00
回复了 Licsber 创建的主题 宽带症候群 关于家庭 ipv6 网络的“裸奔”问题之我见
@Licsber 威联通不了解,群晖自己提供的 DDNS 是支持双栈的。想用自己的服务商,也有现成的 sh 脚本可以加入计划任务。更不用说 Docker 和 SSH 了。
2022-08-30 14:16:11 +08:00
回复了 lxr760 创建的主题 宽带症候群 关于运营商搞假公网,我觉得至少比没公网要好
个人认为主要的麻烦在于,用户以为自己是真公网。没有问题还好,有问题排查时不会想到还有这一出。
也同意楼上观点,希望光猫的 IPv6 防火墙搞好一点。
如果只需要 DDNS 没必要用花生壳。各大域名提供商基本都有配置解析的 API ,网上也很容易找到现成的脚本。
2022-08-30 14:06:54 +08:00
回复了 Licsber 创建的主题 宽带症候群 关于家庭 ipv6 网络的“裸奔”问题之我见
@Licsber 想问一下物联网设备需要 DDNS 的场景是什么?如果是品牌商的物联网设备,那设备间的相互发现应该不劳用户操心。如果是给 DIY 玩家又不可编程的设备,那公网访问能配 TLS 么?不能的话 DDNS 暴露应该不安全,或者要依赖其他设备强化安全才接触公网,抑或是该设备的安全本来也不重要。
IPv6 打破了原来“内网”的安全边界,让每个设备都可被公网连接,恰好可以促使各种联网设备朝“零信任”的方向发展。个人认为,把所有设备一视同仁当作外网设备进行验证和授权是未来的发展趋势,需要公网连入、有安全需求但又缺乏安全机制的设备在 IPv6 下则有点不好处理。
2022-08-29 21:39:03 +08:00
回复了 isad 创建的主题 宽带症候群 公网 IP 并不重要
其实楼主最后一段已经可以用来反驳标题了
2022-08-28 14:49:02 +08:00
回复了 Licsber 创建的主题 宽带症候群 关于家庭 ipv6 网络的“裸奔”问题之我见
@MNIST 只放通部分 v6 访问的方案一直存在,只不过在实践中都比较麻烦。如果认为增加的麻烦复杂性值得上增加的安全性,符合自身需要就行。
2022-08-28 13:53:00 +08:00
回复了 Licsber 创建的主题 宽带症候群 关于家庭 ipv6 网络的“裸奔”问题之我见
@Licsber 我原贴的意思是要有总开关。但对于非小白的家庭用户,更精细的防火墙控制目前还没有比较好的方案。如果有公网入站需求,在权衡利弊之后,SLAAC+全部放通也是一种可选项。
v4 暴露端口的风险很大程度上源自全网 IP 的扫射,这在 v6+SLAAC 下这变得很难。设置 DDNS 可让域名关联到 IPv6 ,但好像没有同样低成本的方法可以遍历各域名。虽然攻击的可能性仍然存在(如证书),但相比 v4 小很多。
既然觉得 DDNS 暴露在公网不安全,那么这种设备多数是使用者可控、可编程的。不一定要沿用 v4 的集中管理策略,每台机器甚至每个虚拟环境都可以有独立的 DDNS 。
UDP 打洞问题我在原贴有讨论。v6+防火墙的打洞比 NAT 要方便不少,但似乎需要没有防火墙的 peer 做中介,如果大家都开防火墙也许会有问题(特别是比较冷的种)。
个人认为 IPv6 下还是要强终端、弱网关。一方面,网关的 IP 是相对容易被探测发现的。如果承载路由、防火墙之外的太多东西,安全弱点造成的风险比终端更大。另一方面,移动互联网时代终端难免跨网移动。外部网关的安全性自己无法掌控,如果终端不加防范,那也会引狼入室再通过内网扩散。无数的开发者无法全部信任,他们既可以向防火墙申请暴露有弱点的端口,也可以不经防火墙自行打洞建立有弱点的 P2P 通信。如果真对安全有很高要求,那么终端的安全更要认真对待。
2022-08-27 21:40:25 +08:00
回复了 Marionic0723 创建的主题 宽带症候群 关于运营商分配假公网 IP 的问题
关键看是什么需要吧?低位端口本来就是封的,高位端口如果外网主动访问正常,很多人也不会在意。
2022-08-27 21:37:18 +08:00
回复了 Licsber 创建的主题 宽带症候群 关于家庭 ipv6 网络的“裸奔”问题之我见
对于楼主的场景,如果 smb 服务和 PT 下载走不同的 SLAAC IPv6 是不是就可以了?这个是容易实现的。
2022-08-27 21:21:01 +08:00
回复了 Licsber 创建的主题 宽带症候群 关于家庭 ipv6 网络的“裸奔”问题之我见
可以参考稍早前的讨论: https://www.v2ex.com/t/833550
2022-08-11 16:19:11 +08:00
回复了 hhhhhh123 创建的主题 程序员 我的服务器是不是被人盯上了?
公网 IPv4 就是会这样
2022-08-09 22:32:11 +08:00
回复了 delpo 创建的主题 宽带症候群 分享一个在 NAT1 下将端口打开到公网上的方法
很好的想法。过程中涉及很多方面技能的综合运用,或有用于教学的潜力。
@industryhive 如果真的变成算力军备竞赛的话,那胜率恐怕不大,因为算力芯片的绝大部分产能未在内地。当然,由于“打赢”军备竞赛没什么好处,而且必须要长期保持算力优势才能防止“死灰复燃”,真发生的可能性不大。
@industryhive 几大国内矿池的算力并不是都在境内。想要打击挖矿,到现在其实也没有清零。
1 ... 14  15  16  17  18  19  20  21  22  23 ... 41  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5983 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 32ms · UTC 03:04 · PVG 11:04 · LAX 19:04 · JFK 22:04
Developed with CodeLauncher
♥ Do have faith in what you're doing.