V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
请不要把任何和邀请码有关的内容发到 NAS 节点。

邀请码相关的内容请使用 /go/in 节点。

如果没有发送到 /go/in,那么会被移动到 /go/pointless 同时账号会被降权。如果持续触发这样的移动,会导致账号被禁用。
Junzhou
V2EX  ›  NAS

群晖 NAS 有异常的网络发送,数据量巨大,暂时未定位到原因。

  •  1
     
  •   Junzhou · 2021-07-25 17:09:20 +08:00 · 5670 次点击
    这是一个创建于 1249 天前的主题,其中的信息可能已经有所发展或是发生改变。

    设备信息

    型号 DS220+,DSM7.0,两根网线,LAN1 LAN2

    具体情况

    每个小时的第 15 分钟开始到第 25 分钟之间,LAN1 和 LAN2 交替以 2MB/s ( 16Mbps )的速度向外发送数据,10 分钟发送了大约 1.2G 的数据,实在想不明白到底什么服务需要对外发送这么大量的数据。

    下图是监控数据。

    已排除的可能

    1. FRP,frp 的相关穿透配置仅限于 LAN1 的地址,未对 LAN2 的地址有任何穿透转发。看发送情况是 LAN1 和 LAN2 交替发送。

    2. OneDrive 的同步,没有这么大的同步量,这几个周期发送了好几十 G 的数据了,OneDrive 同步任务可以排除。

    3. 相关 Docker 容器的网络发送,只有 FRP 容器两个。qinglong 容器一个。

    4. Synology Active Insight,这玩意定期上产系统的运行信息,按理说不可能发送这么巨大的流量。

    其他问题

    DSM7.0 Universal Search 应用点击 检查索引数据库,会一直检查,导致 CPU 在数天内持续占用 50%左右,手动取消后占用恢复正常。

    我使用 iftop 未定位到原因。各位有什么排查策略吗?

    第 1 条附言  ·  2021-07-26 10:04:21 +08:00

    更新一下,找到问题了是MacBook时间机器备份的问题,虽然不太清楚为什么时间机器开始备份前NAS会向MacBook持续发送那么多数据。

    根据老哥们的建议,没有抓包,使用docker起了个iftop容器,挂到了host网络,查看eth0的所有网络情况。

    1. 整点10分的时候,发现NAS起了一个445端口,持续向内网的某台机器发送数据。大约10-18Mbps的速率。
    └──────────────────────────┴──────────────────────────┴───────────────────────────┴──────────────────────────┴───────────────────────────
    192.168.0.108:445                                      => 192.168.0.104:59429                                     12.1Mb  7.28Mb  6.51Mb
                                                           <=                                                         30.6Mb  16.2Mb  14.2Mb
    
    1. 定位端口445为smb端口
    ash-4.4# netstat -pantu | grep 445
    tcp        0      0 0.0.0.0:445             0.0.0.0:*               LISTEN      9877/smbd           
    tcp        0   4180 192.168.0.108:445       192.168.0.104:59429     ESTABLISHED 19533/smbd          
    tcp        0      0 192.168.0.105:445       192.168.0.104:61335     ESTABLISHED 5952/smbd           
    tcp6       0      0 :::445   
    
    1. 查看MacBook的时光机器,发现每小时的定时备份的开始时间为整点第10分钟开始。
    第 2 条附言  ·  2021-07-26 10:04:25 +08:00

    更新一下,找到问题了是MacBook时间机器备份的问题,虽然不太清楚为什么时间机器开始备份前NAS会向MacBook持续发送那么多数据。

    根据老哥们的建议,没有抓包,使用docker起了个iftop容器,挂到了host网络,查看eth0的所有网络情况。

    1. 整点10分的时候,发现NAS起了一个445端口,持续向内网的某台机器发送数据。大约10-18Mbps的速率。
    └──────────────────────────┴──────────────────────────┴───────────────────────────┴──────────────────────────┴───────────────────────────
    192.168.0.108:445                                      => 192.168.0.104:59429                                     12.1Mb  7.28Mb  6.51Mb
                                                           <=                                                         30.6Mb  16.2Mb  14.2Mb
    
    1. 定位端口445为smb端口
    ash-4.4# netstat -pantu | grep 445
    tcp        0      0 0.0.0.0:445             0.0.0.0:*               LISTEN      9877/smbd           
    tcp        0   4180 192.168.0.108:445       192.168.0.104:59429     ESTABLISHED 19533/smbd          
    tcp        0      0 192.168.0.105:445       192.168.0.104:61335     ESTABLISHED 5952/smbd           
    tcp6       0      0 :::445   
    
    1. 查看MacBook的时光机器,发现每小时的定时备份的开始时间为整点第10分钟开始。
    33 条回复    2021-07-27 11:17:23 +08:00
    xtx
        1
    xtx  
       2021-07-25 17:28:34 +08:00 via iPhone
    lan1,lan2 分别连的什么?
    Junzhou
        2
    Junzhou  
    OP
       2021-07-25 17:32:11 +08:00
    @xtx 室内的路由器,同一个路由器。
    sutking
        3
    sutking  
       2021-07-25 17:35:07 +08:00
    排除法,先排除硬件,拔一根网线留一根,看情况,然后再把另外一根插上,拔掉之前没拔的那一根,看情况;然后软件,把服务、进程挨个停掉,观察。
    wtks1
        4
    wtks1  
       2021-07-25 17:38:38 +08:00 via Android
    是不是装了迅雷相关的软件?
    SaberJack
        5
    SaberJack  
       2021-07-25 17:39:57 +08:00
    能通过上级路由器看下流量包不 能的话就可以分析出来了
    Junzhou
        6
    Junzhou  
    OP
       2021-07-25 17:41:48 +08:00
    @wtks1 没有万物下载,迅雷等相关的 bt pt 工具,没有做种,已经排除。
    @sutking lan2 没有的话,会一直通过 lan1 发送数据。这个排除法太耗时了,试图起了一个 netdata 来监控网络情况,效果不尽人意。现在考虑抓包看看流量到底发到哪里。
    wangkai0351
        7
    wangkai0351  
       2021-07-25 17:46:36 +08:00
    不知道群晖现在安全性做的如何,注意排查
    Junzhou
        8
    Junzhou  
    OP
       2021-07-25 17:54:21 +08:00
    @SaberJack 在等下个发送周期。
    ByteCat
        9
    ByteCat  
       2021-07-25 18:18:37 +08:00
    从路由器里面看不行吗,我用的高恪都可以看到数据流向
    Junzhou
        10
    Junzhou  
    OP
       2021-07-25 18:20:09 +08:00
    @ByteCat 不行,桥接的自如的路由器,我的路由是老路由器,看不到数据流向,只能在路由器上抓包。
    512357301
        11
    512357301  
       2021-07-25 18:28:51 +08:00 via Android   ❤️ 1
    有个笨办法,换端口,并且只限制某几个端口可以连外网,类似于 vps 的安全组。
    我之前在 aws 搭的 win10 就出现过这种情况,怀疑是被当成肉鸡了,后来在安全组限制入站端口后,瞬间风平浪静,(不过最终也不确定是什么原因导致的,也可能是 win10 自动更新的锅)
    aws ec2 每月限制 15G 的进和出流量,我当时竟然能跑满。。。,限制端口后,每个月顶天了 8 个 G
    mmlmml1
        12
    mmlmml1  
       2021-07-25 18:38:18 +08:00   ❤️ 1
    在 NAS 上运行 tcpdump 试试看?实在不行可以尝试直接做一根抓包网线,参考 /t/352400
    gBurnX
        13
    gBurnX  
       2021-07-25 19:02:02 +08:00   ❤️ 2
    上面都在答些啥。

    iptraf -> netstat 找到进程。
    SZP1206
        14
    SZP1206  
       2021-07-25 19:03:00 +08:00 via Android
    有点好奇,期待下后续
    matrix67
        15
    matrix67  
       2021-07-25 21:39:45 +08:00   ❤️ 1
    可以使用 tcptrack

    tcptrack -i eth0 。 直接定位出那个端口,以及连的 ip+port 实时速率。

    或者使用 nethogs 。不过这个好像是看瞬时值的。要在你抓到流量大的时候启动它,把相关进程打出来。
    matrix67
        16
    matrix67  
       2021-07-25 21:42:09 +08:00   ❤️ 1
    或者 tcpdump -s 80 就采样 dump 一下包,然后丢到 wireshark 里面看那个 ip+端口占的数据最多。

    楼上说的 iptraf 也是一条路子。
    darkaforest
        17
    darkaforest  
       2021-07-25 21:51:20 +08:00   ❤️ 1
    直接 tcpdump 出来用 wireshark 看看不就一目了然了吗,建议敏感数据直接脱离物理网络存储,最好再加上物理防护措施。 如果觉得不值得这么干,那说明其实也没多敏感,随便它偷着往外传啥吧。
    ly841000
        18
    ly841000  
       2021-07-25 22:14:59 +08:00
    大家都好友善,国内厂商的话不被骂上天?!!!!!!
    PrinceofInj
        19
    PrinceofInj  
       2021-07-25 22:34:26 +08:00   ❤️ 1
    @ly841000 两大 NAS 厂家都是台企,如果用来存储敏感数据,最好还是做好防范。
    geniussoft
        20
    geniussoft  
       2021-07-25 22:39:30 +08:00
    @ly841000 群晖算是非常有操守的企业了,相对来说。
    这边 FRP 、OneDrive 都开着,就认为一定是群晖的锅,这个推测不合理吧。
    vmebeh
        21
    vmebeh  
       2021-07-25 23:43:38 +08:00 via iPhone
    台积电、Nvidia 也是台企,你用的 CPU 、GPU 自带后门!!!!! 🐶
    wangkai0351
        22
    wangkai0351  
       2021-07-26 09:14:06 +08:00
    @vmebeh 要是这么较真,万物皆带后门,台积电、Nvidia 敢反驳这句话吗?
    yesfirst
        23
    yesfirst  
       2021-07-26 09:21:44 +08:00
    这个监控数据在哪里可以看? 我是 dsm6 没找到么
    Junzhou
        24
    Junzhou  
    OP
       2021-07-26 10:05:30 +08:00   ❤️ 1
    @SZP1206 更新一下,找到问题了是 MacBook 时间机器备份的问题,虽然不太清楚为什么时间机器开始备份前 NAS 会向 MacBook 持续发送那么多数据。

    根据老哥们的建议,没有抓包,使用 docker 起了个 iftop 容器,挂到了 host 网络,查看 eth0 的所有网络情况。

    整点 10 分的时候,发现 NAS 起了一个 445 端口,持续向内网的某台机器发送数据。大约 10-18Mbps 的速率。
    └──────────────────────────┴──────────────────────────┴───────────────────────────┴──────────────────────────┴───────────────────────────
    192.168.0.108:445 => 192.168.0.104:59429 12.1Mb 7.28Mb 6.51Mb
    <= 30.6Mb 16.2Mb 14.2Mb
    定位端口 445 为 smb 端口
    ash-4.4# netstat -pantu | grep 445
    tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN 9877/smbd
    tcp 0 4180 192.168.0.108:445 192.168.0.104:59429 ESTABLISHED 19533/smbd
    tcp 0 0 192.168.0.105:445 192.168.0.104:61335 ESTABLISHED 5952/smbd
    tcp6 0 0 :::445
    查看 MacBook 的时光机器,发现每小时的定时备份的开始时间为整点第 10 分钟开始。
    Junzhou
        25
    Junzhou  
    OP
       2021-07-26 10:05:50 +08:00
    @yesfirst dsm7 的监控
    Ravencus
        26
    Ravencus  
       2021-07-26 10:23:38 +08:00
    好像不止是开始备份前。time machine 备份的过程中 mac 上也会有间歇性的流量下行。
    littlewing
        27
    littlewing  
       2021-07-26 11:52:55 +08:00
    从你的描述中我一直以为是向外网发送流量。。。。
    Junzhou
        28
    Junzhou  
    OP
       2021-07-26 12:59:56 +08:00
    @littlewing 最开始也没有确认流向。。。
    tankren
        29
    tankren  
       2021-07-26 13:27:43 +08:00
    shell 里面看看 top 呢
    smileawei
        30
    smileawei  
       2021-07-26 14:25:35 +08:00
    看看是不是装了迅雷系列的下载工具。之前有装过“玩物下载” 。然后就发现上传不正常
    lifanxi
        31
    lifanxi  
       2021-07-26 23:33:57 +08:00 via Android
    @Junzhou 用 Docker 跑 iftop 好机智。还有个更原生的玩法,sudo synogear install,有惊喜。
    Junzhou
        32
    Junzhou  
    OP
       2021-07-27 11:16:52 +08:00
    操 还能这样啊 一会试试
    Junzhou
        33
    Junzhou  
    OP
       2021-07-27 11:17:23 +08:00
    @lifanxi 我草 还能这样啊 一会试试
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1105 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 79ms · UTC 18:54 · PVG 02:54 · LAX 10:54 · JFK 13:54
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.