USTC LUG VPN海外线路怎么优化的

Ding ZhiGang

unread,

Nov 15, 2014, 11:10:10 AM11/15/14

to ustc...@googlegroups.com

我自己买了个DigitalOcean的VPS，搭了VPN，但发现海外网站的访问速度和用LUG VPN有明显的差距。。。

想问问boj，LUG VPN是做了什么特殊优化的吗？为啥同样的DO速度差距却很大？有什么秘诀的？

---------
Ding ZhiGang

Allan Lu

unread,

Nov 15, 2014, 11:16:03 AM11/15/14

to ustc...@googlegroups.com

国内接入点+国外VPS做出口

Soli Deo gloria.

Allan Lu
Email: al...@ream.at
梦.:如此短暂: http://d.ream.at

--
-- 来自USTC LUG
请使用gmail订阅，不要灌水。
更多信息more info：http://groups.google.com/group/ustc_lug?hl=en?hl=en
---
You received this message because you are subscribed to the Google Groups "USTC_LUG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ustc_lug+u...@googlegroups.com.
To post to this group, send email to ustc...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Yuxiao Wu

unread,

Nov 15, 2014, 11:24:24 AM11/15/14

to ustc_lug

digitalocean开新加坡节点的很快啊

------------------ 原始邮件 ------------------

发件人: "Allan Lu"<al...@ream.at>

发送时间: 2014年11月16日(星期天) 凌晨0:15

收件人: "ustc_lug"<ustc...@googlegroups.com>;

主题: Re: [USTC-LUG] USTC LUG VPN海外线路怎么优化的

Ding ZhiGang

unread,

Nov 15, 2014, 8:52:19 PM11/15/14

to ustc...@googlegroups.com

上海电信ADSL，测试下来新加坡的连接速度很不稳定，所以当时选了US的机房

---------

Ding ZhiGang

Hugo

unread,

Nov 30, 2014, 7:31:27 AM11/30/14

to ustc...@googlegroups.com

虽然挖坟了，但我特别想问一下，国内到国外 VPS 这段怎么走的，这么长时间都不会被X？ vpn over Shadowsocks 可行么？

发件人: ustc...@googlegroups.com [mailto:ustc...@googlegroups.com] 代表 Ding ZhiGang
发送时间: 2014年11月16日 9:52
收件人: ustc...@googlegroups.com
主题: Re: 回复： [USTC-LUG] USTC LUG VPN海外线路怎么优化的

Zhang Cheng

unread,

Nov 30, 2014, 7:49:37 AM11/30/14

to USTC LUG

综合在网上看到的各种大家的经验分享，选择方法时应该避免这些坑：

* 大多数常用的翻墙方法都不可靠，能够（在win下）一键安装或者稍有些能力就能方便实施的翻墙方案（比如各种常见的VPN），都不稳定，随时有可能被堵。

* 明显的加密流量，比如ssh、https等，gfw会进行流量特征的分析，如果与浏览网页的流量特征很像，那么很容易被封（比如scp传文件连续传一天可能都没问题，但ssh开socks代理上网则很容易被封）。

* 目前为止发现，gfw主要干扰的是tcp的通信，udp可能仅对某些协议进行干扰（比如openvpn、dns），其他与tcp/udp平级的协议似乎都不干扰，比如icmp、ipip、gre等。

结合上面的分析，可以有以下思路：

* 尽量避免使用Win下能够容易实现的翻墙方法，比如各种常见的vpn

* 要表现的不像加密流量。比如obfsproxy，他会对tcp流量进行混淆，使之看起来不像加密的内容，从而gfw会用敏感词的方式过滤，而不是对加密流量那种粗暴的封杀。科大LUG曾经使用过tun2socks over ssh over obfsproxy的方案，一直很稳定。

* 使用tcp/udp以外的协议，比如ipip，gre或者自定义协议（我不清楚自定义协议是否需要中间路由设备的支持）。现在LUG使用gre tunnel。ipip/gre这类隧道协议，需要两端都有公网ip，这使得实施难度大大增加（许多个人PC都在局域网里面，没有公网IP，要实施通常得在路由器上搞），同时Win下还未出现方便的工具可以快捷的创建隧道实现翻墙，所以短时间内可以认为这是比较安全的方法。

关于LUG vpn使用的技术以及故障情况，可以看这里：https://servers.ustclug.org/category/vpn/

Cheng,

Best Regards

Yan Wang

unread,

Nov 30, 2014, 9:08:48 AM11/30/14

to ustc...@googlegroups.com

[OT] (sorry no Chinese input here).

Saw this post asking for donation to LUG VPN: https://servers.ustclug.org/2014/11/register-digitalocean-and-donate-lug-vpn/

Actually I have quite some AWS credit (as a reward from some programming challenge), expiring 2015/08. Do you guys need EC2 VPS (to 2015/08)?

Hugo

unread,

Nov 30, 2014, 9:31:40 AM11/30/14

to ustc...@googlegroups.com

谢谢！实践了一下 openvpn over obfsproxy over greTunnel 连接上了没问题，就是延迟比较大。。。难道是纽约机房的问题。。。

发件人: ustc...@googlegroups.com [mailto:ustc...@googlegroups.com] 代表 Zhang Cheng
发送时间: 2014年11月30日 20:50
收件人: USTC LUG
主题: Re: 答复: 回复： [USTC-LUG] USTC LUG VPN海外线路怎么优化的

Zhang Cheng

unread,

Nov 30, 2014, 9:42:32 AM11/30/14

to USTC LUG

2014-11-30 22:31 GMT+08:00 Hugo <hu...@fireuponsky.com>:

谢谢！实践了一下 openvpn over obfsproxy over greTunnel 连接上了没问题，就是延迟比较大。。。难道是纽约机房的问题。。。

可以仅仅 openvpn over obfsproxy 或者单独使用gre，gre目前看来是安全的，obfsproxy目前看来也是安全的，两者不需要结合起来用。

延迟着一块，国内电信、联通出国延迟都比较高，移动出国延迟比较好，但是不太稳定。lug主要使用移动线路出国。

--

Cheng,

Best Regards

Zhuoyun Wei

unread,

Dec 1, 2014, 4:32:27 AM12/1/14

to ustc...@googlegroups.com

2014-11-30 20:49 GMT+08:00 Zhang Cheng <steph...@gmail.com>:
> * 使用tcp/udp以外的协议，比如ipip，gre或者自定义协议（我不清楚自定义协议是否需要中间路由设备的支持）。现在LUG使用gre
> tunnel。ipip/gre这类隧道协议，需要两端都有公网ip，这使得实施难度大大增加（许多个人PC都在局域网里面，没有公网IP，要实施通常得在路由器上搞），同时Win下还未出现方便的工具可以快捷的创建隧道实现翻墙，所以短时间内可以认为这是比较安全的方法。

IPIP 和 GRE 这两个协议开销很小，用来翻墙非常合适。我在学校宿舍有线上网直接拿到的是公网 IP
地址，可以直接用。在家的话，家里路由器得开了 DMZ
之后才能用。不过每次重新拨号还要更新对端地址，比较麻烦。再加上这两个隧道协议本身并不加密让我强迫症发作，所以我最终没有作用日常翻墙手段。

这两个隧道协议倒是更适合中转式翻墙方案，比如像 LUG VPN 这样的，国内外各有一个固定的公网 IP 地址，这两个 Linux
主机之间建立隧道之后，客户机们连接到国内的 Linux 机器上实现翻墙。

我的一个朋友是一家创业公司的系统管理员，他需要负责全公司员工的翻墙问题。公司的网关是有固定 IP 地址的，在我的推荐下，他把 IPIP 和
GRE 部署在了公司的网关上（其实就是一台 Linux 服务器），直接连到国外的 VPS
上建立隧道。很舒爽地用了一段时间。然后……这两个协议因为流量太大先后被 ISP 给封了（不是被 GFW）……

现在他改用香港专线了，比较贵，但是用来公司级翻墙倒是效果很好，不用再担心 ISP 捣乱了。

说到这种 Linux 用起来很方便，Windows 用起来很麻烦的翻墙方式的话。Linux 3.2+ 还有一个，最大的优势是原生支持
NAT： https://gist.github.com/klzgrad/5661b64596d003f61980

我个人更期待的是 Linux 3.18 的 Foo over UDP 功能。

--
Zhuoyun Wei

Allan Lu

unread,

Dec 1, 2014, 4:36:24 AM12/1/14

to ustc...@googlegroups.com

这是什么ISP？PPTP的流量也要走GRE的，怎么可以随便乱封？

Allan Lu

Zhuoyun Wei

unread,

Dec 1, 2014, 4:49:48 AM12/1/14

to ustc...@googlegroups.com

2014-12-01 17:36 GMT+08:00 Allan Lu <al...@ream.at>:
> 这是什么ISP？PPTP的流量也要走GRE的，怎么可以随便乱封？

似乎是某省的中国联通的一个二级小运营商。

不过封小众协议根本不奇怪。国内 ISP 本来就是极流氓的，小运营商更甚。我还遇到过有封锁国内到国内的 OpenVPN 流量的小运营商呢……

顺便说一句：江苏联通在 2009 年左右的时候完全封锁 PPTP 流量。国内到国内的也封锁。

--
Zhuoyun Wei

Zhang Cheng

unread,

Dec 1, 2014, 6:50:08 AM12/1/14

to USTC LUG

2014-12-01 17:32 GMT+08:00 Zhuoyun Wei <wzyb...@gmail.com>:

IPIP 和 GRE 这两个协议开销很小，用来翻墙非常合适。我在学校宿舍有线上网直接拿到的是公网 IP

地址，可以直接用。在家的话，家里路由器得开了 DMZ
之后才能用。不过每次重新拨号还要更新对端地址，比较麻烦。再加上这两个隧道协议本身并不加密让我强迫症发作，所以我最终没有作用日常翻墙手段。

对于这种一端是ADSL或者经常变IP的情况，有两种简单的方法解决。一种是写一个脚本放到adsl拨号的接口的if-up/down.d里面，这个脚本可以通过ssh或者其他方式去触发对端更新配置。我目前正在用这种方法，这里可以找到我用的脚本。第二种方法更简单，在对端配置隧道的时候，endpoint填0.0.0.0，表示接受来自所有ip的包，增加一个key（随便填一个合法的东西），隧道两头都用这个key，也就是这个隧道不由两端ip决定，而是由这个key来决定的。我准备回头找时间改成这种做法。

关于加密，是的，所以在网上经常能看到gre over ipsec或者ipsec over gre的配置。ipsec负责加密，但是ipsec的缺点是只能按照通信的pair来配置的，也就是两端都需要配置，而strongswan/openswan这类ipsec vpn，其tunnel模式也不能随便配路由，用起来不是很方便。因此就有很多人用gre over ipsec或者ipsec over gre，一个管加密，另外一个管灵活的路由。这两者之间，我觉得就配置简易程度来看，gre over ipsec更简单。但是我不清楚gfw对ipsec是什么态度。

这两个隧道协议倒是更适合中转式翻墙方案，比如像 LUG VPN 这样的，国内外各有一个固定的公网 IP 地址，这两个 Linux
主机之间建立隧道之后，客户机们连接到国内的 Linux 机器上实现翻墙。

我的一个朋友是一家创业公司的系统管理员，他需要负责全公司员工的翻墙问题。公司的网关是有固定 IP 地址的，在我的推荐下，他把 IPIP 和
GRE 部署在了公司的网关上（其实就是一台 Linux 服务器），直接连到国外的 VPS
上建立隧道。很舒爽地用了一段时间。然后……这两个协议因为流量太大先后被 ISP 给封了（不是被 GFW）……

这种情况可以去告ISP的，ISP没有权力封禁，除非合同里有写。

现在他改用香港专线了，比较贵，但是用来公司级翻墙倒是效果很好，不用再担心 ISP 捣乱了。

我不清楚具体买的哪家的。我原来的一家公司也是买的专线，从香港出国。但是实际上他们会监控所有的http流量，并且有些时候还是会封禁一些国外的网站，比如facebook。而且质量并不稳定，三天两头出问题。而且非常贵，在北京，电信、联通比二级运营商要贵两倍多，他们这个还要比电信、联通再贵一倍左右。

说到这种 Linux 用起来很方便，Windows 用起来很麻烦的翻墙方式的话。Linux 3.2+ 还有一个，最大的优势是原生支持
NAT： https://gist.github.com/klzgrad/5661b64596d003f61980

我以前没有听说过“朴素VPN”的说法，看他的命令，他说的朴素vpn就是l2tp，“加密的朴素vpn”就是ipip over gre，不知道他说的“朴素”是否就是指纯用ip这个命令（iproute2这个包提供的）来建立的，或者是我孤陋寡闻了。（iproute2几乎可以配置所有常见的、内核支持的网络层协议。）

我个人更期待的是 Linux 3.18 的 Foo over UDP 功能。

赞！那么我们将来又多了一个选择。

--

Cheng,

Best Regards

Zhuoyun Wei

unread,

Dec 1, 2014, 8:18:30 AM12/1/14

to ustc...@googlegroups.com

2014-12-01 19:50 GMT+08:00 Zhang Cheng <steph...@gmail.com>:
> 对于这种一端是ADSL或者经常变IP的情况，有两种简单的方法解决。一种是写一个脚本放到adsl拨号的接口的if-up/down.d里面，这个脚本可以通过ssh或者其他方式去触发对端更新配置。我目前正在用这种方法，这里可以找到我用的脚本。第二种方法更简单，在对端配置隧道的时候，endpoint填0.0.0.0，表示接受来自所有ip的包，增加一个key（随便填一个合法的东西），隧道两头都用这个key，也就是这个隧道不由两端ip决定，而是由这个key来决定的。我准备回头找时间改成这种做法。
>

我也写过一个简陋的脚本，在本地获取外网 IP 地址之后，通过 SSH 远程执行，传递给 VPS
上的另一个脚本，实现对端更新。你的脚本写得比我好太多了，已收藏……

endpoint 填 0.0.0.0 然后用 key 认证倒是很好的想法，不过 IPIP 估计不支持。GRE 似乎也不支持？

> 关于加密，是的，所以在网上经常能看到gre over ipsec或者ipsec over
> gre的配置。ipsec负责加密，但是ipsec的缺点是只能按照通信的pair来配置的，也就是两端都需要配置，而strongswan/openswan这类ipsec
> vpn，其tunnel模式也不能随便配路由，用起来不是很方便。因此就有很多人用gre over ipsec或者ipsec over
> gre，一个管加密，另外一个管灵活的路由。这两者之间，我觉得就配置简易程度来看，gre over
> ipsec更简单。但是我不清楚gfw对ipsec是什么态度。
>

目前 GFW 对纯粹的 IPSec 流量未见明显封锁……

>> 现在他改用香港专线了，比较贵，但是用来公司级翻墙倒是效果很好，不用再担心 ISP 捣乱了。
>>
>
> 我不清楚具体买的哪家的。我原来的一家公司也是买的专线，从香港出国。但是实际上他们会监控所有的http流量，并且有些时候还是会封禁一些国外的网站，比如facebook。而且质量并不稳定，三天两头出问题。而且非常贵，在北京，电信、联通比二级运营商要贵两倍多，他们这个还要比电信、联通再贵一倍左右。
>

我朋友最后谈妥的价格是 5 USD / Mbps / mo。已经比原始报价（200 HKD 左右，有一家原始报价 450
HKD）低了很多。以 50 Mbps 计的话，对创业公司来说一个月 250 USD
的支出还算可以接受。不过倒是挺稳定，没有封锁网络的情况。有没有监控就不清楚了。我用过的第一家香港专线倒是有劫持 DNS 流量的行为，会把到
8.8.8.8 等「著名」公共服务器的 DNS 的流量全部劫持到他自己的服务器上，实现所谓的「智能 DNS」……

>>
>> 说到这种 Linux 用起来很方便，Windows 用起来很麻烦的翻墙方式的话。Linux 3.2+ 还有一个，最大的优势是原生支持
>> NAT： https://gist.github.com/klzgrad/5661b64596d003f61980
>
>
> 我以前没有听说过“朴素VPN”的说法，看他的命令，他说的朴素vpn就是l2tp，“加密的朴素vpn”就是ipip over
> gre，不知道他说的“朴素”是否就是指纯用ip这个命令（iproute2这个包提供的）来建立的，或者是我孤陋寡闻了。（iproute2几乎可以配置所有常见的、内核支持的网络层协议。）
>
>

这里的「朴素」只是个形容词而已……链接里的方法支持主要是支持 NAT，这点比较实用。

--
Zhuoyun Wei

Zhang Cheng

unread,

Dec 1, 2014, 9:13:33 AM12/1/14

to USTC LUG

2014-12-01 21:18 GMT+08:00 Zhuoyun Wei <wzyb...@gmail.com>:

我也写过一个简陋的脚本，在本地获取外网 IP 地址之后，通过 SSH 远程执行，传递给 VPS
上的另一个脚本，实现对端更新。你的脚本写得比我好太多了，已收藏……

endpoint 填 0.0.0.0 然后用 key 认证倒是很好的想法，不过 IPIP 估计不支持。GRE 似乎也不支持？

IPIP不支持key，key是GRE特有的，可以理解为tcp/udp中的端口号。

我那个脚本写的也比较早了，其实不是很好。主要是路由方面，是基于IP路由的，所以依赖于两边配置的IP地址。而我的vps是给多个地方共享的（比如我家里、LUGVPN、我公司），要跟多方协调内网IP，有时候不太方便。所以boj给出了更好的方法：https://git.ustclug.org/boj/smartproxy/raw/master/vps/rc.local 这里用的策略路由，从哪个口进来的连接，回去时还从这里回去，这样就不依赖于IP地址了，所以ip可以随便分配。

我根据自己的维护习惯，做了一些修改。我用interfaces文件维护tunnel，这样可以方便的使用ifup/ifdown来随时暂停、启用某个tunnel，interfaces文件内容如下：

auto gre-ustclug

iface gre-ustclug inet tunnel

mode gre

ttl 255

address 10.0.$subnet.1 # $subnet由lugvpn协商分配

netmask 255.255.255.252

dstaddr 10.0.$subnet.2

local $my-public-ip

endpoint 202.141.176.99

up /etc/network/contrib/setup-firewall-for-gre.sh $IFACE 102 1002

down /etc/network/contrib/setup-firewall-for-gre.sh $IFACE 102 1002 destroy

这里，setup-firewall-for-gre.sh 的内容见：https://gitgeek.net/snippets/17

我的这个脚本不支持ipv6，后来增加了ipv6的支持：见：https://gitgeek.net/snippets/19

相应的，在interfaces文件中增加几行：

up ip -6 addr add $local-virtual-v6ip/128 dev $IFACE || true

up /etc/network/contrib/setup-firewall-for-gre.sh $IFACE 102 1002 ipv6

up ip -6 addr del $local-virtual-v6ip/128 dev $IFACE || true

down /etc/network/contrib/setup-firewall-for-gre.sh $IFACE 102 1002 destroy ipv6

不过，这里使用inet tunnel的方式管理，不能指定其他的参数，比如ttl、key之类的，所以还可以进一步修改写法（下面的仅是伪代码，思路没错，但具体可能需要微调）：

auto gre-ustclug

iface gre-ustclug inet manual

pre-up ip tunnel add $IFACE mode gre remote xxx local xxx key xxx ttl xxx

pre-up ip link set $IFACE up

up ip addr add xxx/32 dev $IFACE

up ip -6 add xxx/32 dev $IFACE

up /.../setup-firewall-for-gre.sh ...

down ...

post-down ip tunnel del $IFACE

这里顺便科普一下debian的networking服务，也就是ifconfig, ifup/ifdown, ip 等命令的关系。

ifconfig 顾名思义，是interface configuration tool，专门用来管理iface的，但是其功能基本能够被 ip 命令所替代，而且我觉得使用上 ip 命令更灵活一些。而ifconfig输出的那些统计信息，也都可以直接cat /proc/net/下相应的文件得到。

ifup/ifdown，这是networking服务提供的两个命令，当执行ifup时，它会查看interfaces文件中对这个iface的定义，并调用相应的命令（比如ip、brctl、ppp等等）来启动配置相应的iface，并且执行/etc/networking/if-{up,down,post-down,pre-up}.d/下的脚本（例如有些网络服务需要重启以监听新的端口）。

ip 则是一个比较底层的工具巴。iproute2 这个包主要就提供了俩工具，ip和tc。

所以，ifup/ifdown不仅仅是把一个interface起来、down掉那么简单，同时也管理了许多hook脚本。而ifup/ifdown比较好的一点是，如果iface名字是他们能够识别的，比如brX,、vlanX，它会智能的调用相应的命令来配置这个iface，如果你需要起一些不太明显的名字，比如我上面的gre-ustclug，比如我电脑上为虚拟机配桥时喜欢用vnet0、vnet1等，这时候可以用上面的方法，manual，然后自己写命令。

所以，相比起以前总是手写脚本配置各种接口，我现在更偏好使用interfaces文件，这样要写的代码更简单，而且可以方便的随时up/down。

我朋友最后谈妥的价格是 5 USD / Mbps / mo。已经比原始报价（200 HKD 左右，有一家原始报价 450
HKD）低了很多。以 50 Mbps 计的话，对创业公司来说一个月 250 USD
的支出还算可以接受。不过倒是挺稳定，没有封锁网络的情况。有没有监控就不清楚了。我用过的第一家香港专线倒是有劫持 DNS 流量的行为，会把到
8.8.8.8 等「著名」公共服务器的 DNS 的流量全部劫持到他自己的服务器上，实现所谓的「智能 DNS」……

这也太TM便宜了，这真的是“专线”么？不说别的，在北京，企业专线（名字好听，其实就是光纤入户，上下行对等，有若干固定IP），二级运营商里比较便宜的，也要20w/50M*年，也就是说50M的带宽，一个月要近两万，联通的价格得40～60万。5USD/M*mon，这比一些IDC机房的带宽都便宜（二三线城市的单线IDC机房平均￥15～20/M*mon，多线的机房一般要￥30以上，北上广的BGP机房则>￥100，贵的能>￥500的）。

--

Cheng,

Best Regards

Zhuoyun Wei

unread,

Dec 1, 2014, 9:48:27 AM12/1/14

to ustc...@googlegroups.com

2014-12-01 22:13 GMT+08:00 Zhang Cheng <steph...@gmail.com>:
> 这也太TM便宜了，这真的是“专线”么？不说别的，在北京，企业专线（名字好听，其实就是光纤入户，上下行对等，有若干固定IP），二级运营商里比较便宜的，也要20w/50M*年，也就是说50M的带宽，一个月要近两万，联通的价格得40～60万。5USD/M*mon，这比一些IDC机房的带宽都便宜（二三线城市的单线IDC机房平均￥15～20/M*mon，多线的机房一般要￥30以上，北上广的BGP机房则>￥100，贵的能>￥500的）。

因为我那个朋友所在的公司就是做 CDN 的，所以对带宽价格还算了解。我问了一下，的确是这个价。不知道具体是什么实现的，可能是比较便宜的实现方式吧。

--
Zhuoyun Wei

王冠

unread,

Dec 1, 2014, 10:14:24 PM12/1/14

to ustc...@googlegroups.com

移动是不是把手机的openvpn给封了，手机连不上lugvpn

Bojie Li

unread,

Dec 2, 2014, 3:49:35 AM12/2/14

to USTC_LUG

是合肥移动的路由问题，前几天有至少三个人跟我报 bug 了，我刚才测试了一下确实如此，合肥移动无法访问 202.141.176.0/25 网段，我跟 jameszhang 反映一下。

On Tue, Dec 2, 2014 at 11:14 AM, 王冠 <wgwg1...@gmail.com> wrote:

移动是不是把手机的openvpn给封了，手机连不上lugvpn

王冠

unread,

Dec 2, 2014, 9:07:12 AM12/2/14

to ustc...@googlegroups.com

这个东西和移动反映一下不知道有没有效果

Bojie Li

unread,

Dec 2, 2014, 9:39:54 PM12/2/14

to USTC_LUG

目前合肥移动无法访问 202.141.176.0/25 的问题仍然没有解决，jameszhang 也没有回复。这是一个很严重的问题，导致合肥移动用户无法访问 mirrors、blog、freeshell、vpn。

由于移动线路不稳定，今天中午打算除 mirrors 外的移动线路解析取消，DNS 全部解析到电信线路 IP，大家怎么看？

mirrors 的移动线路承担了 400M 左右的流量（目前总流量接近 800M），如果取消移动解析，会对电信出口造成过大压力且影响用户访问质量。因此是否可以找一下安徽移动的 IP 地址范围，在权威 DNS 上做设置，把这部分解析到电信 IP？ @Roy Zhang

On Dec 2, 2014 10:07 PM, "王冠" <wgwg1...@gmail.com> wrote:

这个东西和移动反映一下不知道有没有效果

Zhang Cheng

unread,

Dec 2, 2014, 9:48:03 PM12/2/14

to USTC LUG

2014-12-03 10:39 GMT+08:00 Bojie Li <boj...@gmail.com>:

目前合肥移动无法访问 202.141.176.0/25 的问题仍然没有解决，jameszhang 也没有回复。这是一个很严重的问题，导致合肥移动用户无法访问 mirrors、blog、freeshell、vpn。

由于移动线路不稳定，今天中午打算除 mirrors 外的移动线路解析取消，DNS 全部解析到电信线路 IP，大家怎么看？

mirrors 的移动线路承担了 400M 左右的流量（目前总流量接近 800M），如果取消移动解析，会对电信出口造成过大压力且影响用户访问质量。因此是否可以找一下安徽移动的 IP 地址范围，在权威 DNS 上做设置，把这部分解析到电信 IP？ @Roy Zhang

不要取消所有移动线路的解析，建议仅取消安徽移动的。不过看上去移动的ip段很少，估计各省使用的也很零散：http://staff.ustc.edu.cn/~james/dxwt/20110307/final/CMCC.txt

不过现在mirrors 400M的流量，应该不是DNS引导过去，而是nginx rewrite引导过去的吧？

--

Cheng,

Best Regards

Roy Zhang

unread,

Dec 2, 2014, 9:50:42 PM12/2/14

to ustc...@googlegroups.com

目前 mirrors 的权威 DNS 还在用 DNSPod，也许是时候迁过来了。

Bojie Li

unread,

Dec 3, 2014, 6:09:30 AM12/3/14

to USTC_LUG

2014-12-02 21:48 GMT-05:00 Zhang Cheng <steph...@gmail.com>:

2014-12-03 10:39 GMT+08:00 Bojie Li <boj...@gmail.com>:
目前合肥移动无法访问 202.141.176.0/25 的问题仍然没有解决，jameszhang 也没有回复。这是一个很严重的问题，导致合肥移动用户无法访问 mirrors、blog、freeshell、vpn。

由于移动线路不稳定，今天中午打算除 mirrors 外的移动线路解析取消，DNS 全部解析到电信线路 IP，大家怎么看？

mirrors 的移动线路承担了 400M 左右的流量（目前总流量接近 800M），如果取消移动解析，会对电信出口造成过大压力且影响用户访问质量。因此是否可以找一下安徽移动的 IP 地址范围，在权威 DNS 上做设置，把这部分解析到电信 IP？ @Roy Zhang

不要取消所有移动线路的解析，建议仅取消安徽移动的。不过看上去移动的ip段很少，估计各省使用的也很零散：http://staff.ustc.edu.cn/~james/dxwt/20110307/final/CMCC.txt

现在把 blog、freeshell、vpn 域名对国内 IP 都解析到电信线路了，国外 IP 仍然是移动线路，也就是取消了 “国内移动线路解析到移动” 的设置。这些服务的校外流量都不大，因此不会给学校电信出口增加负担。

找不到安徽移动的 IP 地址范围，也是我没对 mirrors 域名动手的原因。而且如 Roy Zhang 所说，目前 mirrors 的域名解析是在 DNSPod 的，要把 NS 迁到 dns.lug.ustc.edu.cn 才能做灵活配置。

不过现在mirrors 400M的流量，应该不是DNS引导过去，而是nginx rewrite引导过去的吧？

这个没有统计过，不过 nginx rewrite 过去的可能确实占不小的比例。

--
Cheng,
Best Regards

Reply all

Reply to author

Forward