感谢AI 酱和缺梦等老司机的安利与指导，最终于今年三月底购买了 XPS 15 9550。次月，又蛊惑同学购买了一台。

两台机子都是在 eBay 上购买的官方翻新版（manufacturer refurbished），经由顺丰转运，送至澳门。我这台是 i7 16G 512G FHD，总花销 8736.69 元 （1299.99 USD / 8482.69 CNY + 254.00 CNY 运费，港澳无关税）。同学的是 i5 8G 256G UHD，大概七千元。

配置

XPS 15 系列不同型号的机子不少，Dell 官网共列出了八款。主要就是 CPU（i3/i5/i7）、内存（8G/16G/32G)、硬盘（不同容量的 HDD、SSD 及其组合）、电池（56Wh/84Wh）、屏幕（1080P 非触屏/4k 触屏）的不同组合。

我入的是 i7 16G 512G FHD 这款，以下描述针对此型号，不清楚其他型号是否有所不同：

• 机子带了一个 USB Type-C 口，Nexus 5X 终于有得连原装充电器以外的设备了；
• USB 口支持关机充电，但默认关闭，需要在 BIOS 里开启；
• 带 TPM 1.2，使用 BitLocker 全盘加密非常方便；
• GTX 960M 带 Fallout 4 使用「中」画质，通常跑在 30~50 fps 的范围内。

其他能方便地查到的配置细节就不提了（

购买渠道

在 Dell 国内官网购买似乎是最贵的，淘宝买官方翻新版会便宜很多。自行从 eBay 海淘可能会更便宜。下面是此时（2016年5月29日）我入的这个型号（i7 16G 512G FHD）在不同渠道购买的大致价格：

eBay 官翻的价格不一，我入的那台是 1299.99 USD，美国国内包邮。

这也是我第一次在 eBay 上买东西，有两个可能需要注意的地方：

• 注册的时候，填写的是联系地址，填自己常住地就好。如使用转运服务，注册好之后再将转运仓库的地址作为邮寄地址添加；
• 不少商品是支持直邮国内的。搜索结果似乎默认会滤除无法（直接）送达的商品。如要考虑转运，需要更改设置(?)或者添加一个美国地址。

转运

如果卖家支持直邮国内，价格合适倒是能省很多事，缺梦似乎就是这么做的。

我这次用的是顺丰的海购丰运，他们支持送到港澳台。流程大致是：注册，得到转运仓库地址，卖家发货后添加包裹资料，包裹到达仓库后确认、交钱、出库，坐等签收。

价格

听说顺丰的转运也比较贵的，如果是送国内，还有更便宜的选择。

两次购买，包裹称得重量是 3.28kg 和 3.34kg，按此时的价格，如包裹重量大于 3.1kg，先购买一个 50 元/月 的会员会更划算。最终的运费为 254 元（会员 50 + 首重 64 + 续重 160 – 优惠 20）。

时间

从顺丰收到包裹，到在澳门签收，两次购买分别花了 5 天和 7 天。

比较蛋疼的是美国国内这一段。我购买时，由于卖家就在仓库隔壁城市，只花了不到两天就送到了。而同学的那台卖家在西海岸，足足花了一周才送到  。

开箱

开向前 -> 开箱后（误：

箱内除了机子本体和电源，还有就是保修信息小册子和 USB 的 Windows 恢复盘了（USB 3.0 好评，> 100 MiB/s）：

顺带一提，卖家还 email 了他的购买资料，用于在 Dell 官网申请更新保修相关信息（ Warranty and Ownership Transfer）。

其他

• 超窄边框爽爽爽；
• 轻、薄、好看，15.6” 的屏幕却比之前的 14” 本子体积还要小；
• 触摸板手感很好，爽；但键盘感觉一般；
• 我这台到手后是 Windows 10 Pro，虽然官网写的是 Home；同学那台是 Home 版；
• 触屏的玻璃反光挺明显的，非触屏版没有这个问题；
• UHD 版的屏幕色彩效果很好，能很直观地感受到其他屏幕和它的差距；
• FHD 默认放大至 125%，日常使用没有特别的不适；UHD 默认 250%，调成 200% 的效果也不错，强行放大整数倍的文字似乎会比 125% 或 250% 略微清晰一些；
• 插耳机时一般用 4% 的音量，无声音播放时可以听见底噪。

RT @kgen: 大家 BT 下载的时候，不要开着 VPN，发达国家的版权投诉猛如虎。版权方会主动放出一些正版的 BT 种子，然后收集所有连接来源 IP，投诉或索赔。

这对于 VPN 提供商来说也是一个很头疼的问题。现在的 BT 客户端为了避免被封，已经经进化出了各种加密、混淆手段，直接检测 P2P 流量很困难。不过，大多数时候，客户端都在下载是都会同时连接一些 BitTorrent tracker 服务器。这些服务器数量有限且地址、端口号相对固定，可以非常容易地收集，并直接通过 IP 地址和端口号判断而不必对流量内容进行深度检测。探测到了就扔炸弹。是一个简单易行的判断用户是否正在使用 BT 的方法。

这个方法已在某家梯子站上部署了有一段时间了。鉴于它误报率（false postive rate）低但漏报率（false negtive rate）高，检测到的「处罚」会比较严厉——发现连接就立即挂断这条 VPN 连接。效果似乎还不错，仅有的几次投诉经过排查，发现都是在这套机制的某些环节失效时发生的。

当时为了方便操作，写了几个脚本。现在重新整理了一下，放在了 GitHub 上。这个脚本主要用于从 BT 种子文件里收集 trackers 的地址，然后解析域名得到对应的 IP 地址、协议和端口号。脚本本身并不进行检测等操作，只是为了方便配置防火墙而写。

示例

先在各处收集一些 BT 种子，这些种子文件中通常会包含一个或多个的 trackers。可使用./trackers.py torrent获得 trackers 的 URL 列表，重复的地址会被自动剔除：

$ ./trackers.py torrent *.torrent > trackers.txt

$ cat trackers.txt
> http://tracker.yify-torrents.com
> udp://tracker.justseed.it:1337
> udp://tracker.openbittorrent.com:80
> http://nyaatorrents.info:3277
  ......

防火墙通常需要匹配 IP 地址而非域名，并且一个域名可能对应多个 IP。这个脚本提供了解析 tracker URL 的功能，每个地址会被解析为一个或多个 IP 地址 – 协议 – 端口 的组合：

$ ./trackers.py raw trackers.txt
> 188.166.82.104 tcp 6881
> 94.23.217.90 udp 1337
> 179.43.146.110 udp 80
  ......

使用 ipset 来匹配这些连接是一个不错的选择。可以使用./trackers.py ipset直接生成 ipset 规则，这些规则可经由ipset restore导入系统：

$ ./trackers.py ipset trackers trackers.txt > ipset.rules

$ cat ipset.rules
> create -exist trackers hash:ip,port family inet
> add -exist trackers 188.166.82.104,tcp:6881
> add -exist trackers 94.23.217.90,udp:1337
> add -exist trackers 179.43.146.110,udp:80
> ...

# ipset restore -file ipset.rules

另外，虽然不是很推荐这么做，从收集 trackers 到导入 ipset 的操作也可以一步完成：

# ./trackers.py torrent *.torrent | ./trackers.py ipset trackers - | ipset restore

导入 ipset 后，可以使用 iptables 匹配这个 ipset，进行进一步操作。例如可使用iptables -j LOG记录下连接 trackers 的行为：

# iptables -N TRACKERS
# iptables -A FORWARD -m set --match-set trackers dst,dst -j TRACKERS
# iptables -A TRACKERS -m limit --limit 1/sec --limit-burst 10 \
  -j LOG --log-level info --log-prefix trackers
# iptables -A TRACKERS -j DROP

一些发行版本使用了 syslogd 管理日志，可以修改它的配置，将连接记录转发至其他程序进行进一步处理。例如文章开头所说的，通过日志中记录的源 IP 识别出对应的用户，然后将其断线。

编辑于 2015-09-03

我在用的 Arch Linux，众所周知，是一个比较激进的发新版本。它已经开始送主线内核linux-armv7啦。

毫无悬念地，更新后就无法启动了。原因似乎是它没有更新 U-Boot。
参照这篇 Mainline U-Boot 编译最新的主线版 U-Boot 然后写入 SD 卡就好了。

需要注意的是，boot.cmd内容需要根据 Arch Linux 的安排有所更改：

setenv bootargs console=ttyS0,115200 root=/dev/mmcblk0p2 rootwait panic=10
load mmc 0:1 0x43000000 dtbs/${fdtfile}
load mmc 0:1 0x42000000 zImage
bootz 0x42000000 - 0x43000000

（不同之处也就是使用bootz来载入zImage；fdtfile位于dtbs/下）

另外注意似乎还有一些驱动不太完善，比如无法使用 NAND，具体请参考 Linux mainlining effort。

当然「听起来好像很厉害」只是个副作用，其目的还是为了确保安全。

TL;DR – 如果你的网站也支持全站 HTTPS，可以考虑配妥 HSTS 后在此提交申请。

（2015-11 更新）现在 Qualys 的 SSL Server Test 也会显示相关信息啦：

一切为了安全

现代浏览器在安全上真是做足了功夫。

HTTPS

SSL 协议在早在上世纪末就已提出^[2]。目前广泛使用的 TLS 1.2 是它的改良版，在 2008 年正式发布^[3]。他们可以在很大程度上，保证数据在 浏览器 与 网站服务器 间传输时的安全，保证他们不在传输过程中被监听或者修改。

但目前仍有大量网站是不提供 HTTPS （SSL/TLS）连接的 ^[4]，或是只在部分页面提供。浏览器不知道哪些网站使用 HTTPS，用户也不一定知道。现在通常的做法是，浏览器先默认使用 HTTP 连接，如果服务器要求安全连接，再通过这个 HTTP 连接返回给浏览器一个「重定向」，让浏览器转而使用 HTTPS。

这样有一个问题，因为 HTTP 是不安全的，这个「重定向」就有可能被攻击者吞掉。然后攻击者一方面冒充服务器，使用 HTTP 与浏览器进行通讯；另一方面冒充浏览器，与服务器使用 HTTPS 建立连接。这就是所谓的 SSLstrip 攻击。

HSTS

为了解决这个问题，HTTP Strict Transport Security (HSTS, HTTP 严格传输安全) 孕育而出。这个 2012 年才发布的新玩意儿其实很简单，就是制订了一种方法，让服务器能够告诉浏览器：「我支持 HTTPS，今后请仅使用它连接我」。

具体来说，它在增加了一个 HTTP 头 Strict-Transport-Security，里面指明网站至少支持 HTTPS 多长时间、是否包含子域名等。浏览器会缓存这条规则，今后即使是用户或者网页指定了http://，浏览器也会无视掉它，强制使用安全连接。

Preload List

但这无法阻止首次访问网站时受攻击（此时还没有 HSTS 规则的缓存呢），浏览器们并不满足于此，推出了 HSTS Prelod List（预加载列表？）。顾名思义，就是将使用 HSTS 的网站域名直接内置（hard-coded）进浏览器。只要是出现在列表中的域名，就统统只使用 HTTPS 连接，让攻击者无缝可钻，安全性大提升。

部署

唔.. 介绍了这么多背景，进入正题，怎么做？首先当然是要做好全站的 HTTPS 支持，这个就略过不提了。然后是部署 HSTS。最后是提交申请，进入浏览器的 Preload List。

UPDATE 20150904: 如果你在使用 CloudFlare，进入 Dashborad，在 Crypto 找到并开启 HSTS 就可以了。

HSTS

添加 HSTS 支持其实很简单，修改一下 Web 服务器的配置，增加一个 HTTP 头就行^[5]。随手 Google 到了一篇文章，大家可以参考一下。

举个例子，这个域名目前使用的是：

Strict-Transport-Security: max-age=15552000; includeSubDomains; preload

max-age=15552000告诉浏览器缓存这条规则 180 天；includeSubDomains对子域名也使用相同的规则；preload允许将这条规则内置进浏览器。

部署完毕后，可以用这个网站测试一下。如果存在其他安全相关问题，也会被检测出来。

Preload List

Duang! 现在可以提交申请啦（自备梯子）：
https://hstspreload.appspot.com/

这个网站似乎是 Google 牵头做的，但不仅 Chrome，Firefox、Safari 和 IE 也都会包含这个列表。所以只要在这里提交一次就行啦。

提交前注意几点：

• 需在全站启用 HTTPS（包括子域名），同时重定向所有 HTTP 流量至 HTTPS；
• max-age必须大于 10886400 秒（18 周）；
• includeSubdomains和preload；
• 不能反悔的哦。

另外，他说这个申请是要经过人工审核的（not automatic nor assured … undergo a manual review），所以可能要花上几周的时间。具体到并入个浏览器代码中，可能需要更长的时间。

老实说，当初我看见「人工审核」便没报太大希望，提交后就忘了这事了。近几天才偶然发现已经申请通过并入了浏览器，才知道其实并没有什么门槛（虽然目前的列表只有两千行左右）。所以我也不知道我从申请到通过花了多久…

附注

[1] 会并入随 Windows 10 发布的那个 IE 上，MSDN 是这样说的。所以我是不是还可以更标题党一点，比如「与 Windows 一同发布」或者「嵌入 Windows」，233。
[2] Wikipedia – Transport Layer Security
[3] RFC 5246 The Transport Layer Security (TLS) Version 1.2
[4] 65% of top 1,000,000 websites by 2014. Source.
[5] 其实要完全符合标准的话，还要复杂一些。如果你也在使用 nginx，可以参考这条评论进行设置，会更规范一些。

传感器内部有一个 LED，通过检测灰尘对光的反射的强度来估计空气中单位体积内灰尘的质量。
虽然因为无法区分灰尘颗粒的体积，无法直接推算出 PM2.5 数值，但我想它和 PM2.5 之间应该还是比较强的相关性的 ^来源请求。

（嘛 30 块一个东西还是不要想太多比较好。

另一个传感器是 DHT22，淘宝大概 20 元一个。用于测量空气温度和湿度。

去年暑假我把这两个东西用了起来，监测室内空气状况并绘制图表然后显示在网页上。干嘛用？就是玩具，好玩嘛… 如果你也觉得有点意思，想搞个玩玩… 这篇文章也许可以用作参考。

事隔较久，一些细节记不太清了，可能会有些疏漏。相关代码在使用前记得改改文件名路径什么的。

读取传感器

这两传感器都不是面向一般用户的，没有 USB 这样方便的东西呢…
DHT22 是用一根线串行输入输出。
GP2Y1010AU0F 输出的是模拟信号，要测量输出口的电压，根据电压来计算灰尘密度（如下图^[2]）。

DHT22 也许^[3]能用 Cubieboard （山寨树莓派） 的 GPIO 来读取。
但 GP2Y1010AU0F 则需要测量电压（A/D），Cubieboard 不带此功能。

于是就用了 Arduino，先用它定时从传感器读取数据，然后通过串口（UART）发送给 Cubieboard。
读取传感器的模块：DHT22.cpp DHT22.h, GP2Y1010AU0F.cpp GP2Y1010AU0F.h
每隔三秒读取一次两传感器，从串口输出 的 Arduino 代码：Sensors.ino

储存数据

数据通过 UART 传给了 Cubiebaord，接下来就是想怎么存怎么存啦。
这里按照传统^来源请求，用 RRDtool 来储存数据。简单方便^[4]自带数据库顺带还能把画图给做了。

先用rrdtool create创建数据库：rrd-create.sh
别问我这些参数是啥意思，半年多过去了我早忘了（
RRDtool 也是挺坑的，参数多不说，写出来一点都不直观，不对手册根本不知道这都是些什么鬼（

arduino-uart.py 这个 Python 脚本将持续地从串口读取 Arduino 发来的数据，然后执行rrdtool update往数据库里喂数据。

呈现数据

使用rrdtool graph绘制折线图：graph.sh
./graph.sh 1d 绘制近一天的图像，./graph.sh 1w 绘制近一周的图像。
（输出和数据文件路径请修改开头的DIR和DATA变量）

可以使用crontab -e或者 systemd-timer^[5] 定时执行脚本更新图像。

再加个网页做索引：index.html
网页上方可选择查看近一天、一周、一个月的数据^[6]。这样就基本完成啦。

完成

其实装好后我一直挺担心灰尘传感器的读数是否正确的，没法方法确认，读出来的 µg/cm³ 我也没啥概念。不过这幅大年三十的图看起来倒是挺像回事的：
（图中数据单位有误，应为 µg/m³）

即使家里门窗紧闭，依然能看到中午一点和午夜的两条高峰。想必是受周边鞭炮燃放的影响吧。

附注

[1] 来源 iMall
[2] 来源 Datasheet PDF
[3] 我不太确定，因为 Cubieboard 的每一个 GPIO 口似乎只能在开机时设置为读或者写二选一，而 DHT22 的读写都在一根线上。也许能用两个 GPIO 口并加少许电路来实现？
[4] 好吧其实一点都不简单方便。
[5] systemd 用户请参考 Gist 中的.timer .service等文件。
[6] 需分别生成日、周、月的图片，参见 [4] 中的三个 .timer 文件。

电子钱包与脱机支付

先说一下几个基本概念。

所谓电子钱包，就是卡内有一块 IC，（电子）现金以数据的形式直接存在 IC 内。不记名不挂失^{[来源请求]}。

脱机即不联网，脱机支付即为在不与银行通讯的情况下直接完成支付。电子现金使脱机支付成为可能。

有了银联闪付，在读卡器上直接拍卡就能完成支付，不需要密码也不用签字。嘛就是类似公交卡的那种体验啦…

顺带，往电子钱包里存钱叫做「圈存」，从电子钱包里体现叫做「圈提」，现在 ATM 机里似乎都能进行这两项操作。卡上带有「UPcash」字样，并且在限额大于 0 的卡都能进行此项操作（限额调整可在银行柜台办理）。

POS 机死机重启

当时我和往常一样，拿着工行的借记卡在超市用闪付结帐。

超市的 POS 机是中行的，一个小巧的「读卡器」通过连接线与 POS 机相连。使用时，只需将银行卡置于读卡器之上，读卡器显示扣款金额，「嘀——」，显示卡内余额。POS 机打印两份小条，一份商家留底，一份自己拿走，无需签名确认，完成。

那天，扣款时「读卡器」突然「死机重启」了。（嗯我确定那是在重启，我对画面中闪过的「Bootloader」等字样比较敏感（

当时我也没多想，又刷了两次：第二次依旧死机重启，第三次才成功支付。

核对存根

平常有保留各种票据的习惯，到宿舍后我翻出了上一次闪付时的小条，和这次的对比：

如图，左侧为我上一次支付时的存根，右侧为这次收到的存根。

可以看出，我在这三次拍卡前，卡内余额为 493.77 元。在第三次拍卡后，卡内余额为 252.00 元。

493.77 – 80.59 × 3 = 252.00

也就是说，前两次虽然死机了，但钱还是是被扣掉了。493.77 元的余额在扣了三次 80.59 元后变为了现在的 252.00 元。

超市没有记录

重复扣款这时，前不久还刚遇到过。商家那有记录，查一下就能发现问题，然后把钱退回来。即使商家那没记录，银行那总有了吧。但是这次不同。

我先找到了超市，超市给我了一份这样的记录：

如图，超市当天只有两笔（闪付）消费，左边是我的那一次，右边是路人甲的一次。

钱飞了

好了，事情到此也就明了了。

POS 机成功地从我的卡上扣款三次，但是由于自身故障，未留下前两次的扣款记录。
由于 POS 机本身未留有记录，超市在日后上传交易记录时也就不可能含那两笔交易。进而银行那也不会有这两笔记录。超市我不会收到那 161.18 元钱 （= 80.59 × 2），我的 161.18 元也不会回来。

再次强调，由于是脱机支付，POS 机不会立即联系银行进行确认，而是要日后商家心情好时再上传交易记录。如果交易记录没被上传，银行那也不会有记录。

我先后找了超市、银联、中行，就是没人认账。

打个比方，这就相当于收银员收了我的钞票后，当场撕掉了，而我却傻乎乎地交了三次。

最后

你们问我还支不支持电子现金脱机支付，我可以说无可奉告，但你们又不高兴，我怎么办？我的意思不是我支持它们这样乱扣我钱还不还。你们问我滋不滋瓷，我说滋瓷，我就明确告诉你这点。
至于你们呀，我感觉你们银行界还要学习一个… 你们非常熟悉金融的那一套理论，毕竟也是 too young，明白这意思吗？我告诉你们，我是生经百战，见得多了，西方的银行哪家没用过？你们要知道，美国的花莱旗比你们不知道高到哪里去了，我和他谈笑风生。其实你们呀，要提高自己的技术水平，识得唔识得呀？唉！我要为你们着急呀！真的。
你们有一个好，全世界什么业务，你们收费比谁都快，但问来问去的问题呀，too simple，sometimes naïve！
我很抱歉，我今天是以一个消费者跟你们讲，我不是写 POS 机代码的，但是我见得太多了，有必要告诉你一点人生的经验。我没有说要支持你们乱吞钱，没有任何这个意思。但是你必要问我对闪付滋不滋瓷，我怎么不滋瓷？它现在是新支付方式的代表，我怎么不滋瓷新技术？对不对？
但技术发展也要按中国的法律呀，对不对，当然消费者的选择权也很重要。你们呀，不要喜欢弄个大新闻，说离线支付不行了，有把新技术批判一番，你们呀，naïve，I am angry！
你们这样子不行！这算我得罪一次了。

最近才知道，美亚（amazon.com）上的东西是可以直接寄往国外的。似乎商品页面有注明“This item is also available for shipping to select countries outside the U.S.”字样的都行，我随便点了几个就没发现不支持的。

这导致了在其网站购买 Nexus 9 异常方便，免得找转运折腾什么的，看着靠谱用着安心。当然 US$ 33.33 的邮费也很可观。好在我这不用交关税，要是在加上 80 刀的关税什么的… 还是上淘宝吧（

虽然港版也出了… 但…还是网上买方便啊！再者船票也比邮费贵多了…

UPS 负责运送，9日上午（UTC+8）发件，15日中午到手，历时六天，应该还不算慢？

寄来的包裹长这样，点击大图有码见谅。大小盒子间只塞了几张纸，我大淘宝卖家比它不知道高到哪里去了。

机子就不贴图了，我拍的照片和工信部的有得一拼（

简单说下使用感受吧

手感比已故的 iPad 2 好很多。更轻、薄。嘛毕竟隔了几年的科技了，还拼不过可说不过去。应该和 iPad Air 比较？但我没怎么玩过所以没办法啦。

2G RAM 似乎不大，但使用一周下来还没遇到内存不够的情况。即在几个程序之间切换时，没有程序因为内存不足而清扫出门。

Lollipop，赞！原生大法好！

自带电源输出 5V 1.5A，作为一个有着 6700 mAh 电池的设备，不觉得 1.5A 有点太少了吗！实际充电的时候，在点亮屏幕、CPU 闲置的情况下，电池输入电流大概在 1A ~ 1.2A 之间浮动。虽然没有试过，估计从没电到充满插一个下午是要的吧……

最不满的一点是，音频输出底噪明显。比手上这台索尼猴机还要明显。视频/音乐等连续的音频输出带来的是连续稳定的噪声；按键声等带来的是断续的噪音，烦啊。肾板、魅族 M8、正在用的 Dell 本子没这问题；现在的 Xperia SP，之前用的华为和天语，还有旧的联想本子，也是不同程度的底噪。所以这问题其实挺普遍的？

本来没怎么关注这个东西，支持少非主流，IP over TCP，也是因为一些奇怪的事突然有了这方面需求了，才开始了解它。

SoftEther

目前在 Linux，服务器似乎只有 SoftEther 这个实现。这软件也是挺拼的，把各种流行的非主流的 VPN 协议都给实现了一遍，跨平台，GPL。还提供傻瓜化的 GUI 管理，中日英三语界面，简直就是部署 VPN 的大杀器。只是一来太重，二来对 RADIUS 支持不全，不太符合需求。

DIY

因为内部走的是 PPP，如果只是调用 pppd 并转发数据，由 pppd 负责用户认证等麻烦事，自己实现一个目测也不是太复杂。加上微软的官方文档甚详，近来又一直想学一下 Twisted 但又不知如何入手，决定来写一个试试。

托 Twisted 的简单易用，挺顺利地初步完成了这个 SSTP 服务器。

代码放在 GitHub 和 PyPI 上了，sorz/sstp-server 。

安装使用

供参考，详见sstpd --help：

sudo apt-get install python-dev python-pip python-twisted
sudo pip install sstp-server
sudo sstpd -c cert.pem --local 10.0.0.1 --remote 10.0.0.0/24

关于证书，请参考 HTTPS 证书相关教程。
别忘了建/etc/ppp/options.sstpd，一个例子：

name sstpd
require-mschap-v2
nologfd
nodefaultroute
ms-dns 8.8.8.8
ms-dns 8.8.4.4

需要 IPv6 支持的，可加参数--listen ::。

麻烦

折腾过程中遇到的主要障碍还是关于 PPP 的。简单地转发是不行的，因为每个 SSTP 包中只允许放入一个 PPP frame，需要自行分离出每个 frame。

PPP 这个古老的协议比预想中的要复杂。Windows 在 SSTP 中使用的其实是这个 HDLC-like Framing。找了一份 SSTP 客户端的代码，它是自行对两种格式进行了转换。好在后来发现 pppd 其实自身就支持 HDLC（sync 参数），于是成功偷懒。

但后来发现 HDLC 似乎需要 Linux 内核支持（CONFIG_PPP_SYNC_TTY = yes）。

更新：
果然偷懒失败了，用 HDLC 取巧的方法是不行的，偶尔会有 frame 被截断，后面就全乱了。于是还是老老实实地照着 RFC 1662 来做 framing，自行 (un)escape 一些字符。但是这样性能变得很糟糕，试着把这部分用 C 扩展重写了一遍。想来这还是我第一次出于解决问题的需要写 C 呢……

感谢 @deba12 指出了这个问题，并协助测试、改善性能。

安全性

目前这个实现其实是不完整的，没有实现 Crypto binding 部分，导致其可能遭受中间人攻击。

使用了 SSL 还会遭受中间人攻击？微软在文档末尾提供了一个这种攻击的情境，挺有意思的。

攻击者建立一个假 Wi-Fi AP，然后诱骗用户连接。
Wi-Fi 使用 802.11 EAP 进行认证，用户以为他是在登录 Wi-Fi，但实际上，攻击者将这个认证请求转发给了 SSTP（PPP） 服务器！用户确实在和真的认证服务器在对话，只不过认证的不是 Wi-Fi 而是 SSTP 服务。

Crypto binding 可以防止这种攻击，想详细了解请参见微软文档。
但实现这个有些复杂，我这边的使用情境暂时没有这个需求，就先放一放了。
（懒你就直说 _(:з」∠)_

这是一种基于域名的 VPN 智能翻越方案。不同于 chnroutes 这类通过维护一个 IP 地址列表来区分国内外网站的方案，基于域名的方式不受 IP 地址变动的影响。仅需维护一个相对很少有变化的域名列表即可。

dnsmasq 在 2.66 版之后加入了对 ipset 的支持，可将指定域名的 IP 解析后自动加入某一 ipset 中。 再配置路由规制，使该 ipset 中的 IP 走 VPN 即可。

感谢 @wzyboy 提供了此方案的思路。

大致流程

• 配置 VPN
• 配置 dnsmasq，指定域名
• 增加一个路由表，默认网关为 VPN
• 使用 iptables 匹配 ipset 并打上 mark
• 使用 ip rule 将打上 mark 的包送入该路由表

所需软件

• iproute2
• dnsmasq (>= 2.66, has ipset)
• iptables (with ipset and mark modules)

opkg update
opkg install ip ipset kmod-ipt-ipset dnsmasq-full

OpenWrt 默认的dnsmasq包并不包含 ipset 支持，需安装dnsmasq-full（感谢 @leavic 的提醒）。亦可修改 makefile 自行编译，以节省空间。

配置文件

列举一下涉及的各部分配置文件，供参考。

VPN

各类 VPN 均可，请参考 VPN overview。注意请勿将 VPN 设为默认路由。

rt_tables

添加outwall路由表。 走 VPN 的流量都将使用此表。

echo "200 outwall" >> /etc/iproute2/rt_tables

rc.local

使系统启动时创建一个名为outwall的 ipset。
在 /etc/rc.local 中添加：

# vi /etc/rc.local
ipset create outwall hash:ip

名字可以随便取，与 dnsmasq.conf 和 firewall.user 中的保持一致即可。

firewall.user

将匹配 ipset outwall的包全部标上 mark 8。
在 /etc/firewall.user 中添加：

# vi /etc/firewall.user
iptables -t mangle -A fwmark -m set --match-set outwall dst -j MARK --set-mark 8

打上 mark 以后，就可以指定它们所使用的路由表了。
mark 值可随便选，保持一致即可。若同时装有 qos-scripts，mark 可选一个较大的值，以防与其发生冲突。

VPN Post-connected Script

确保以下脚本在每次 VPN 连接建立后执行。
不同 VPN 的配置方法可能不同。 一个比较通用的方法是使用 Hotplug。

（我这次用的是 vpnc，所以比较偷懒地将脚本放在了/etc/vpnc/post-connect.d/下）

#!/bin/sh
ip route add 8.8.8.8 dev $TUNDEV
ip route add default dev $TUNDEV table outwall
ip rule add fwmark 8 table outwall

注意，须将$TUNDEV替换为 VPN 设备名，比如ppp0。

这段脚本有三个作用：

1. 让 8.8.8.8 走 VPN，防止 DNS 污染；
2. 由于 VPN 断线时相关路由会被自动删除，所以在需要每次连接时添加一次；
3. ip rule 在 VPN 断线时将手动删除（见下一节），切换至正常路由。

VPN Disconnect Script

见上节说明，须在 VPN 断线时 自动执行的脚本：

#!/bin/sh
ip rule del table outwall

dnsmasq.conf

请参考 dnsmasq man(8)。
修改 /etc/dnsmasq.conf，在其中加入需要翻越的域名。 格式如下：

server=/域名/8.8.8.8
ipset=/域名/outwall

• server将指定域名使用 8.8.8.8 查询（8.8.8.8 已配置为走 VPN，防止 DNS 污染）；
• ipset将指定域名的所有 IP 加入 ipset outwall中；
• 可在一行添加多个域名，如ipset=/twitter.com/t.co/outwall；
• google.com将同时匹配 google.com 和 plus.google.com。com将匹配所有 .com 结尾域名。

一个可供参考的配置如下， 该配置：

• 尽可能地让 Google 所有常用服务走 VPN
• 允许访问 Facebook、Twitter 和 YouTube
• 让 GitHub 的 CDN 走 VPN

server=/google.com/8.8.8.8
server=/googleusercontent.com/8.8.8.8
server=/gstatic.com/8.8.8.8
server=/googlehosted.com/8.8.8.8
server=/golang.org/8.8.8.8
server=/googleapis.com/8.8.8.8
ipset=/google.com/outwall
ipset=/googleusercontent.com/outwall
ipset=/gstatic.com/outwall
ipset=/googlehosted.com/outwall
ipset=/golang.org/outwall
ipset=/googleapis.com/outwall

server=/twitter.com/8.8.8.8
server=/twimg.com/8.8.8.8
server=/t.co/8.8.8.8
ipset=/twitter.com/outwall
ipset=/twimg.com/outwall
ipset=/t.co/outwall

server=/facebook.com/8.8.8.8
ipset=/facebook.com/outwall

server=/youtube.com/8.8.8.8
server=/ytimg.com/8.8.8.8
server=/ggpht.com/8.8.8.8
server=/youtu.be/8.8.8.8
server=/googlevideo.com/8.8.8.8
server=/youtube-nocookie.com/8.8.8.8
ipset=/youtube.com/outwall
ipset=/ytimg.com/outwall
ipset=/ggpht.com/outwall
ipset=/youtu.be/outwall
ipset=/googlevideo.com/outwall
ipset=/youtube-nocookie.com/outwall

server=/githubusercontent.com/8.8.8.8
server=/github.global.ssl.fastly.net/8.8.8.8
server=/githubapp.com/8.8.8.8
ipset=/githubusercontent.com/outwall
ipset=/github.global.ssl.fastly.net/outwall
ipset=/githubapp.com/outwall

关于 Shadowsocks

（更新于 2014-11-23）

补充说明一下，此方案亦可与 shadowsocks-libev 配合使用，配置起来会比 VPN 简单很多。自己用了几个月，体验良好。这里简单介绍一下配置方法。

1、在 shdowsocks.org 可以下载到已编译的 ipk 包，在 OpenWrt 上安装即可。

2、配置好 Shadowsocks，并运行，注意服务器那边需要支持 UDP 转发（请使用较新版并配好防火墙）。OpenWrt 中使用ss-redir代理 TCP 连接，使用ss-tunnel代理 DNS 查询。具体参数请参考范例：

ss-redir -c /etc/shadowsocks.json -l 1080
ss-tunnel -c /etc/shadowsocks.json -l 5533 -L 8.8.8.8:53 -u

3、在/etc/firewall.user中加入（参考）：

iptables -t nat -N shadowsocks
iptables -t nat -A shadowsocks -m set ! --match-set outwall dst -j RETURN
iptables -t nat -A shadowsocks -p tcp --syn -m connlimit --connlimit-above 32 -j RETURN
iptables -t nat -A shadowsocks -p tcp -j REDIRECT --to-ports 1080

iptables -t nat -A PREROUTING -s 192.168.0.0/16 -j shadowsocks

这将使匹配outwall（这个 IPSet）的 TCP 连接指向ss-redir。后者将为这些连接建立隧道并通过 Shadowsocks 协议加密发送。

4、/etc/dnsmasq.conf中不再使用8.8.8.8，而是使用127.0.0.1#5533，范例如下：

server=/google.com/127.0.0.1#5533
ipset=/google.com/outwall

这将使 dnsmasq 将 DNS 查询请求发送至ss-tunnel，后者在将其通过 SS 转送至 Google Public DNS。

由于不再涉及路由，不需要安装配置iproute2，不再需要使用-j MARK打标记。当然，也不用在配置 VPN 及相关脚本。

优点：方便配置，不管是路由器还是服务器。
缺点：只代理 TCP 连接，UDP、ICMP (ping) 等无法使用。