V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
akrislu
V2EX  ›  宽带症候群

电信移动的 QOS 级别

  •  
  •   akrislu · 2017-02-17 09:59:41 +08:00 · 8865 次点击
    这是一个创建于 2596 天前的主题,其中的信息可能已经有所发展或是发生改变。
    网络环境:
    本地:移动企业专线宽带,公网 IP 走互联互通
    对端:澳洲电信
    模式: CISCO SVTI 隧道 IPSEC 加密。
    路由状况:经广州入香港对接澳洲电信 Peer.
    症状:
    昨天移动广州出口炸的时候,我这边移动线路上直 PING 澳洲公网 IP 延时正常,完全不丢包(和移动本地技术专家确认过,企业专线 QOS 等级为 5 算比较高的),但是在 SVTI 通道上 ping 对端通道内网地址 丢包率 20%。今天广州出口恢复的时候 再次测试,已经恢复正常。

    问题: 有没有大神知道,为什么 SVTI 通道上会丢包,是不是 IPSEC 加密后的数据在运营商那边 QOS 等级很低的原因。 因为不光是移动,前一段时间在电信线路上也发现 GRE 隧道 加上 IPSEC 保护后 立马就丢包。
    21 条回复    2021-02-14 10:40:08 +08:00
    kennylam777
        1
    kennylam777  
       2017-02-17 10:05:01 +08:00
    樓主第一天在中國? 還敢用公網來搭 VPN 連到外國去,還是企業用的通道......
    yadiman
        2
    yadiman  
       2017-02-17 10:14:34 +08:00 via iPhone
    企业内网用 vpn 非常合理正常的。
    估计移动给了你假的 qos ,只优化了 icmp 吧。第三层的通信有问题,露馅了。
    yexm0
        3
    yexm0  
       2017-02-17 10:20:20 +08:00 via Android
    申请条 mpls 线路吧。
    jasontse
        4
    jasontse  
       2017-02-17 10:24:13 +08:00 via iPad
    ipsec 协议不同走的路由可能不一样, tcp / udp 可能都不同,你 ping 出来的 icmp 也许没有参考价值。
    akrislu
        5
    akrislu  
    OP
       2017-02-17 10:38:02 +08:00
    @kennylam777
    @yadiman
    @yexm0
    @jasontse
    企业公网上搭建 VPN 很正常啊,因为 MPLS 太贵了,很多企业都这样做,不是 FQ 用的,也一直都比较稳定的,移动这条线路只是备用线路,主要业务还是在联通的精品网上跑。昨天移动炸时正好测试了一下,结合以前在电信 163 网上跑 GRE OVER IPSEC 的时候也丢包,突然联想到是不是 QOS 了 IPSEC 的原因。
    z5864703
        6
    z5864703  
       2017-02-17 10:50:29 +08:00
    @kennylam777 VPN 主要又不是用来翻墙的,本来是内部加密通讯用的
    kennylam777
        7
    kennylam777  
       2017-02-17 18:31:57 +08:00
    @yadiman
    @z5864703
    @akrislu

    VPN 的原意是這樣,但偉大的國家安全裝置就是會來干擾啊.....都加密了哪會分你是否企業用的,也不管你有否 FQ ,一律干擾。

    我以前住深圳,只要是到外國的通訊一律受干擾,如果是 IPSec 還是公開的 VPN 標準,特徵明顯,連到外國去必死無疑,國內就沒有問題。

    真的要穩定不受國家級干擾,只有 MPLS 專線。
    kennylam777
        8
    kennylam777  
       2017-02-17 18:38:28 +08:00   ❤️ 1
    申報一下,我公司的 VPN

    香港總部
    連到新加坡用 IPSec/OpenVPN 都穩定
    連到中國大陸, OpenVPN (Static key+UDP)用幾分鐘就斷掉, IPSec 用一個星期左右會 packet loss ,掛過阿里雲香港 B 區走 CN2 如是,最後把不重要的流量拆出,重要的東東走 MPLS 。
    JackyBao
        9
    JackyBao  
       2017-02-17 21:26:30 +08:00 via iPad
    你们有试过用 kcptun 承载 openvpn 吗? 2 个字,完美!
    akrislu
        10
    akrislu  
    OP
       2017-02-17 21:54:49 +08:00 via iPhone
    @kennylam777 我们倒是还可以 IPSEC VPN 到美国和澳洲应该说都是稳定的,一年拥塞个 2 到 3 次 每次半个到 1 个小时。最多切换到备用线路就可以了。一开始我也认为是功夫网干扰,但是很明显是大家丢包的时候我才丢包,线路畅通的时候我也没问题啊。
    bclerdx
        11
    bclerdx  
       2017-02-17 23:54:36 +08:00
    @akrislu 现在的企业在公网上跑 VPN ,用哪个协议? PPTP ?
    z991238
        12
    z991238  
       2017-02-18 04:45:07 +08:00
    @bclerdx L2TP+IPSEC 吧。 PPTP 不安全都
    akrislu
        13
    akrislu  
    OP
       2017-02-18 11:00:57 +08:00 via iPhone
    @bclerdx S2S 一般 IPSEC VPN 。 L2L 么一般 GRE TUNNEL 。移动接入 PPTP 或者 L2TP+IPSEC
    VmuTargh
        14
    VmuTargh  
       2017-02-18 11:39:18 +08:00
    @kennylam777 TCP ,移动建议不要用 UDP
    某认识的 JP 驻国内公司大佬,他们 anyconnect 都是 TCP …… UDP 在国内这个差劲的网络环境是很不可靠的
    bclerdx
        15
    bclerdx  
       2017-02-19 00:30:06 +08:00
    @VmuTargh 怎么才能 TCP 协议?
    akw2312
        16
    akw2312  
       2017-02-19 03:00:11 +08:00
    @bclerdx TCP 類的 VPN 很多啊.. SSTP, AnyConnect 也有 TCP 模式
    bclerdx
        17
    bclerdx  
       2017-02-24 11:17:29 +08:00
    @akw2312 请教一下,用什么测试方法测试当前使用的 PPTP/L2TP 是支持 TCP 协议的?
    bclerdx
        18
    bclerdx  
       2018-08-07 20:59:09 +08:00
    @yadiman 第三层是啥?
    akrislu
        19
    akrislu  
    OP
       2019-12-15 19:13:16 +08:00 via iPhone
    @bclerdx 传输层啊
    bclerdx
        20
    bclerdx  
       2019-12-15 20:08:22 +08:00
    @akrislu 你是说 OSI 中的第三层?
    freemangl
        21
    freemangl  
       2021-02-14 10:40:08 +08:00
    LZ 有没有试过 ipsec over gre 会不会好一些?
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   1063 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 27ms · UTC 19:13 · PVG 03:13 · LAX 12:13 · JFK 15:13
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.