依云's Blog

众所周知，大部分无线网卡是不支持桥接操作的。

但是 VirtualBox 就是能，因为它做了特殊处理：来回改 MAC。

那么，我的 LXC、netns、KVM 啥的也想这么玩，成不？

实际上不仅能成，而且 Debian Wiki 还给出了两个方案。方案一是用 ebtables 来回改 MAC。不过我失败了，可能是 ebtables 不支持改完 MAC 再把包发往另外的网络接口吧。

方案二是内核的一个叫 Proxy ARP 的功能。设置起来超级简单：往/proc/sys/net/ipv4/conf/all/proxy_arp里写1，然后给需要的 IP 地址加一条 /32 路由项就可以了。

这方案相比起 VirtualBox 来是非常手动了，也不支持 DHCP 自动配置的 IP 地址，但好歹能用。至少微信备份能用。（火狐的 Wi-Fi 远程调试已经坏掉了，倒是那个「USB 调试」其实只要 adb 连接上就能用，不一定要走 USB 线。）

部分国内网络访问 GitHub 会很慢，严重拖慢了学习和开发效率。除了使用代理绕路之外，有没有什么简便的办法呢？最近我写了个脚本，用来测试所有已经的 GitHub IP 并计时，然后就可以挑一个访问快的写在 hosts 文件里了。

获取脚本请访问 gh-check。脚本依赖 Python 3 近期版本及 aiohttp。

中国大陆目前自然解析 github.com，通常会得到位于新加坡的 IP。然而这几个 IP 的访问速度经常不怎么好。我之前是手动尝试使用西雅图或者阿什本的 IP，但是它们也并不总是很流畅。现在，终于可以让数据说话了：

IP 来源于四个 GitHub 区域域名的解析结果，以及另外两个我自己通过 DNS 发现的。

检查分为两种：HTTP 和 SSH。默认两者都测试，可如上图中那样通过参数指定只测试一种协议。HTTP 测试时，会验证服务器的 TLS 证书。

我本地的 MediaWiki 的证书过期啦，干脆申请个免费证书好了。之所以用 HTTPS，是因为 MediaWiki 不喜欢不加密的 HTTP，会登录不了……

在网上寻找时，发现 certbot 就有 Cloudflare 的插件呢！这下就方便了。首先 pacman -S certbot-dns-cloudflare 装上，然后把自己的 Cloudflare 凭证信息写到一个 ini 文件里：

dns_cloudflare_email = cloudflare@example.com
dns_cloudflare_api_key = 0123456789abcdef0123456789abcdef01234567

就这么两行。保存好，设置好权限，然后就可以申请证书了：

sudo certbot certonly -d 域名列表 --dns-cloudflare --dns-cloudflare-credentials 凭证ini文件路径

稍微回答几个问题，证书就在 /etc/letsencrypt/live 下准备好啦。在 nginx 里配置一下就好了。

然后还要加个 cron 任务来更新证书（dcron 格式）：

@weekly         ID=cert-renew   certbot renew -q

这样就大功告成了。

首先 iw list 看是否支持。如果支持，那就

iw dev wlan0 interface add p2p0 type __p2pdev

这样其实并不会多出一个叫 p2p0 的网络接口。iw dev 能看到多了个「Unnamed/non-netdev」设备。不执行这个也可以连接上 WLAN Direct，但是当前的 managed Wi-Fi 连接会断掉。执行之后再连接，managed 连接会持续，iw dev 里会有两个 Unnamed，不知道何故。另外这个 type __p2pdev 加上去了我就不知道怎么删除了。试了几个命令，结果搞得内核 oops 了……

然后是 wpa_supplicant 配置文件：

ctrl_interface=/run/wpa_supplicant_p2p
ap_scan=1

device_name=起一个名字
device_type=1-0050F204-1

driver_param=use_p2p_group_interface=1

wpa_supplicant 跑起来。注意这里的接口名还是那个 managed 接口的。

wpa_supplicant -i wlan0 -c p2p_config.conf

然后 wpa_cli 连过去操作：

wpa_cli -p /run/wpa_supplicant_p2p

首先用 p2p_find 开启搜索。这时候对端设备能够看到自己了。使用 p2p_connect 对端MAC pbc go_intent=0 连接，在对端接受连接即可。go_intent=0 是让对方作为 group owner，这样对端 Android 才会提供 DHCP 服务（否则要本地提供了）。

然后就可以给自己添加 IP 地址了。此时是可以用 dhcpcd 的，然而直接跑的话它会抢走默认路由，所以知道地址范围之后手动加一个好了：

ip a add 192.168.49.22/24 dev p2p-wlan0-1

Android 设备的地址是 192.168.49.1。

之后就可以用 adb connect 然后 scrcpy 了。

PS: Android 很喜欢四十几的 IP 段呢。USB 网络共享是 192.168.42.129/24，Wi-Fi 网络共享是 192.168.43.1/24，而 WLAN Direct 是 192.168.49.1/24。不知道蓝牙网络共享是多少呢。

PPS: scrcpy 在我的 XZ2C 上运行完美，但是在 MIUI 10 上需要去开发者选项里开启选项「USB 调试（安全设置）」，否则会是「只读模式」，只能看，所有交互操作无效。

参考资料

• en:developers:p2p:howto [Linux Wireless]
• OMAP Wireless Connectivity NLCP WiFi Direct Configuration Scripts - Texas Instruments Wiki

很早之前，我在《Linux「真」全局 HTTP 代理方案》中介绍了 redsocks 方案。不过它只处理了 TCP，并没有处理 UDP，DNS 也是采用强制 TCP 的方式来处理的，再加上它本身还要将请求转发到真正的代理客户端，延迟比较高。然后，还可以结合 Wi-Fi 分享 或者网络命令空间，玩点更有趣的。

首先要有支持的代理客户端，比如 ss-redir。这个就不用多介绍了，配置好、跑起来即可。以下假设此代理跑在 127.0.0.1 的 $PPROT 端口上。

然后，TCP 的代理设置。使用的是和 redoscks 一样的方案。这个比较简单，除了有一点需要注意：DNAT 到 127.0.0.1 时，需要设置内核选项net.ipv4.conf.all.route_localnet=1。

最麻烦的是 UDP 的代理，使用的是 TPROXY。首先，需要把要走代理的数据包路由到本地。以下假设我们给要代理的数据包打上标签 1。那么执行：

ip rule add fwmark 1 lookup 100
ip route add local 0.0.0.0/0 dev lo table 100

那个 100 是路由表的编号，可以自己选一个喜欢的。

然后，对于转发流量（来自局域网或者另外的网络命名空间），直接把需要代理的数据包扔给 TPROXY 目标，并且打上对应的标签即可。而对于本地产生的流量，不仅要带有对应的标签，而且需要在 OUTPUT 链打上一个（与之前不同的）标签，触发 reroute check 才行。

最后，对需要代理的数据包设置 iptables 规则：

比如来自网络命名空间或者局域网的 IP 段 192.168.57.0/24 全部走代理：

iptables -t nat -A PREROUTING -p tcp -s 192.168.57.0/24 ! -d 192.168.57.0/24 -j DNAT --to-destination 127.0.0.1:$PPROT
iptables -t mangle -A PREROUTING -p udp -s 192.168.57.0/24 ! -d 192.168.57.0/24 -j TPROXY --on-port $PPROT --on-ip 127.0.0.1 --tproxy-mark 1/1

有一个很讨厌的公司叫「深信服」，英文名叫「Sangfor」。它开发的私有协议的 SSL VPN 客户端 EasyConnect 终于支持 Ubuntu 了，然而我没能在 Arch Linux 上正确地把它跑起来。图形界面是 electron 之类的，这部分没有问题。但有一个会往 /usr/share 下写日志的 root 进程，应该是负责真正的 VPN 创建的，死活连不上。

那么就在 Windows 虚拟机里跑吧。所以我的 Linux 系统需要通过 Windows 访问部分网络了。只是 HTTP 的话倒是可以装个 HTTP 代理搞定，但是我还要连 ssh 的。

正文开始了。其实整个过程并不难，关键在于很难找到资料。

首先，当然是给 Windows 一张 host only 的网卡，用于两个系统之间的连接。以及，把那个 VPN 连上。

然后，打开「网络设置」，选择「更改适配器选项」。右键单击要被共享的网络适配器（比如此例中是那张 Sangfor VPN 的网卡），选择「属性」。

选择「共享」选项卡，把第一个框给勾选上，下边下拉菜单选择那张 host only 的适配器。确定。

就这样，OK 了。

要注意的是，此操作会将网卡的 IP 强制设置为「192.168.137.1」。就像图中可以看到的那样，微软总喜欢「提供策略，而非机制」。假定你是给你的家庭共享。假定你要共享的是 Internet 连接（本例中其实是 VPN 连接）。所以它也假定了你的「家庭」网络中 Windows 可以随意选择 IP 地址，假定你需要 DHCP 服务。

Linux 这边配置起来就容易多了。Virtualbox 的 vboxnet0 接口本来用的是 192.168.56.0/24 网段，但是给它配置另外的 IP 地址，往它里边扔它不了解的目标地址的包，它也不介意的。

sudo ip a add 192.168.137.2/24 dev vboxnet0
sudo ip r add 172.16.2.9/32 via 192.168.137.1

以上给 vboxnet0 添加了 IP 地址，并且让需要走 VPN 的目标地址（172.16.2.9）走 Windows 的网络。

PS: 开着防火墙的话，Windows 10 默认是忽略 ping 的。在防火墙的「入站规则」里启用「文件和打印机共享(回显请求—ICMPv4-In)」之后才能 ping 它。

另见阿森人的《伪·如何在 Linux 下使用深信服 SSL VPN》一文。

家里和公司电脑连接，因为厌倦了一个个做端口映射，有些还因为安全原因得走 ssh，所以决定弄个 VPN。之前使用过 OpenVPN，然而现在懒得再去配置 OpenVPN 的证书了，所以决定尝试一下新东西。

首先，去 WireGuard 官网上转了一圈，结果还是没弄明白怎么配置。后来尝试了一下 demo，把服务端和客户端的脚本分别看了一下，才弄明白。其实在 WireGuard 里，客户端和服务端基本是平等的，差别只是谁主动连接谁而已。双方都会监听一个 UDP 端口。双方都需要一对密钥。双方都需要把对方的公钥加进来。最后一步，谁主动连接，谁就是客户端。因为家里路由器有公网 IP，我做了端口映射，所以我当然是从公司连家里方便了，用不着麻烦的打洞脚本。

首先 pacman -S wireguard-tools 安装。这也会安装上 WireGuard 的内核模块。然后使用熟悉的 ip 命令添加并配置 WireGuard 的网络接口：

# 生成密钥对
wg genkey | tee privatekey | wg pubkey > publickey

sudo ip link add dev wg0 type wireguard
sudo ip address add dev wg0 192.168.58.1/24
sudo wg set wg0 listen-port 60010 private-key privatekey
sudo ip link set wg0 up

这是我家里的配置。使用的是网段 192.168.58.0/24，因为 56 是 vbox 虚拟机用的，57 分配给 lxc 和我的网络命名空间了。指定了一下监听的端口号。我把之前给 mosh 配置了转发的端口号中最高的那个挪用了。

公司里也是同时的配置，只是不需要指定监听端口号，然后把家里那边设置成 peer，并且连过去（相同的命令我没写）：

sudo wg set wg0 private-key privatekey peer 这里是公钥 endpoint 家里的IP:60010 allowed-ips 0.0.0.0/0 persistent-keepalive 180

allowed-ips 指定过来的 IP。这里没怎么限制。persistent-keepalive 是为 NAT 设置的。WireGuard 本来很安静，不需要说话的时候就不说话，但是要往 NAT 后边的主机发送信息，需要经常通信，让 NAT 记得对应的映射关系。

然后家里那边也需要添加一下公司这边的公钥：

sudo wg set wg0 peer YiyFylL+1Dr3j2Cyf0lwXQYz2qaNwm3XyV5YvMFp3Vs= allowed-ips 192.168.58.2/32

IP 限制加上也是没有问题的。这里就不用加上 endpoint 了，它连过来的时候自然就知道了。WireGuard 是支持漫游的，也就是说，双方不管谁的地址变动了，WireGuard 在看到对方从新地址说话的时候，就会记住它的新地址（跟 mosh 一样，不过是双向的）。所以双方要是一直保持在线，并且通信足够频繁的话（比如配置 persistent-keepalive），两边的 IP 都不固定也不影响的。

最后，用得不错，可以把这几条命令写到一个 systemd service 文件里，就可以不用每次敲一串命令了，也可以做到联网后自动启动。

刚刚找了一下，其实之前使用的证书什么的还在，而且还没过期。而且因为弄 nghttpx，用了一下 xca，比 easy-rsa 好用很多呢。不过 WireGuard 的双向漫游很棒啊～

最近 #archlinux-cn 又流行玩 teeworlds 了，然而我却连不上那个服务器。

情况很奇怪。我能 ping 通服务器 IP，TCP 连接也正常，UDP traceroute 也表现得很正常（对关闭端口能够完成，对开放端口会在最后一跳开始得到一堆星号），并且我连接的时候，服务器能看到我在连接。也就是说，TCP 和 ICMP 都正常，UDP 上行正常，下行出了状况。

难道是有防火墙？首先呢，我能连接其它服务器，说明我这边没有问题；大部分人能连接上服务器，说明服务器那边也没有问题。所以，问题出在路上。也确实有另外的北京联通用户连不上这个服务器。但是很奇怪啊，为什么单单只是这一个 IP 的 UDP 包丢失了呢？

于是继续试验。从最简单的开始，用 netcat / socat 尝试通讯。方向反过来，我监听，服务器那边连接。端口是我在路由器上做过端口映射的。结果是正常的。再来，服务器那边监听，我往那边发，果然我就收不到包了。按理说，UDP 双方是对等的，不应该换了个方向就出问题呀。难道是因为端口映射？Wireshark 抓包看到本地使用的端口号之后，在路由器上映射一下，果然就通了！

然后，我注意到了一件十分诡异的事情：虽然我和服务器能够通讯了，但是我的 Wireshark 上只显示了我发出去的包，却看不到回来的包！我抓包时按服务器 IP 做了过滤，所以，回来的包的源 IP 不是服务器的地址！

重新抓包一看，果然。服务器 IP 是 202.118.17.142，但是回来的包的源 IP 变成了 121.22.88.41……看起来这是联通的设备，在下行 traceroute 时能够看到有节点与它 IP 相似（121.22.88.1）。原来又是这著名的「联不通」又干坏事了 -_-|||

虽然 socat 接收 UDP 时不介意源 IP 变化了，但是 teeworlds 介意啊。并且 NAT 那边也会不知所措。所以，首先得告诉路由器把来自这个 IP 的 UDP 包全部扔给我：

ssh 192.168.1.1 iptables -I FORWARD -i ppp0.2 -p udp -s 121.22.88.41 -j ACCEPT

于是数据包有了。接下来是修正源 IP。我试过 SNAT，无效。这东西似乎只对本地发出的包有用？于是我又用 netfilter_queue 了。这东西很强大呢～一个简单的 Python 脚本搞定：

#!/usr/bin/env python3

from netfilterqueue import NetfilterQueue
from scapy.all import *

def main(pkt):
  p = IP(pkt.get_payload())
  # print('recv', p)
  p.src = '202.118.17.142'
  p.chksum = None
  p[UDP].chksum = None
  pkt.set_payload(bytes(p))
  # print('fixed to', p)
  print('.', flush=True, end='')
  pkt.accept()

conf.color_theme = DefaultTheme()
nfqueue = NetfilterQueue()
nfqueue.bind(1, main)
try:
  nfqueue.run()
except KeyboardInterrupt:
  pass

然后是 iptables 命令：

sudo iptables -I INPUT -s 121.22.88.41 -p udp -j NFQUEUE --queue-num 1 --queue-bypass

scapy 这个神奇的网络库在 Arch 官方源里叫「scapy3k」。Python 的 netfilterqueue 模块需要用我自己修改过的这个版本。

2017年7月30日更新：Python 的依赖有点麻烦，所以我又写了个 Rust 版本，放在 GitHub 上了。

2017年02月08日更新：已经无法通过 InoReader 的 OAuth 功能登录。现只能通过提交 InoReader 账号和密码到 Reabble 的方式登录。我正考虑放弃此服务。

InoReader 的核心在于阅读。Kindle 的核心也在于阅读。

InoReader 的重点在于，它是在线 RSS 阅读器，手机 app 还支持离线，不仅可以在电脑前研读，还可以随时随地使用手机来闲读。可有个问题：长时间盯着 LCD 屏幕看，对眼睛不好！

而这正是使用电子墨水的阅读器——如 Kindle——所解决的问题。所以，怎么把两者结合起来呢？

土木坛子介绍了一个名为 kindle4rss 的服务，通过电子邮件推送 RSS 源。其实我之前也听朋友说过，RSS 源是可以推送到 Kindle 的。但是这样是针对单个的 RSS 设置，推送到 Kindle 的部分不能和其它地方的阅读同步。然后，我顺着 kindle4rss 看了一下，忽然眼前一亮：他们基于 InoReader 的 API 做了一个网页版的、适合 Kindle 使用的阅读器！

就是 Reabble 啦。其实它支持各种浏览器的，只是配色、操作方式是为 Kindle 优化的。（说起来，我挺讨厌像美团招聘或者 AirDroid 局域网 HTTPS 版那样故意不支持特定客户端的行为，明明能用的，却偏偏不让用户用。）

直接访问就可以试用啦。黑白的界面，在电脑上看着挺丑的，不过在 Kindle 上看就大不一样啦。左边是文章列表界面（调整过选项，隐藏了侧栏和已读文章），右边是文章阅读界面（打开了菜单）：

在 Kindle 上的体验非常好。而且 Kindle 上的登录做得非常棒：只需要在电脑上通过 InoReader 的 OAuth 授权登录，之后就可以获得一串代码，在 Kindle 那边填写就可以了。我的 InoReader 是用 Google 账号登录的，要是让我在 Kindle 上登录我大概会直接放弃的。

它要求有 Wi-Fi 网络（废话，Kindle 那个破浏览器又不支持离线模式）。不过这对我来说不是问题。真要没 Wi-Fi 的话，用手机开个热点用也成。

不过有些小问题：

• 不支持广播和赞，只支持加星标。
• 侧栏里没有未读文章的项、以及星标数不能隐藏。
• 免费用户只能每天阅读15篇文章，但是并没有阅读到那么多就会出现提示。好像重新打开又可以继续读了。

最后，这服务收费也非常便宜，一年只要18RMB，订更久还会更便宜～最重要的是，它的支付方式对于我很方便！（谁去帮 InoReader 接入支付宝或者微信支付吧，这样我就不用看广告了～）另外，推荐它的话，可以获赠两年的使用权。

之前做了一个知乎专栏转RSS的网关，这次又写了个针对知乎动态的。感兴趣的话去 https://rss.lilydjwg.me/ 看看用法吧。

此功能只支持用户的回答和发布文章两个操作。别的操作，比如赞了答案啦，关注了专栏啦，参加了 live 啦，没有实质性的内容，又可能会有非常多，不适合 RSS 这种面向内容发布的东西，所以就过滤掉了。即使如此，程序每次访问取最近40条动态，缓存有好几个小时，所以对于活跃的用户是可能漏掉一些动态的。反正现在信息这么多，漏了就漏了吧，去读读别的东西呗。

知乎这次暴露出来的 API 有点意思。它有一个 include 参数，看起来是指定要返回哪些字段的。看起来知乎也在解决 GitHub 遇到的同样的问题：RESTful API 太不灵活了。只是，为什么要造轮子啊，GraphQL 不是挺好的吗……