qyb的博客

传统 DNS 由于采用了 UDP 协议，以及 53 公开端口，导致很容易被运营商劫持，或者被不知道哪里的设备来一个抢先应答... 许多厂商也包括标准化组织一直在想办法改进它：

1. DNSSEC，这个提出得最早，目的之一是确认应答的有效性。我理解这个方案解决了权威域名解析的安全基础架构，但还得依赖于为最终用户提供服务的转发服务器的实现
2. DNS over TLS & DNS over HTTPS(HTTP/2)，这两项技术保障用户访问转发服务的安全传输，是 DNS 安全体系中另外重要的一环。DoT 是传统 DNS tcp 协议传输增加 TLS 通道，DoH 具体实现则有两个变种，当前正在标准化的阶段
3. 国际几个 Public Resolver 大厂都支持上述两类连接，包括 1.1.1.1、9.9.9.9，以及谷歌的 8.8.8.8
4. 但是在本地解析服务的部署上，变化要缓慢得多。当前几个重要的进展是：a) Android Pie 支持 DoT；b) systemd-resolved release-239 支持 DoT(2018年6月)；c) firefox 62 将正式支持 DoH

安全 DNS 是安全网络环境的起点，由于我在过去配置家庭路由器中碰到的种种不靠谱，打算自己搞一个安全 DNS 服务，希望能为净化大环境起到一些微小的贡献

在当前这个时间点，要使用上安全 DNS 对普通人还是有一点费劲，要做的事情不仅仅是架 Server，而应该是一整套解决方案。正在摸索中...

升级到了 Drupal 7.x 的最新代码，更换了一个对移动设备友好的布局模板；接下来打算把最近关于 DNS 学习到的知识整理发表出来

网易博客关闭，越发觉得独立的必要性

https://press.one/p/address/v?s=d1b5c197542e5c30054c3b672124791d8c6c9053...

参考 https://eparon.me/2016/09/09/rpi3-enterprise-wifi.html

最核心的工作：

配置文件内容见下：我司的 Phase 2 authentication 认证用的是 MSCHAPV2/无证书，请酌情修补

country=CN
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
network={
ssid="SOHU.COM-2.4G"
priority=1
proto=RSN
key_mgmt=WPA-EAP
pairwise=CCMP
auth_alg=OPEN
eap=PEAP
identity="qiuyingbo"
password=hash:XXXXXXXXXXXXXXXXXXXXXX
phase1="peaplabel=0"
phase2="auth=MSCHAPV2"
}

ChinaDNS 的说明语焉不详，一直觉得是伪科学——它的基本原理是
1. 把同一个域名送到国内国际两个域名上解析，比如 114 和 8
2. 如果从 114 得到的是一个国际IP （国内DNS说它是一个外国网站），那么外国网站自然不如 8 返回的可信

前两天看了 V2EX 上的一条讨论 https://www.v2ex.com/t/460686 , rio 也表示：“ChinaDNS 分流基于一个核心假设，就是被污染域名都解析到非 China IP。这个假设在目前是成立的，但似乎并没有什么客观原因认为它一定成立”

是啊，理论上可以把 google.com 返回成金盾官网呢，向群众展示厉国的神力

前文：树莓派做路由器 2018.03 (Part 2) hostapd 和 RTL8188CUS 网卡，如何在 Raspbian Stretch/Kernel 4.9.x 下工作？

三个月之后，随着 Raspbian 把内核从 4.9.x LTS 升级到下一个 LTS 4.14.x，麻烦又来了
在这三个月里又断断续续尝试了 Pi Zero W（有内置的 BCM 无线网卡），以及 Ralink 的 RT3070 USB 网卡等，当前的结论是：
a. RT3070 做 AP 最稳定
b. Pi Zero W 的内置无线网卡能用，网上甚至有让它同时做 STA + AP 的例子，但兼容性不那么好，无法支持 chromecast 的 chrome tab 串流
c. RTL8188CUS 在 4.9.x 下尚能较稳定的工作，但到了 4.14.x 下还需要摸索摸索

1. 内核主线里有一个 rtl8192cu 的模块，来自 realtek 的驱动源码
2. 后来主线里又有了一个 rtl8xxxu 的模块，似乎是 realtek 自己不用心维护驱动，所以社区社区自己开干。据说这个还是靠谱的，但——直到目前还没有缺省支持 0bda:8176 (需要编译时额外增加 UNTEST 选项)，以及还不支持 AP Mode
3. 为了解决 rtl8192cu 的问题，所以有了 https://github.com/pvaret/rtl8192cu-fixes.git 项目，它编译后的模块名改成了 8192cu 以避免和主线冲突；至少直到 4.9.x 内核，还是能和 hostapd patch 后的 rtl871xdrv 一起愉快的工作
4. 但是到了 4.14.x，rtl871xdrv 出问题了，报 ioctl[RTL_IOCTL_HOSTAPD]: Operation not supported ，可参考 https://forum.odroid.com/viewtopic.php?f=146&t=29195#p208592
5. 话说 odroid.com 这个公司似乎是专门销售网络硬件方案的，其中 WiFi module #3 就是用 realtek 的这款芯片，所以它必须解决问题。。。
6. 然后该公司发现，使用4.14.x主线的 rtl8192cu就能用 hostapd 的 nl80211 驱动来跑 AP，甚至无需给 hostapd 2.6 打补丁：https://forum.odroid.com/viewtopic.php?f=146&t=27287
7. 按照它给的方法，确实能启动热点，客户机也能连上，但就最近两天的情况看并不稳定

...需要时间继续检验...

对我等 VPS 简单应用来说，最大的好处就是 shadowsocks-libev 和 simple-obfs 都已经打好包了...

另外，16.04 里面的 postfix 一个很愚蠢且讨厌的 bug 看起来也解决了。。。

作为一个音箱，哪怕是冠以智能音箱的名义，也是必须要能满足用户想放什么声音，就能放出什么的需求的

所以，如果玩家没有 Spotify 之类的流媒体帐号，又或者是有独家珍藏的 MP3 file，怎样在 49$ 的设备上把声音播放出来呢？Echo dot 可以作为 bluetooth speaker 和手机配对，Google Home Mini 自然就是 chromecast 了

想到树莓派非常适合做家庭媒体中心，调研了一番从 Linux 主机 cast 到 chromecast 设备的方案。。。被 Raspbian Stretch 内置的 mkchromecast 似乎必须要一个桌面环境，抛弃。。。然后发现 stream2chromecast 出乎意料的靠谱，至少目前放个 mp3 ，命令行再控制一下音量是毫无问题的。。。

下一步就是开发 Alexa skills or Google Actions 让我可以赖在沙发上指挥这个树莓派了...

再等过两天 chromecast 到货后试一下 stream2chromecast 播放视频的能力；以及要是有功夫看看 VLC 3.0 能不能在 Raspbian Stretch 上编译通过和命令行工具 cvlc 的情况

UPDATE: 2018/03/21

1. qyt 今天提示我有一个 My Media for Amazon Alexa，上亚马逊看了一下评分，还真的很高
2. chromecast 2Gen 到货，stream2chromecast 投 mp4 视频毫无问题；VLC 3.0 的编译放弃了，steam2chromecast 是 python 开发的已然足够方便

虽然搭树莓派的最初原因只是想使用 Google Home Mini，但这个跑起来后不可避免的就想用它来带其它设备上网，毕竟 iOS 装个 ss 客户端还是挺麻烦的不是？

研究一番，发现 tcp 流量分发异常简单

1. sudo apt install ipset
2. 然后创建中国地区的网络地址表，以及生成 ipset 的脚本；可以放在 cron 里每周更新一下
   • 从 https://github.com/17mon/china_ip_list 下载来自 ipip.net 最专业的国内IP表
   • echo "ipset -N chnroute hash:net maxelem 65536">chnroute.sh; chmod +x chnroute.sh; for i in `cat china_ip_list.txt`; do echo "ipset add chnroute "$i >>chnroute.sh; done
3. 每次启动系统的时候首先执行一次 chnroute.sh，最后在 iptables 设置 bypass 的命令中，增加如下一行
   • iptables -t nat -A SHADOWSOCKS -p tcp -m set --match-set chnroute dst -j RETURN

   现在可以访问一下国内的网站看看是否正确寻路出去了

看其它人的配置，往往还有 ChinaDNS 一项；仔细思索了一下它号称的原理，觉得从逻辑上投毒同正常业务的DNS海内外解析无法分辨的，如果仅仅依赖一个 chnroute.txt 完全做不到信任新浪的国内解析但不信任谷歌的国内解析。。。所以就不部署它了

前言：写于 2018.03，分成三篇blog，介绍为了在家里使用 Google Home Mini 而进行的一系列努力；
本文为第三部分，进阶路由配置，github 官方页面上相应的 iptables 配置已经介绍的很全面了；本文只描述几个特定的坑
第一部分：树莓派做路由器 2018.03 (Part 1) 最基础的Hotspot配置知识
第二部分：树莓派做路由器 2018.03 (Part 2) hostapd 和 RTL8188CUS 网卡，如何在 Raspbian Stretch/Kernel 4.9.x 下工作？

从源码编译 https://github.com/shadowsocks/shadowsocks-libev#linux 和 https://github.com/shadowsocks/simple-obfs 非常简单，毕竟树莓派系统是一个很完整的 Debian Stretch 变种，首先安装依赖的包，然后从源码 clone 下来按说明编译和配置即可

• sudo apt install --no-install-recommends gettext build-essential autoconf libtool libpcre3-dev asciidoc xmlto libev-dev libc-ares-dev automake libmbedtls-dev libsodium-dev
• 。。。略去官网里的 iptables 以及 ss-redir 配置 https://github.com/shadowsocks/shadowsocks-libev#transparent-proxy

因为这个树莓派目的很简单，只是为了服务 Google Home Mini，不需要复杂的国内国际流量区分，所有流量统统全局路由出去；为了避免投毒只是简单的自己搭了一个 DNS 转发

• ss-tunnel -c /etc/shadowsocks-libev/crown2.json -l 5353 -L 8.8.8.8:53 -u -f /var/run/ss-tunnel.pid
• 如果是在 rc.local 里启动 ss-tunnel 可能出现启动不了的情况。参考 https://www.v2ex.com/t/348171 加上 "sleep 15 && " 解决问题

使用 dig www.youtube.com @127.0.0.1 -p 5353 测试一下

最后把 dnsmasq 作为真实 dns server，ss-tunnel 做 upstream，让 dnsmasq 做一层缓存；这样最终 /etc/dnsmasq.conf 配置如下

• port=53
  no-resolv
  no-poll
  server=127.0.0.1#5353
  interface=wlan0
  dhcp-range=
  dhcp-option=option:router,192.168.x.1
  dhcp-option=option:dns-server,192.168.x.1

注意 dnsmasq 启动 DNS Server 之后，resolvconf 会自动将 /etc/resolv.conf 中的 nameserver 更改为 127.0.0.1

现在对于接入的其它设备比如 Amazon Echo dot 已经能成功接收来自 CNN/BBC 的新闻了；但对 Google 家族的硬件还不够。它不理会 DHCP 的 DNS-Server 配置，固执的使用自己的 DNS Server 进行解析

• 参考 https://github.com/qiwihui/hiwifi-ss/issues/106 和 https://gist.github.com/willwhui/28e8896b6e4560f1cf0d32a5acf501f3 搞定
• Google Home Mini 联网之后，我的 LG Watch Style 现在也正常通过该路由器连上 Play 并更新到 8.0 了！！

附录：在解决问题中发现的其它可能有帮助的链接

• https://github.com/shadowsocks/shadowsocks-libev/issues/1252
• http://blog.csdn.net/lvshaorong/article/details/53203674 【推荐】

又附：本系列的后继 关于路由器配置海内外流量分发