V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
gonbo
V2EX  ›  程序员

VPN跑了480M流量681K个包,竟然收到GFW的RST包957K,VPN发一个包,GFW回来1.4个reset包。GFW也太狠了。

  •  
  •   gonbo · 2013-01-24 13:55:59 +08:00 · 4617 次点击
    这是一个创建于 4350 天前的主题,其中的信息可能已经有所发展或是发生改变。
    957/681=1.4 回来1.4个包。
    Chain INPUT (policy ACCEPT 681K packets, 480M bytes)
    pkts bytes target prot opt in out source destination
    957K 38M DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x2F/0x04
    25 条回复    2015-02-24 12:35:21 +08:00
    gonbo
        1
    gonbo  
    OP
       2013-01-24 14:00:42 +08:00   ❤️ 1
    @unwiredkite 上面哪个主题计算有错误。理论上的确有可能,只要大家都发包,引发GFW回来RST包。
    gonbo
        2
    gonbo  
    OP
       2013-01-24 14:05:09 +08:00
    @BOYPT 应该是有可能的,研究一下他发包机制,让他大量的发包,cpu跑满100%,正常翻墙的链接就不会被强奸。
    chenshaoju
        3
    chenshaoju  
       2013-01-24 14:10:26 +08:00
    @gonbo 不太可能的,你一台机器不可能和TBit级的设备对抗。
    而且Wa11有多个节点,就算你搞垮了一个,其他出口一切正常。
    BOYPT
        4
    BOYPT  
       2013-01-24 14:11:30 +08:00
    @gonbo 现在的高性能网络设备数据包根本就不用过CPU的好么~
    gonbo
        5
    gonbo  
    OP
       2013-01-24 14:13:34 +08:00
    @chenshaoju 我觉得这个是一个正确思路。dns污染完全可以搞死。
    gonbo
        6
    gonbo  
    OP
       2013-01-24 14:14:26 +08:00
    @BOYPT 这种需要计算的封禁肯定是cpu的。
    BOYPT
        7
    BOYPT  
       2013-01-24 14:15:03 +08:00
    而且你收到这么多个RST不是因为人家故意发给你那么多个,是因为同时触发了多个节点,有时候有些节点忙别的就不发给你了,

    GFW的这个模式是个完美的 flexible extensive module
    BOYPT
        8
    BOYPT  
       2013-01-24 14:17:30 +08:00
    @gonbo 肯定不是。
    SAGAN
        9
    SAGAN  
       2013-01-24 14:19:05 +08:00
    很奇怪LZ一直这样drop rst还能继续使用VPN,rst发到一定程度应该就直接封ip了
    ShadowStar
        10
    ShadowStar  
       2013-01-24 14:19:08 +08:00
    @gonbo CPU计算量很小。特征匹配、校验和都是硬件完成。
    zeeler
        11
    zeeler  
       2013-01-24 14:19:51 +08:00
    你要想完美就搞个国外的卫星通道,架个小锅,就不受GFW约束了
    gonbo
        12
    gonbo  
    OP
       2013-01-24 14:25:14 +08:00
    @zeeler 延迟比较大呀。
    gonbo
        13
    gonbo  
    OP
       2013-01-24 14:26:55 +08:00
    @BOYPT
    @ShadowStar 我觉得他们做基于流量特征的分析,肯定需要大规模计算量的。

    @SAGAN 把两边把RST都drop了,所以能够用VPN,不过速度很慢。
    ShadowStar
        14
    ShadowStar  
       2013-01-24 14:30:54 +08:00
    @gonbo 特征分析一般是在后端服务器群做,前端接入设备简单高效。
    BOYPT
        15
    BOYPT  
       2013-01-24 14:48:11 +08:00
    @ShadowStar Openvpn的TLS握手特征那种就扔后端做,所以一般改端口后有几个小时能用的;

    关键字触发RST这种机制即时性高,完全就硬件级别识别的了。cisco的流处理单元但是很牛x的。
    dndx
        16
    dndx  
       2013-01-24 14:50:15 +08:00
    @gonbo 以 GJ 雄厚的财力,一秒 TB 级别的 RST 包根本就没感觉。

    如果真要这样 DDOS ,估计 GFW 不倒国际出口先被搞挂了。GFW 用的都是曙光超级计算集群,流量分析还不是小 Case 。如果容量不够了尽管加机器,看谁能撑得住。
    jackyz
        17
    jackyz  
       2013-01-24 15:16:14 +08:00
    @gonbo 现在是两边都 drop reset 所以还能连上,要是它能自动升级为封 ip 呢,还能通讯么?

    另外,这是个什么状况?有点不大理解。按常规,墙完全可以弄个小脚本来自动地跑,一旦超过某个值,就触发程序来封你服务器的 ip 不就完了嘛,为啥没这么做?还是说你又做了什么反制手段,让它停留在 reset 的级别,所以还能跑?

    感觉 DDOS 是主动碰线,不如想什么办法,悄悄地进村,碰线地不要。
    ShadowStar
        18
    ShadowStar  
       2013-01-24 15:17:10 +08:00
    @BOYPT 基本是这样的,现在的设备除了通常的黑白名单外,还会有灰名单,对于不确定的流量丢到后端做(行为、特征)分析学习,然后将生成的特征下发到前端设备,后续的相同流量就前端直接处理了。
    ShadowStar
        19
    ShadowStar  
       2013-01-24 15:18:36 +08:00
    想把GFW弄死,理论上可以,实际操作起来基本不可能。
    treo
        20
    treo  
       2013-01-24 19:04:22 +08:00
    @jackyz 可能是因为旁路上没法封IP,主干路由上封IP不是说封就封的,路由表多了会影响转发速度,只有极少数IP享受这种待遇
    ShadowStar
        21
    ShadowStar  
       2013-01-24 19:23:05 +08:00
    @treo 封IP和路由没关系。通常手段只有2种:串接阻断和旁路RST。从整体可靠性上来看,一般都比较保守的采用旁路方式。
    enj0y
        22
    enj0y  
       2013-01-24 19:48:04 +08:00
    你这是在与GM开玩笑
    gonbo
        23
    gonbo  
    OP
       2013-01-24 19:57:06 +08:00
    @enj0y 有足够多的带宽,的确可以这样做呀。
    chenshaoju
        24
    chenshaoju  
       2013-01-24 22:58:42 +08:00   ❤️ 1
    很早以前我做过测试,当时的环境是如果连续触发墙,那么一段时间墙就不发送RST了,更早以前就直接在国际出口处断开你的国际互联网连接,注意,是彻底断开,你的整个国际出口就没有了。

    如果要说墙的负载,是的,墙的确有负载,去年什么时候墙封掉了整个 *.co.jp 域名,结果洪水一样的请求的确淹没了墙(猜测是国内的图片/JS引用,证券或商业交易等),RST延迟骤升: http://twitpic.com/9x2sph

    真想淹没墙?等 *.com 域名被墙掉了再说。
    mikangchan
        25
    mikangchan  
       2015-02-24 12:35:21 +08:00
    @gonbo 有足够多的带宽做这个就会有行政/刑事人员找你了(有关部门
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   878 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 32ms · UTC 21:46 · PVG 05:46 · LAX 13:46 · JFK 16:46
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.