家用级别路由器,对 v6 支持如何? mesh 的支持如何? AP+AC 的支持如何? - V2EX
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
bigghost

家用级别路由器,对 v6 支持如何? mesh 的支持如何? AP+AC 的支持如何?

  •  
  •   bigghost 2020 年 12 月 6 日 3298 次点击
    这是一个创建于 1965 天前的主题,其中的信息可能已经有所发展或是发生改变。
    谢谢。
    因为各个运营商的家宽,基本都分配了公网的 v6,不想浪费,
    但是怕 AC+AP 模式不透穿
    26 条回复    2020-12-09 14:23:30 +08:00
    shikkoku
        1
    shikkoku  
       2020 年 12 月 6 日   1
    tplink 新型号基本已经支持 SLACC 和 RDNSS,马甲水星和 fast 仅特定新型号支持。腾达不太清楚,H3C 家用全部不支持。网件和 Linksys 支持度不佳。ASUS 的支持度比较高。360 仅部分型号支持,且支持度不佳(有 bug )。
    cpstar
        2
    cpstar  
       2020 年 12 月 6 日
    其实 V6 隐含着一个坑,以往的 v4 NAT,不做 NAT,外边基本上不知道里边是啥,但是 V6 没有 NAT,每个 IP 原则上直接全网暴露,于是防火墙必须设置完备
    wazon
        3
    wazon  
       2020 年 12 月 6 日
    我以前问过类似的问题可供参考: t/660812

    @cpstar 路由器防火墙即使全开威胁也没有 IPv4 那么大。SLAAC+隐私扩展生成的 IP 地址几乎无法被暴力扫描、只会被本地或主动访问的外部网站获知(含中间经过的 ISP ),再加上现代终端基本都有完备的防火墙,民用的安全性已经足够了。
    shikkoku
        4
    shikkoku  
       2020 年 12 月 6 日
    ipv6 的防火墙我都关掉的
    sasalemma
        5
    sasalemma  
       2020 年 12 月 6 日
    @wazon 实际上不是后缀的问题。对于 v6 来说,从路由的角度,wan 口和 lan 口必然是不同网段,所以就不管 wan 口那边的那个 v6 地址了。wan 口无论在 v4 还是 v6,wan 对于一般人来说都是“墙外”,看管很严格。

    lan 口这边的获取的前缀,其实可以自己搜集的,比如电信己拨号后的前 240e:1234:abcd:5678,至少在某个时间断,三段变化,第二段变化也不大,有的是时间的话,也是能扫描的,毕竟路由的 lan 口就是 240e:1234:abcd:5678:2276::1 管理地址,从自己的网段开始扫。

    而一般 lan 口这边,如果按照 v4 的思路,几乎是不防的。如果 web 服务是监听 0.0.0.0:80 和 :::80,爆破的可能性还是蛮高的,不过目前已知比如 ASUS,web 服务监听只有 ipv4,v6 没有监听,倒是开了 ssh+wan 口访问 ssh,ssh 就是监听 v4+v6 了,只开放 ssh 的 lan 口访问,ssh 就只监听 v4,所以实际大多数家用路由,大多也是没有准备好的。

    为什么想着单纯爆破内网一个机器,那么地址确实很难,爆破总开关不要啥有啥?
    elfive
        6
    elfive  
       2020 年 12 月 7 日 via iPhone
    @shikkoku #1 兄弟,网件都支持好多年了……
    noahzh
        7
    noahzh  
       2020 年 12 月 7 日
    不知道内网上 ipv6 有什么意义呀.
    cwbsw
        8
    cwbsw  
       2020 年 12 月 7 日
    @sasalemma 所以不要用::1 。各种固件习惯性的给 LAN 口配地址用::1,这是 IPv4 时代的惯性思维,存在安全隐患。
    sasalemma
        9
    sasalemma  
       2020 年 12 月 7 日
    @cwbsw 问题在于,按照 ipv4 的惯性思维,总要有一个“总设备”来分配前缀吧,然后从 isp 那边获得前缀,默认就是::1 为第一个总设备了。路由的 ip 地址竟然不是 SLAAC 一样,后缀为 MAC 生成。而非自己编译的固件,这个压根不存在修改的可能性。

    不过鉴于当前的一些 IPV6 应用不成熟,一些默认的配置倒是不经意就关了门的。ASUS 的 1900P,1750AC 一类固件,如上所说默认开启 ssh 的 wan 口访问,是会监听:::22,但是防火墙那边,v4 会开放 wan 的 22 端口到本机,V6 的墙默认还是禁止 WAN 所有连接入本机的,虽说 LAN 是公网,但逻辑线路上访问还是 internet--》 wan--》 lan 。

    所以像楼上说的,关闭 v6 墙,在这个还没重视的 v6 时代,要爆破总开关,关墙才是送人头的行为。
    cwbsw
        10
    cwbsw  
       2020 年 12 月 7 日
    @sasalemma 所以说这是写固件的人惯性思维啊,事实上并没有必须::1 的限制,OpenWrt 就可以自定义,EUI64 、random 都可以。另外 LAN 口也不是一定要配 GUA,内网访问用 ULA,甚至压根不配地址都可以的。
    sasalemma
        11
    sasalemma  
       2020 年 12 月 7 日
    @cwbsw 这个倒是,希望以后会有所改善,目前就只能自己改了。
    shikkoku
        12
    shikkoku  
       2020 年 12 月 7 日
    @elfive #6 我没说不支持啊,我说支持不佳而已。
    Kowloon
        13
    Kowloon  
       2020 年 12 月 7 日 via iPhone
    @cwbsw
    网关是 ::1 是一个问题,一个例子是天津联通 BAS 的配置是随意 Traceroute 一个 PD 的 ::/60 段内随意地址就会出来对方光猫或者路由器的地址,这个地址不但是 MAC 生成的,而且记下这个地址等地方下次重新拨号获取新地址,再次 Traceroute 就能出来新地址。我不知道这个算不算是没有效保护隐私,毕竟暴露了 MAC 地址也不是那么好。
    wazon
        14
    wazon  
       2020 年 12 月 8 日
    @sasalemma 你说的这种威胁情况仅限网关设备自身监听了对外开放端口吧?
    wazon
        15
    wazon  
       2020 年 12 月 8 日
    @sasalemma
    想了下,对于你所说这种无防火墙下网关自身陷落的风险,需要是其自身运行的高权限服务,且满足以下条件:
    1. 该服务监听了[::]且自身没有 IP 段的校验
    2. 该服务没有身份验证或者弱密码
    3. 该服务没有使用被运营商屏蔽的常用端口
    4. 网关自身 lan 方向的全球 IPv6 地址后缀为::1 而非 SLAAC (暂时不是很清楚是固件还是上游的原因,我自己的路由器 lan 和 wan 方向都是 EUI64 。网上搜了一下截图,两种情况都有看到)

    对于一般用户而言,高权限的服务就该就是路由器后台界面,其通常监听 IPv4 的 80 、不监听 IPv6,威胁不是很大。
    对于折腾路由器的用户而言,如果网关自身 lan 方向的 IPv6 后缀为::1 、运行有监听 IPv6 的高权限+弱设防服务,且端口没有被运营商拦截,那确实有一定的风险。不过这些用户一般也有能力配置 IPv6 的防火墙。


    @Kowloon 提出了一种从外部发现 SLAAC 地址网关设备的方法。这样的话运行在网关的高权限网络服务应该至少满足 有 v6 的内 /外部端口拦截、不监听 IPv6 、强身份验证 中的至少一个。

    至于内网的 SLAAC 设备,暂未发现明显的公网暴露风险。
    mrzx
        16
    mrzx  
       2020 年 12 月 8 日
    @cpstar nat 诞生之初不是为了安全,仅仅是为了解决 ipv4 地址不够用而设计的。所谓的地址防暴露等等只是附带效果。
    mrzx
        17
    mrzx  
       2020 年 12 月 8 日
    @cpstar 补充一点,我家里的路由器是 rb4011,内置防火墙,早开启 deny ipv6 all 了,我现在家里只要是支持 ipv6 的设备,都有一个唯一的公网 ipv6 地址。用的是阿里的 ipv6 dns
    mrzx
        18
    mrzx  
       2020 年 12 月 8 日
    @sasalemma 路由器上自带 ipv6 防火墙功能可以解决这些问题。。。。
    mrzx
        19
    mrzx  
       2020 年 12 月 8 日
    @sasalemma 我加路由器从来都是不开 web 的,因为未知的安全隐患谁也说不准(我手里还从别人那捞过来的深信服 ssl vpn 0day 漏洞一直没用,所以我不相信有绝对的安全)。。即使是我开启 telnet 和 ssh,也限定了 acl.
    只有家里的 vpn pool 和 lan 的地址可以 ssh 和 telnet 到路由器上
    sasalemma
        20
    sasalemma  
       2020 年 12 月 8 日
    @wazon

    ::1 问题只是思维惯性,相对于某些朋友说的 ipv6 公网地址繁多,扫描难的说法,不是说一定有风险。

    任何系统爆破都是基于 0day 或者弱密码,不安全或者不当设置导致的。

    比如 openwrt 官方固件中,默认情况下是,web 的 80 和 443 (启用的话)是监听于 0.0.0.0:80 / 0.0.0.0:443,V6 是监听 [::]:80 / [::]:443,只是一种思维惯性,或者说安全与易用是相对的,这么设置只是防止除了普通情况是用默认的 3 类地址 192.168.1.1 访问,本机 127.0.0.1 的访问,还有 wan 口访问,这样配置是方便使用,除非个人对这个有安全要求,否则有些服务都是监听全端口的。

    关于路由本身 LAN 口地址,用 ifconfig 能查到,实际上两个地址情况都是有的(个人实测):

    1.路由拨号,光猫桥接,广东电信,带 V4 公网,LAN 口 V6 地址为全球地址,"前缀::1",路由 ASUS AC1900P 。
    2.路由拨号,光猫桥接,广东移动,V4 内网,LAN 口 V6 地址为全球地址,EUI64,路由 ASUS AC1200P 。

    移动的 WAN 口 LAN 口网段 2409:abcd 是相同的。

    也可能是固件原因导致,但目前两地设备无法交换,所以没法测试。

    不过如你所说,无论哪个地址,一般常规的设备都会禁止连接自身,但这个可能只是 bug,因为这个在耍大牌的 asus 官方固件中,既然开启 ssh 的 WAN+LAN 访问,为什么就会监听[::]:22,但奇葩的是,v4 的墙,也就是 iptables 开了转发到自身,而 ip6tables,也就是 v6 的墙,并没有开启。爆破要 1.2.3 都满足才有可能,所以像移动,80,443 都封杀了,广州南沙电信带 v4 公网的 443 没有禁,禁了 80,内网 v4 的封了 v6 的 80,443.

    所以说这个只是存在隐患,如果用其他不开源固件的,又没有开放 ssh 进去,你实际上也不知道开了什么端口,比如一般的家用路由。

    ::1+莫名其妙的端口+关闭的 ipv6 墙,那是什么样子。另外像 openwrt 默认是不禁 ping 的,::1 只是更容易找到房门,怎么进屋,就看时效了。像 v4 公网的广东电信,47:55 强制断线一次,要是内网 v4,一周不换 v6 地址的那种。

    肖申克只是有足够的时间+压力。

    另外,我个人还是哪个观点,虽然逻辑上内网设备都获得的全球的 ipv6 地址,至少从逻辑链路上说,还是通过 LAN---》 WAN--》 internet 的,所以 ipv6 墙对于开放内网设备用的是 FORWARD =。= 就是俗称的转发!

    开墙就能避免很多不必要的隐患,仅此。

    如果是光猫拨号,实际上哪个 TR69 的同城网不是一个巨大无比的漏洞?
    sasalemma
        21
    sasalemma  
       2020 年 12 月 8 日
    @mrzx You are right !

    开墙保平安,现在的爆破,除了 0day 能由外爆破,基本都是都是由内连出的,哪怕是最简单无趣的墙,都保平安。

    由内就得靠主动防御了。

    我个人外网访问简单点就开 ssh+端口转发来设置 web 。

    安全易用相对矛盾的,只是反对为了省事关墙的行为,和探讨下 ::1 扫描问题。
    tankren
        22
    tankren  
       2020 年 12 月 8 日
    pfsense 啊 简单易用还实用
    cpstar
        23
    cpstar  
       2020 年 12 月 9 日
    安全的问题,是要这么理解的,对于两个高手,一边有盾(防火墙),一边有矛(攻击工具),那两方即便不对等,但都知道如何攻防。
    但是放在更广罗的大众,很有可能攻击的高手还在,可是防守的根本不知道可以有盾,所以相当于任人宰割了,所以,对于广罗大众,这是需要进行一个安全知识的普及的。
    咱们群里普遍都是前者,可以与高手对垒的,但要超脱自己,看到更大的风险,所以。
    至于技术问题,NAT 不为保护内网啊,开端口啊,从来都不是最关键的问题。
    ZRS
        24
    ZRS  
       2020 年 12 月 9 日 via iPhone
    目前让人满意支持 v6 的路由只有 mikrotik
    cwbsw
        25
    cwbsw  
       2020 年 12 月 9 日
    @ZRS
    比 OpenWrt 差太多了。
    不支持 IPv6 FastPath 。
    不支持 IPv6 Policy Routing 。
    不支持 SLAAC 上游。
    不支持 DHCP-v6 分发单个地址。
    cwbsw
        26
    cwbsw  
       2020 年 12 月 9 日
    内置命令还不支持解析 AAAA 记录,影响写 DDNS 脚本。
    关于     帮助文档     自助推广系统     博客     API     FAQ     Solana     901 人在线   最高记录 6679       Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 53ms UTC 19:48 PVG 03:48 LAX 12:48 JFK 15:48
    Do have faith in what you're doing.
    ubao msn snddm index pchome yahoo rakuten mypaper meadowduck bidyahoo youbao zxmzxm asda bnvcg cvbfg dfscv mmhjk xxddc yybgb zznbn ccubao uaitu acv GXCV ET GDG YH FG BCVB FJFH CBRE CBC GDG ET54 WRWR RWER WREW WRWER RWER SDG EW SF DSFSF fbbs ubao fhd dfg ewr dg df ewwr ewwr et ruyut utut dfg fgd gdfgt etg dfgt dfgd ert4 gd fgg wr 235 wer3 we vsdf sdf gdf ert xcv sdf rwer hfd dfg cvb rwf afb dfh jgh bmn lgh rty gfds cxv xcv xcs vdas fdf fgd cv sdf tert sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf shasha9178 shasha9178 shasha9178 shasha9178 shasha9178 liflif2 liflif2 liflif2 liflif2 liflif2 liblib3 liblib3 liblib3 liblib3 liblib3 zhazha444 zhazha444 zhazha444 zhazha444 zhazha444 dende5 dende denden denden2 denden21 fenfen9 fenf619 fen619 fenfe9 fe619 sdf sdf sdf sdf sdf zhazh90 zhazh0 zhaa50 zha90 zh590 zho zhoz zhozh zhozho zhozho2 lislis lls95 lili95 lils5 liss9 sdf0ty987 sdft876 sdft9876 sdf09876 sd0t9876 sdf0ty98 sdf0976 sdf0ty986 sdf0ty96 sdf0t76 sdf0876 df0ty98 sf0t876 sd0ty76 sdy76 sdf76 sdf0t76 sdf0ty9 sdf0ty98 sdf0ty987 sdf0ty98 sdf6676 sdf876 sd876 sd876 sdf6 sdf6 sdf9876 sdf0t sdf06 sdf0ty9776 sdf0ty9776 sdf0ty76 sdf8876 sdf0t sd6 sdf06 s688876 sd688 sdf86