方院士近况(三)

时隔一年,看看最新的变化,总的来说,情况变的更坏了。
最明显的发现就是仅仅有一个好的 tunnel 是远远不够的,尤其像我用的这个号称 20M 的连通,半月丢一周包的网络,再牛逼的 tunnel,遇到这种只有到了凌晨通向亚太以及太平洋西海岸的丢包率才会下降到 10% 以下的烂网只能洗洗睡了,现在从这个小区出去的,10% 的丢包已经是很乐观的情况了,当然访问大中华局域网是没有任何问题的。
所以,除了一个好的 tunnel 之外,一个 ping 了不丢包或者在高峰时期丢很少的包的网络是非常非常重要的,因此,我最终放弃了之前在 US、JP 以及其他几个地区持有的 VPS,转战到了欧洲以及香港等非主流区域,但是依然难免会遇到丢包的情况。
其实这跟方院士没太大关系,主要还是连通的国际出口太烂,具体体现在带宽太小,或者机器的处理能力太烂,公司电信的出口则不存在这个问题。最初我投诉一下,他们修复一下,过了半个月继续丢包我继续投诉,后来实在没这空跟一群猪脑耗着,索性不投诉了,靠他们解决问题母猪真的会上树了。

要解决这个问题,唯一的办法就是你在海外有足够多的节点资源,哪里坏了切哪里。这事不少服务商都在做,我从前年开始,除了自己搞一套之外,还陆陆续续的试了几个。都能 work,但是做的都比较的 dirty。

  1. 最有代表性的就是 VPN/SSH 之类的,这个没什么技术含量,哪个节点连接不上了切换就好了
  2. 后来还用了几个月的 "highly sophisticated yet extremely easy-to-use Web and Apps accelerator",设置确实很简单,但是离我想要的还差很远
  • 无法做白名单,我需要绝大部分的都走 proxy,很少的走默认的路由
  • 每个月的流量对我来说太少,因此不能走全局模式,依然是上面的问题
  • 没想象中的智能,节点挂了照样没法智能的切换
  • 最悲伤的是,Twitter 上了 SPDY,据说是因为 iOS 无法做 proxy 了,于是该服务就没法用 Twitter,这对我来说就等于是废了

总结一下,要持续的跟方院士做斗争,需要:
1. 好的基础网络环境,低丢包率的小众低调私有 tunnel,没有比这个更重要更基础的了。其实上面的还不是最坏的情况,最坏的情况是什么了?好不容易国内的不丢包了,国际出口也不丢包了,HE 却在狂丢包 :-(

2. 作为备份,一个完备的商业 proxy 服务,这个需要平时多用多发现

希望我写方院士近况(四)的时候内容只有三个字「肉翻了」。

10G 网络升级(服务器端 bonding)

本次升级最大的"意外"之一就是关于服务器 bonding 的问题,归根到底还是在升级之前文档看的不够充分,调研的不够仔细。下面会对其做一个比较全面的分析。
说到 bonding,最重要的问题之一就是模式的选择,这个是要根据各自不同业务来选择的,切勿人云亦云,我整理了一份表格,说明每一种模式的一些特性以及交换机对其的支持情况。

选哪个模式最合适?很明显,正常情况下,mode4 是一个比较好的选择,但是需要注意的是端对端尤其是交换机 active/on 选择,对于服务器来说,稍微有点繁杂,需要根据网口的情况来分:

  • 四口的,如果有内外网,没有问题
  • 两口的,如果仅仅有内网或者公网,也没有问题
  • 两口的,如果既要有内网又要有公网,很明显,还缺少两个端口,这时候在 Linux 上做 VLAN  的价值就体现出来了

确认完模式,接下来就是 bonding 的安装,bonding 这个 module 默认应该都是随发型版本加载的,可以在 /etc/modprobe.d/ 目录下面加载;接下来就是修改网卡对应的配置了,各个不同的发型版本大同小异,这里分别给一个 Ubuntu 以及 RHEL 的范例。这两个主流发型版本的 bonding 的配置还是比较灵活的,除了可以在 /etc/modprobe.d/ 里面指定 bonding 的各种参数之外,还可以在 network-scripts/ 以及 interface 里面指定,比如可以在 ifcfg-bond0 里面指定 bonding opts:
# cat /etc/sysconfig/network-scripts/ifcfg-bond0
DEVICE=bond0

BONDING_OPTS="mode=4 miimon=100"

跟 bonding 有关的几个实时文件分别在 /proc/net/bonding/:
# cat /proc/net/bonding/bond0

以及 /sys/class/net/ 下面:
# cat /sys/class/net/bonding_masters
bond0

# cat /sys/class/net/bond0/bonding/mode
balance-alb 6

# cat /sys/class/net/bond0/address
99:11:11:11:dd:dd

要让 bonding 生效,我认为最 KISS 的办法还是直接重启机器,尽管可以通过 ifenslave 或者在加载完 bonding 之后直接在 /sys/(/sys/class/net/ 下面) 里面 "on the fly"。官方的建议是通过 iproute2(ip link set eth0 master bond0) 或者 sysfs 修改生效,ifenslave 会被逐渐抛弃。
在启动的时候,注意查看系统的 /var/log/messages,这个文件里面能看到很多跟 bonding 相关的信息。

对于 bonding 一对或者多对网卡的监控,可以二选一:
1. miimon
2. arp_interval 以及 arp_ip_target
不用任何监控的弊端之一就是一个网卡挂了无法及时的切换到另外一块网卡上,这个明显是不容许的。
对于 ARP 的监控方式,一般用在兼容 etherchannel 的模式里面,也就是交换机会将流量分散到多条链路上;如果是以 XOR 的方式(单条链路)则不可行。除此之外,ARP 的方式不可以跟 miimon 同时使用。
对于 miimon 来说,有 downdelay, updelay, user_carrier 几个参数比较重要。
如果想使用 balance-xor 或者 802.3ad,还需要了解下 xmit_hash_policy 以便更好的平衡流量。

既然是端到端的系统,除了要考虑服务器方面的 bonding 状态,也要考虑对端 FEX 的支持情况,在上篇已经说过,主流的 2k 跟 5k 的接法无外乎 single-homed 也就是一台 2k 仅连接一台 5k 或者是 dual-homed 也就是一台 2k 同时连接两台 5k。其中前者的 topo 支持 2k 的到服务器的 vPC、FCOE 以及 static pinning,而后者是不可以对 2k 下挂的服务器做 vPC,单凭这一点就没什么优势了,更何况这种接法还有其他不少的缺点。

这里有一篇文章提到遇到 Orphan Port 也就是单上联的情况,这个在实际情况中还时有发生,尤其是比较早期的服务器,那时候网口的数量还不足以达到双上联的标准,对于这类情况,文中分析在 peer link 参与的情况下流量的分布以及需要注意的地方,值得看看。

还有几个需要注意的地方:
1. 路由问题,原先由 eth0 单块网卡处理的现在将由 bond0 接替处理,如果是通过 ifensalve、modprobe 等方式启动的 bonding,注意也要修改对应的路由,重启不存在这类问题。
2. SNMP 问题,需要确保 bonding  这个模块在其他的网络模块之前加载,否则 SNMP 取得的数据会有错乱。
3. 在混杂(promiscuous) 模式下,balance-rr, balance-xor, broadcast 以及 802ad 这四种模式会将混杂模式的设定会传播到所有的 slave 接口;而 active-backup, balance-tlb 以及 balance-alb 这三种则只会传播到 active 的 slave 接口。
4. duplicated 包的问题,最常见的是在初次或者闲置一段时间之后 ping 某台机器的过程中发现不少 (DUP!) 表示的包,正常现象,主要在于交换机广播的机制,最简单的方式是清空一次 MAC 转发表,Nexus 上的示例:
# clear mac address-table dynamic


update: 服务器端的注意 xmit_hash_policy 这个参数,默认值为 layer2,也就是 mac 层的 hash,在某些业务下,会出现带宽跑不满,上不去的情况,可以考虑使用 xmit_has_policy=1(layer3+4) 的组合,这个还是要根据具体的业务来定。

Thailand 小游(Koh Samui, Chiang Mai, Bangkok)

过年期间跟某只小熊猫去 Thailand 溜达了一圈,享受了半个月的清新的空气,满天的繁星以及自由的网络。下面按照时间顺序,流水账的记录一下。
就在出发去 PVG 的前一天晚上,我的这台历经磨难的 air 的硬盘又挂了。说来好笑,去年在跟三里屯零售店的以出了问题重装系统为指导思想的一帮蠢才吧的员工扯了大半个月之后,他们的头头终于同意给我换一台全新的 mba,可是用了不到三个月,这台笔记本的 SSD 就中招了,把笔记本仍在那儿扔了一周之后,终于换好了 SSD,按理说,应该不会再出现问题。结果,就在我走了前一天晚上,SSD 又光荣牺牲了,还好第二天要去的是上海。2号下午到了上海,下了火车就急匆匆的赶到了他们的香港广场零售店,等了三个多小时,拿到了一台空系统的机器。
3 号早上的飞机,12 点出发的航班延误到了 14 点才出发,到了 HKG 中转,下了飞机看到国泰的小妹们忙的不可开交,一个个扯破嗓子在"拉客",顿时觉得现代这么发达的航空业也不过如此,最后到达 BKK 的时间竟然只比原计划晚了不到 1h,真庆幸。晚上住在了离 BKK 不远的酒店,放下行李之后,在周围溜达,初步勘探下来,除了沿路若干的 711、bigc 以及 tesco,其余的都是路边摊,我们就在路边选了个当地人最多的摊位找了可能是当地的小吃做为了晚饭,口味一般般。
第二天中午直飞到了 Koh Samui。其实除了直飞之外,还可以通过水陆或者水空结合的方式,从 Bangkok 做大巴/飞机到 Surat Thani Province,然后坐船到 Samui,价格会比带有垄断性质的直飞便宜的多,但是耗时也长的多,有时间的完全可以体验一下。不得不说,USM 机场是我见到过的最漂亮的机场(虽然我也没见过多少机场),用几个关键词概括一下就是花、树荫、鸟、蓝天、可爱的飞机。
接下来的四天主要的行程就是晒太阳,我没做特别详细的攻略,基本是走到哪里吃到哪里玩到哪里,海里玩累了就上岸晒太阳吃东西如此循环。住在 Bo Phut 的 Samui Pier Beach Resort,离 Big Buddha(其实没什么意思,属于去跟不去都后悔的那种) 步行大概 15min,人少安静,基本没有聒噪成群结队的大陆土豪。
从我们住的地方往东的那条主路吃到了味道最正的 Tai cuisine,英文名叫 Cafe Uno,一家看上去非常本地化的小餐馆,环境一般般(真正好吃的东西都在那种价格不贵环境一般的地方),他们家的菜单没有价格,统一 60B 一道主食。味道最正的一道主食叫 Kapaw rice,食材很简单,就是 rice, basil, pork, chilli pepper,这个在 711 以及后来其他的餐馆都尝过,但是味道跟他们家比还是有不少差距,有条件的把他们家的菜都吃一遍吧,反正我们是基本做到了,不后悔,下午三点关门,要吃的趁早。靠近他们家有一个流动的卖水果的摊点,菠萝的价格便宜不说,据资深菠萝专家小熊猫的评价,这是她吃过的最好吃的菠萝了,同样的,机不可失时不再来,我们也只买到了两次,后来再过来的时候再也找不到他们了。
除了这两个固定的地方之外,在 Mae Nam beach 以及 Chaweng Beach 呆了两天,推荐个叫 "KohSamui" 的 app,优点是能根据我目前的位置推荐一些比较好的商户。Mae Nam 的 Chill Out cafe 以及 Chaweng 的 synergy samui 都是他推荐的,点几个 dish 两杯 cocktail 一下午很快就过去了。另外,各个海滩上的烤玉米普遍都不错,我们吃过几次,口感非常脆鲜嫩多汁。
最后一天就在酒店做了个 deep tai massage,手法一般关键是环境好,sea view。竟然还可以还价,一人 400,两人 700。
在岛上唯一遗憾的就是交通太混乱了,靠左行驶是一个不大习惯的问题,taxi 以及 Songtaews(中文叫双条车) 漫天要价,由于之前没有研究下这两种交通工具,分别被砍了 400B(都是 3 公里不到),后来有经验了知道要态度坚决的砍价,对半砍。不得不说北京的出租是我见过的最规范最标准的出租。
接着是飞回 Bangkok,根据小熊猫的指示,下了飞机立马酒店 check in,然后赶了个叫 Chatuchak weekend Market,还蛮热闹的,第一次喝到用塑料袋(好像整个 Thailand 都喜欢用塑料袋装熟食)装的 ice tea,里面其实就是自由市场,随便走走也蛮自在的。首都的交通比接下来的包括 Chiang Mai 在内的要规范的多,taxi 基本都是可以打表的。
次日中午到了 Chiang Mai,据说坐火车也是一个很好的选择,沿途风景不错,前提是时间充裕。在 DMK 见识了大陆失足少女狂扫 NaRaYa 的场面。Chiang Mai 是一个国人跟团聚集的地方,基本上如果你能听到各种呱噪以及机场工作人跟乘客谈三观问题的话,十有八九十就是我们的同胞了。我跟小熊猫在某些问题上的观点很一致的,比如在 Chiang Mai 我们看到国人跟团聚集的地方会主动避开,选餐馆会先大概评估下里面大陆同胞的数量,曾经在 USM 这么美好的地方见到工作人员训斥一帮穿戴十分光鲜亮丽的大陆同学的某些不雅行径,大陆护照基本是废止一张跟这些不无关系。
原本是根据小熊猫在吃货俱乐部等各大中文网站做的攻略来的,后来发现情况不妙,你能找的到的其他说中文的也能找到,"Chinese go out, Chinese around"。后来干脆切换到前面在 Samui 的做法,随便跑辅助参考 tripadvisor 的做法。当然 Chiang Mai 最有名的横跨 Ratchadamnoen Rd 的 Sunday night market 绝对不可错过了,我跟小熊猫都看的眼花缭乱,这是目前我见过的最大的市场了,比大陆的有序最重要的干净的多,那天晚上在 Tha Pae Gate 正在举行 Flower Festival 的闭幕式,人流涌动异常欢乐。
接下来的几天在路边感受了一次廉价的 foot massage,在 nanthikan,一个非常不起眼的角落做了一次全身的 hot oil massage,有没有保健效果不知道,但是全身脱光了,黑暗中,被一个看不清容颜的女性全身按压,感觉不一样啊。
吃的方面,在 Nimmanhenin Rd 吃过一次日式简餐,味道应该蛮正的。Dash(我也不大清楚为什么这么火)、Ristr8to² (一家非常有意思的咖啡馆)、Huen Phen(本地小吃,跟我们在 Samui 吃的那家比差不少,只不过离我们的住的地方很近)、Guu Fusion Roti & Tea(印度 Roti)、Kabab Bar(中国人民的老朋友巴基斯坦开的,foursquare 的 Indian Restaurant 有误,pratha 一定要尝一尝) 。只因为看到里面有 live band,进了家叫 The Garden Restaurant 的地方,各点了杯 cocktail,我感觉我点的那杯 Mai Tai 里面糖精放多了,跟在 Chill Out 点的那种甜甜苦苦酸酸的口感完全不一样,直到后来看 tripadvisor 才发现这是家 gay bar。最后什么骑大象、看 ladyboy 的表演、玩 zipline 我们统一都没玩,除了 zipline 某只小猫觉得太危险不让玩,其他的都没什么兴趣。
最后几天呆 Bangkok,真是一段用身难忘的经历。我们去年很早就定好了 Thailand 的酒店机票,结果一帮政客年底闹革命,搞的人心惶惶。我们在 National Stadium 附近定的酒店离 Suthep Thaugsuban 他老人家带领的一帮老弱病残中下贫农的演讲舞台只有不到 5min 的路程,大晚上关了窗子都能听到他们玩摇滚的声音。实事证明了,情况没那么糟糕,这种 protest 无非就是一帮中高产利益集团跟不满另一帮利益集团而已,跟底层人民的关系甚微,恰巧在年前看完了《天葬:西藏的命运》,二者对比下会发现,很多东西都是惊人的相似。在 National Stadium 的现场,跟着 Suthep 玩的都是一帮只会说 Yes 各 no 的农民,白天根本看不到一个穿着像样的年轻人,只有到晚上下班之后,才能看到一些年轻人聚集在广场听 Suthep 演讲,接着是唱歌跳舞,然后继续演讲,后来某天晚上我们也参与近来了(1, 2) 。被封路的沿途商户基本都已关闭,只剩下跟着抗议的农民摆的小摊了,每天免费供应三餐,也算是提前过上社会主义的日子。出了像 Victory Monument 这样的几个闹事区,根本感觉不到这个国家任何的不对劲,21 termainal 照样人来人往,Wat Pho 照样香火旺盛,该怎么玩继续怎么玩。最后一天在 Siam 找了个 shooting range,第一次碰到了真正的 revolver  以及 rifle,时间很快过程很爽,据说资金充裕还可以开坦克玩。
由于要走的前一天晚上在走了 20min 路之后好不容易发现了一家 Tesco 里面有酒卖(Bangkok 大部分地区都禁酒, Chiang Mai & Samui 不受影响),买了两瓶 fruit wine,度数比在 Samui & Chiang Mai 喝的猛一些,结果晚上喝了点就感觉醉了,第二天到了机场又灌了半瓶然后倒掉了。
最后回来要中转的航班被国泰取消了,直接给我们换成了泰国航空的直飞,这样也好,节约了不少时间,不过某只熊猫少吃了一顿看上去还不错的穆斯林的机上餐,有失有得。
最后大赞全 Thailand 公共场所禁烟的举动,这半个月我没有闻到一丝的烟味,身心得到了无比的放松,这比伟光正的小打小闹禁塑料袋不敢触及真正利益集团的的举动要强的多。

OpenSSL(CVE-2014-0160)漏洞修复速度

OpenSSL 不是第一次出现这类影响非常严重的漏洞了,12 年 4 月的 CVE-2012-2110 这个漏洞当时就让我忙活了好一阵子
今天早上扫 feedly 的时候发现了这个漏洞,迅速确认了我们线上的服务器不受影响之后就开始围观了。  
OpenSSL 官方最先挂了通知
几个主要的发行版本都在当天(4 月 8 日)发出了 Heartbleed bug 影响以及修复方式:USN(1, 2) , DSA, Bugzilla

要说影响,基本可以确定包含 taobao 在内的绝大多数的都受到影响了,其他的小电商小网站就不计其数了,wooyun 上有截图为证:

话说这漏洞出来也好长时间了(相对于互联网的速度),到我写这篇博客的时候(08-21-04-08-2014),最少也有五六个小时了。很不幸的是,我跑了一遍,发现还有下面这些网站没有及时的升级打补丁:
1. kyfw.12306.cn,这个证书本来就有问题
2. 126.com/163.com 旗下的各种邮箱
3. login.yahoo.com,  www.flickr.com 这两个一起的,www.tumblr.com 虽然被收购了,估计还没整合好,这次修复的还蛮迅速的
4. www.quora.com 没想到反应这么慢
5. 京东的蛮有意思的,海外、国内登录两套标准,passport.en.jd.com 这个没有 ssl 证书,passport.jd.com 则有证书
6. fitbit.com,毕竟不是专业搞互联网的,速度慢可以理解

上面的在没有确认升级完毕之前,务必不要再登录,要检验是否安全很简单,可以去 github 上跑个脚本或者直接用这个。其他的比如 amazon.com, coursera.org, dropbox.com, evernote.com, facebook, twitter.com, foursquare.com, github.com, instagram.com, vimeo.com, wikipedia.org 我扫的时候发现已经没有问题了(或许原来就没遇到这个漏洞)。

其实这个漏洞保守估计在一周之前就已经发现,但是并没有公开,所以 cloudflare 有足够的时间去升级,今天发布的这个博客绝对是个绝妙的加分项,完爆 ali。

如何修复?
对于服务商,抓紧时间升级。
对于用户,最好修改一遍密码,因为可以确认包括 taobao 在内已经有部分用户的信息泄漏了,如果你是所有网站公用一套登录名密码,连夜修改吧。


update: 07-15-04-09-2014,上面提到的 6 个网站已经全部完成修复,速度还算可以接受。

update: 04-09-2014,Cisco 官方发出了受影响设备的列表,IOS 以及 Nexus 的不在影响之列。

遭受了 NTP 放大攻击

某台开放了公网的服务器流量从某时刻起突然暴涨了,登陆上去排查,ibmonitor&iftop&iptraf 三个工具结合跑一遍,直接定位到了问题的根源,遭受了 ntp amplification,现象以及细节可以看下面五张图。

整个过程中我们的带宽变化

攻击进行时通过 iftop 观察到的现象

攻击进行时通过 iptraf 观察到的现象

停止了 ntp 之后通过 iftop 观察到的

停止了 ntp 之后通过 iptraf 观察到的

关注 cloudflare 官方博客的可以发现,时间跟这次全球性的 400G DDoS 非常吻合,之后通过跟官方联系,确认我们的机器是受害者之一。
除了 NTP 之外,DNS 以及 SNMP 也是易受攻击做 AMP 的协议之一,二者都是 UDP,很容易通过很小的投入产生巨大的流量,根据监控可以发现,机器的进流量在受攻击的这段时间内几乎没有变化,而出去的流量净增 400M+。按照这个量,攻击十台这样的服务器,基本可以搞定一个中型网站的一个或者多个出口。

如何防御?OpenNTPProject 这个项目上写的很详尽