全新 VPN 翻墙技术 WireGuard 简单教程攻略

来源:https://yuesheng01.blogspot.com/2018/07/vpn-wireguard.html

今天闲来没事干浏览手机的时候, 在手机主页左侧的Feed 新闻推荐页面推送了一个新闻。大意是说,美国的一个参议员给美国技术协会写了一篇公开信,内容是希望政府单位能够淘汰老旧的VPN技术,使用全新的WireGuard 作为替代。文章还提到,如果使用以前的VPN技术,一个数据包传输大概要经过7次的复制转发,十分的浪费带宽和资源。

心想既然美国参议员都这么建议了说明这个WireGuard的确是个好东西,于是经过一番google 后,成功进行了跳墙。好了废话不多说,上硬货:

一、准备工作


我身边只有MAC一台,所以我以此作为基本的进行讲解(估计其他版本差别也不是太大)。

首选,大家都知道VPN也少不了C-S(客户-服务器)的模式。所以找一个靠谱的服务器,现成的最好。那么就推荐一个AzireVPN. 这是一个付费的VPN服务提供商但是却提供 免费的WireGuard 服务。也就是所有的WireGuard都是无限期免费使用。啥都不多说人家给我们免费使用了还说什么。

官方公告: 
Our WireGuard tunnel is currently free for everyone
Our internal tests has been running smoothly, therefore we are now interested in testing our WireGuard infrastructure at larger scale. For this reason, we decided to open up ours WireGuard servers for free. Simply sign up to connect to all of ours WireGuard servers, available in each of ours locations.
所以,赶紧去注册一下,获取帐号激活账号就好。

二、安装

1、首选Mac电脑默认没有安装HomeBrew,所以我们需要安装HomeBrew。
打开终端:复制粘贴下面code到你的终端中回车。

 /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
2、等待homeBrew下载安装结束后。安装wireguard
 brew install wireguard-tools jq
3、等待结束后添加AzireVpn提供的服务器脚本
 curl -LO https://www.azirevpn.com/dl/azirevpn-wg.sh && chmod +x ./azirevpn-wg.sh && ./azirevpn-wg.sh
这个过程中你会获取到相应的服务器地址以及名称类似于下图:


4、启动wireguard
好了所有都安装都完成了,下面就是启动了。寻找对应的上图中的框框中提示的,里面已经含有了启动代码,所以复制粘贴启动就可以了

 wg-quick up azirevpn-us1 
5、暂停wireguard
 wg-quick down azirevpn-us1 
三、Android 客户端

1、官方提供的Android 客户端软件,下载软件后再从这个配置连接下载配置信息,打开手机软件选择导入即可。

2、这个客户端是独立存在的,不需要我们手动配置参数,直接导入下载的配置使用就行。

四、后记

再怎么说服务器不是自己搭建的,所以随时都有可能被停用。后期找到相应的服务器搭建方法后再补充。

“未阅先焚” 微信朋友圈图片过滤功能分析

来源: https://citizenlab.ca/2018/08/%E6%9C%AA%E9%98%85%E5%85%88%E7%84%9A%EF%BC%9A%E5%BE%AE%E4%BF%A1%E6%9C%8B%E5%8F%8B%E5%9C%88%E5%9B%BE%E7%89%87%E8%BF%87%E6%BB%A4%E5%8A%9F%E8%83%BD%E5%88%86%E6%9E%90/

阅读报告全文(英文)



本报告分析了微信朋友圈上的敏感图片过滤技术。微信是中国腾讯控股有限公司旗下的即时通讯应用,目前是中国最受欢迎的聊天软件之一,也是全球排名第四的最流行聊天软件。朋友圈是微信上最常用的功能之一,其中图片是用户最期望看到的内容分享形式。

根据中国相关法律法规,互联网公司往往需要对内容进行过滤。公民实验室此前的研究报告发现了微信的“一APP两制”关键词过滤机制,在新浪微博Tom-Skype和新浪UC等即时通讯软件,以及直播平台上的审查机制。此前,我们留意到微信除了过滤关键词,部分与敏感事件相关的图片也会被审查。

主要发现
  • 微信采用了两种不同的算法过滤朋友圈中的敏感图片:一种是基于光学字符识别(Optical character Recognition)的文字检测方法,该方法用以过滤包含敏感词的图片;另一种是基于图像相似度的对比,该算法用以过滤与微信不良图片数据库中的图片相似或吻合的图片。
  • 我们发现微信采用的文字识别算法与大部分文字识别算法有所相通,即其对包含文字的图像进行灰度化(grayscale)和通过斑点合并(blob merging)来识别文字。
  • 微信基于图片相似度的的图片过滤算法并没有使用机器学习来判别目标图片是否属于某个不良图片类别。
  • 在研究这两种不同算法的同时,我们发现用以检测不良内容的技术同样可以被用来反审查。
  • 通过分析了解文字识别算法和图片相似度检测算法,我们发现了这两种算法并非万无一失。算法的弱点让用户得以通过编辑图片,使经过编辑的图片与原敏感图片在能够被普通读者识别理解的同时欺骗机器算法,从而不被过滤。

柏拉图:地穴寓言



来源: https://zh.wikipedia.org/wiki/%E5%9C%B0%E7%A9%B4%E5%AF%93%E8%A8%80

苏格拉底描述了一个地下洞穴住所,洞里有一条宽阔的通道通向地面。这个山洞里居住着终生被关押在那里的囚犯。他们被捆绑着大腿和脖子坐在那里,以致他们只能朝前看到洞穴的墙壁,而不能转身回头顾望。因此,他们永远看不到背后的出口,也根本不知道有这么一个出口。他们也不能看到自己和其他囚犯。他们唯一能看到的是他们面对的墙壁。他们的住所被身后远方高处燃烧的火炬照亮。囚犯只能看见这唯一的亮光,照亮着墙壁。但是看不见光源。在墙上他们只能看见光影。

监狱内部同火炬之间,有一堵不会遮挡光线的矮墙。沿着这堵墙壁,有人来回穿梭,搬运着不同的物品,包括一些用石头和木头做的人体和其他生物模型。这些物体高出那堵矮墙,但是他们的搬运者比墙低。其中的一些搬运者相互交谈着,另一些则保持沉默。

由于囚犯面对洞穴墙壁,那些来回移动的物体,在墙上投射的阴影,被穴居人看见当作会移动的影子。但他们想到有人在搬运这些东西。当有人说话时,洞壁上的回声,就如同那些影子自己在讲话一样。因此,囚犯以为那些影子会说话。他们把这些影像当作生物,把所有发生的事情理解为这些生物的行为。墙上演绎的事情,对他们来说都是真相,当然是真实的。他们从这些影子中研发出一整套学问,试图从它们的出场和动作中,找出一系列规律,并且预告将要发生地事情。那些预测最准确的人,还会得到嘉奖。

接着,苏格拉底问Glaukon(苏格拉底的谈话对象),如果给一名囚犯松绑,让他站起来,转身向出口望去,看见这些以往所见的影子的原型,能否想象这时会发生什么?这个人可能会在强光刺激下痛苦不堪,产生错乱。相比于过去熟悉的光影,他可能会认为届时所看到的东西不是现实的。因此,他可能希望重新返回自己习惯的位置。因为他相信只有在洞壁上能看见真相。而不去会相信一个善意解放者的相反说教。

如果使用武力将松绑的囚徒从洞穴中拖出来,穿过对他来说陡峭难行的通道,来到地面,他也许会觉得特别别扭,愈发神志错乱。因为璀璨的阳光会使他睁不开眼,开始时什么都看不见。慢慢地他也许会适应看见的新鲜事物。其过程也许是首先识别光影,然后是水中的倒影,最终才是人和事物本身。如果往上看,他也许会先习惯夜晚的星空,然后才是白天的日光,最后他也许才敢于直接目视太阳,从而感受太阳的独特之处。只有这时他才能理解,太阳造就了光影。有了这些经历和认识,他应该不再愿意回到洞穴,去探究那里的光影学问,获取其它囚徒的赞誉。

如果他还是回到故地,那么他肯定需要重新慢慢地适应洞穴里的黑暗。由此他肯定会在一段时间内,落后其它囚徒对后续光影估算能力。而洞里其它的囚徒则会认为,他在上面把眼睛弄坏了。他们会嘲笑他,觉得离开洞穴显然是宗蚀本生意,根本不值得一试。如果有人试图解放他们,把他们带到地上,他们会杀了他,如果可能的话。

在 Ubuntu 部署 VPN 隧道 WireGuard

来源: https://steemit.com/cn/@curl/ubuntu-vpn-wireguard
内容修订:https://github.com/aturl/awesome-anti-gfw





关于 WireGuard

WireGuard 是简单、快速、高效并且安全的开源 VPN 软件,它采用先进的加密协议,基于 Linux 内核实现。
WireGuard 项目官方网站 https://www.wireguard.com/
WireGuard 源代码由开发者自我托管,代码仓库 https://git.zx2c4.com/WireGuard/
WireGuard 源代码在 GitHub 的镜像仓库 https://github.com/WireGuard

在服务器端部署 WireGuard

WireGuard 跨平台,参照官方给出的快速安装指南 https://www.wireguard.com/install/

服务器环境以 Ubuntu 系统为例

生成公钥、私钥、共享密钥

sudo mkdir -p /etc/wireguard && sudo chmod 0777 /etc/wireguard && cd /etc/wireguard
umask 077
wg genkey | tee privatekey | wg pubkey > publickey | wg genpsk > presharedkey
打印输出私钥
cat privatekey
+Cr59JzbCKz9rESqimHGi5C2QfIRYZ5xVMssiTAEqV4=
打印输出公钥
cat publickey
bco6xIgfp++iFBj6vmDr27tAXfgYsppn/wyUJRcFgUc=
打印输出共享密钥(可以不生成,配置文件中不是必须的)
cat presharedkey
Vv0MdBNolqbnsBPQPf0ttJecOw2QC8QqWBVieNtvoIo=

编辑并保存 wg0 配置文件 wg0.conf

sudo vi wg0.conf

wg0.conf 配置文件内容如下:

ListenPort = 监听端口 1194
PrivateKey = 服务器私钥
PrivateKey = 连接节点公钥(由客户端生成)
AllowedIPs = VPN 隧道的内网 IP 段
[Interface]
ListenPort = 1194
PrivateKey = +Cr59JzbCKz9rESqimHGi5C2QfIRYZ5xVMssiTAEqV4=

[Peer]
PublicKey = 1lq23n/oNwYosnf0xMadtrIcC+droND9fg/wiS0aEhw=
AllowedIPs = 10.100.0.1/24

设置服务器的 NAT 流量转发

sudo vi /etc/sysctl.conf

找到这一行 #net.ipv4.ip_forward = 1 去掉注释符 “#”

net.ipv4.ip_forward = 1

执行 sysctl 并生效

sudo sysctl -p

在服务器端添加虚拟网卡 wg0,设置隧道 IP 和 iptables 规则

sudo ip link add dev wg0 type wireguard
sudo ip address add dev wg0 10.100.0.1/24
sudo ip link set wg0 up
sudo wg setconf wg0 /etc/wireguard/wg0.conf
sudo iptables -A FORWARD -i wg0 -j ACCEPT
sudo iptables -A FORWARD -o wg0 -j ACCEPT
sudo iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE
sudo iptables -t nat -A POSTROUTING -o ens4 -j MASQUERADE
检查 wg 设置是否正常
sudo wg show

正常情况应该输出以下内容:

interface: wg0
  public key: 1lq23n/oNwYosnf0xMadtrIcC+droND9fg/wiS0aEhw=
  private key: (hidden)
  listening port: 1194

peer: 8+9jGlxuwyGUWtUk8/NZMAl1Ax577KAvnXJY0EeuNkQ=
  endpoint: 12.34.56.78:61353
  allowed ips: 10.100.0.0/24
  latest handshake: 0 days, 8 minutes, 19 seconds ago
  transfer: 0.60 GiB received, 0.93 GiB sent
服务器端设置完成。

设置客户端

客户端系统 Ubuntu/Debian/ArchLinux 参照官方给出的快速安装指南 https://www.wireguard.com/install/

sudo mkdir -p /etc/wireguard && sudo chmod 077 /etc/wireguard && cd /etc/wireguard
umask 077
wg genkey | tee privatekey | wg pubkey > publickey
打印输出私钥
cat privatekey
SHBjWA3uAYAZc+TUvr6PcTA5SVQnt+aSVkdlZhlg1Hk=
打印输出公钥
cat publickey
8+9jGlxuwyGUWtUk8/NZMAl1Ax577KAvnXJY0EeuNkQ=

编辑并保存 wg0 配置文件 wg0.conf

sudo vi wg0.conf

wg0.conf 配置文件内容如下:

ListenPort = 监听端口 1194
PrivateKey = 本地客户端私钥
PrivateKey = 服务器端公钥(由服务器端生成)
AllowedIPs = VPN 隧道的内网 IP 段
Endpoint = 远程服务器公网 IP 和端口
PersistentKeepalive = 连接心跳包的唤醒间隔
[Interface]
ListenPort = 1194
PrivateKey = SHBjWA3uAYAZc+TUvr6PcTA5SVQnt+aSVkdlZhlg1Hk=

[Peer]
PublicKey = bco6xIgfp++iFBj6vmDr27tAXfgYsppn/wyUJRcFgUc=
AllowedIPs = 0.0.0.0/0
Endpoint = 12.34.56.78:1194
PersistentKeepalive = 25

在本地客户端

在客户端,添加虚拟网卡 wg0 并设置 IP 和路由

sudo ip link add dev wg0 type wireguard
sudo ip address add dev wg0 10.100.0.101/24
sudo ip link set wg0 up
sudo wg setconf wg0 /etc/wireguard/wg0.conf
sudo ip route add 12.34.56.78 via 192.168.1.1
sudo ip route del default
sudo ip route add default dev wg0

客户端设置完成,Ping 测试 VPN 隧道

ping 10.100.0.1

ping 输出如下

PING 10.100.0.1 (10.100.0.1) 56(84) bytes of data.
64 bytes from 10.100.0.1: icmp_seq=1 ttl=44 time=103.50 ms
64 bytes from 10.100.0.1: icmp_seq=2 ttl=44 time=103.50 ms
64 bytes from 10.100.0.1: icmp_seq=3 ttl=44 time=103.50 ms
64 bytes from 10.100.0.1: icmp_seq=4 ttl=44 time=103.50 ms
64 bytes from 10.100.0.1: icmp_seq=5 ttl=44 time=103.50 ms
64 bytes from 10.100.0.1: icmp_seq=6 ttl=44 time=103.50 ms
64 bytes from 10.100.0.1: icmp_seq=7 ttl=44 time=103.50 ms
64 bytes from 10.100.0.1: icmp_seq=8 ttl=44 time=103.50 ms
^C
--- 10.100.0.1 ping statistics ---
8 packets transmitted, 8 received, 0% packet loss, time 828ms
rtt min/avg/max/mdev = 103.50/103.50/103.50/0.00 ms
说明 VPN 隧道已通
用 curl 命令测试隧道的流量转发状态
curl ifconfig.me
显示 IP 为服务器的公网 IP
12.34.56.78
curl 获取到了服务器的公网 IP,流量转发成功

Disable WireGuard,禁用 WireGuard

删除添加的虚拟网卡、IP 和路由,或者重启系统,将恢复默认设置

服务器端

sudo ip link del dev wg0

本地客户端

sudo ip link del dev wg0
sudo ip route del 12.34.56.78 via 192.168.1.1
sudo ip route del default
sudo ip route add default via 192.168.1.1

其他

WireGuard 设计原理和使用方法参考 https://www.wireguard.com/
WireGuard 支持各种 Linux 发行版,目前 Windows 和 macOS 客户端(Go 实现)以及 Android 应用都在开发中。
WireGuard 在数字权利遭受强权政府日益侵害的国家,能有效捍卫网络用户的数字权利。
WireGuard 在中国、俄罗斯、伊朗等网络审查严重的国家,能有效突破网络封锁,突破 GFW 封锁,加密访问被封锁的网站,自由使用互联网。



用 dig 命令辨别 DNS 是否被污染

来源: https://kyle.ai/blog/6340.html

原理

既然说起 DNS 和其污染问题,就不得不先看看 DNS 系统是如何工作的,这个自从上个世纪80出现的方便大家连接主机的系统的确是有问题。从 Wikipedia 上偷张图先。
563px-An_example_of_theoretical_DNS_recursion.svg_
DNS 解析流程图
图中可以看到我们的 ISP 的 DNS 服务器在图中叫做 DNS Recurser,在解析一个域名的时候,总共经过了以下的步骤,图是以 www.wikipedia.org 作为示范的:
  1. 向 root 服务器获取该 gTLD 的管辖服务器,图中为 org 结尾的域名
  2. root 服务器返回 org 的管辖服务器
  3. 向 org 的管辖服务器查询,谁来负责解析 wikipedia.org 这个域名的
  4. org 的管辖服务器返回解析 wikipedia.org 的服务器 IP 地址
  5. 向 wikipedia.org 的解析服务器发出查询,解析 www.wikipedia.org 的 IP 地址
  6. 拿到最终要的 IP 地址
共6个步骤。那么如果在最后一次查询的时候,有人假冒了 wikipedia.org 的解析服务器,则可以在中间进行欺骗攻击,致使用户最后得到的 IP 地址不是真实的地址。如图所示,
563px-An_example_of_theoretical_DNS_recursion.svg_1
解析请求被劫持
更详细的关于 DNS 的内容,可以自行参考 rfc1035(http://tools.ietf.org/html/rfc1035)。

手工模拟

以上是大致的解析原理,我们手工一步一步来模拟解析的每个步骤吧。这里我用的环境是北京联通 ADSL + Mac OS X 10.7 『Lion』 + 某国家 VPN 一条。工具用到了 dig 和 tcpdump 来完成,Windows 下默认木有俩工具似乎,大家自行寻找吧,或者找一个 GNU/Linux 发行版装上,个人推荐 Ubuntu,有 red hat 情节的,就 Fedora 好了。首先用联通的 ADSL 来试验下
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
$ dig //直接获取根服务器的地址
; <<>> DiG 9.8.3-P1 <<>>
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59858
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 3
;; QUESTION SECTION:
;.              IN  NS
;; ANSWER SECTION:
.           205043  IN  NS  e.root-servers.net.
.           205043  IN  NS  h.root-servers.net.
.           205043  IN  NS  l.root-servers.net.
.           205043  IN  NS  i.root-servers.net.
.           205043  IN  NS  a.root-servers.net.
.           205043  IN  NS  d.root-servers.net.
.           205043  IN  NS  c.root-servers.net.
.           205043  IN  NS  b.root-servers.net.
.           205043  IN  NS  j.root-servers.net.
.           205043  IN  NS  k.root-servers.net.
.           205043  IN  NS  g.root-servers.net.
.           205043  IN  NS  m.root-servers.net.
.           205043  IN  NS  f.root-servers.net.
;; ADDITIONAL SECTION:
k.root-servers.net. 604222  IN  AAAA    2001:7fd::1
m.root-servers.net. 602881  IN  A   202.12.27.33
f.root-servers.net. 604218  IN  AAAA    2001:500:2f::f
;; Query time: 11 msec
;; SERVER: 202.96.134.133#53(202.96.134.133)
;; WHEN: Wed Sep 27 15:56:19 2017
;; MSG SIZE  rcvd: 300
这里我们可以看到,全球的域名根服务器共有从 a 到 m,共 13 组服务器。继续去 dig 出来这些服务器的地址吧,随便找一个好了
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
$ dig e.root-servers.net
; <<>> DiG 9.8.3-P1 <<>> e.root-servers.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25194
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;e.root-servers.net.        IN  A
;; ANSWER SECTION:
e.root-servers.net. 84796   IN  A   192.203.230.10
;; Query time: 4 msec
;; SERVER: 202.96.134.133#53(202.96.134.133)
;; WHEN: Wed Sep 27 15:56:51 2017
;; MSG SIZE  rcvd: 52
这里我们抓到了其中一组的 DNS 根服务器 e.root-servers.net 的地址为 192.203.230.10,继续
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
$ dig -t ns @192.203.230.10 com.
; <<>> DiG 9.8.3-P1 <<>> -t ns @192.203.230.10 com.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 691
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 15
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;com.               IN  NS
;; AUTHORITY SECTION:
com.            172800  IN  NS  a.gtld-servers.net.
com.            172800  IN  NS  b.gtld-servers.net.
com.            172800  IN  NS  c.gtld-servers.net.
com.            172800  IN  NS  d.gtld-servers.net.
com.            172800  IN  NS  e.gtld-servers.net.
com.            172800  IN  NS  f.gtld-servers.net.
com.            172800  IN  NS  g.gtld-servers.net.
com.            172800  IN  NS  h.gtld-servers.net.
com.            172800  IN  NS  i.gtld-servers.net.
com.            172800  IN  NS  j.gtld-servers.net.
com.            172800  IN  NS  k.gtld-servers.net.
com.            172800  IN  NS  l.gtld-servers.net.
com.            172800  IN  NS  m.gtld-servers.net.
;; ADDITIONAL SECTION:
a.gtld-servers.net. 172800  IN  A   192.5.6.30
b.gtld-servers.net. 172800  IN  A   192.33.14.30
c.gtld-servers.net. 172800  IN  A   192.26.92.30
d.gtld-servers.net. 172800  IN  A   192.31.80.30
e.gtld-servers.net. 172800  IN  A   192.12.94.30
f.gtld-servers.net. 172800  IN  A   192.35.51.30
g.gtld-servers.net. 172800  IN  A   192.42.93.30
h.gtld-servers.net. 172800  IN  A   192.54.112.30
i.gtld-servers.net. 172800  IN  A   192.43.172.30
j.gtld-servers.net. 172800  IN  A   192.48.79.30
k.gtld-servers.net. 172800  IN  A   192.52.178.30
l.gtld-servers.net. 172800  IN  A   192.41.162.30
m.gtld-servers.net. 172800  IN  A   192.55.83.30
a.gtld-servers.net. 172800  IN  AAAA    2001:503:a83e::2:30
b.gtld-servers.net. 172800  IN  AAAA    2001:503:231d::2:30
;; Query time: 349 msec
;; SERVER: 192.203.230.10#53(192.203.230.10)
;; WHEN: Wed Sep 27 15:57:39 2017
;; MSG SIZE  rcvd: 509
上面共有从 a 到 m,一样是 13 组服务器在所有的 com. 的 gTLD 的记录保存。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
$ dig -t ns @192.5.6.30 twitter.com
; <<>> DiG 9.8.3-P1 <<>> -t ns @192.5.6.30 twitter.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21761
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;twitter.com.           IN  NS
;; ANSWER SECTION:
twitter.com.        240 IN  A   78.16.49.15
;; Query time: 13 msec
;; SERVER: 192.5.6.30#53(192.5.6.30)
;; WHEN: Wed Sep 27 15:58:18 2017
;; MSG SIZE  rcvd: 45
这里看到问题了么?本来应该返回 twitter.com 的具体的解析服务器,为什么直接返回了一个 A 记录?而且还是这么诡异的一个地址?查询以下这个 IP 的归属地,是『新西兰 奥克兰Telstraclear公司』,应该是胡乱编出来的地址了。至此再测试下去意义也就不大了,具体原因等会儿分析。换上 VPN 看看结果如何
1
2
3
4
5
6
7
8
9
10
11
12
13
$ dig
# 这里的结果完全一样,我们继续选择 e 的那组
$ dig e.root-servers.net
# 嗯,这里也一样,继续
$ dig -t ns @192.203.230.10 com.
# 没有什么新奇的,继续…
以上几条结果都是一样的返回
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
$ dig -t ns @192.5.6.30 twitter.com
; <<>> DiG 9.8.3-P1 <<>> -t ns @192.5.6.30 twitter.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56292
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 6
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;twitter.com.           IN  NS
;; AUTHORITY SECTION:
twitter.com.        172800  IN  NS  ns3.p34.dynect.net.
twitter.com.        172800  IN  NS  ns4.p34.dynect.net.
twitter.com.        172800  IN  NS  r01-01.ns.twtrdns.net.
twitter.com.        172800  IN  NS  r01-02.ns.twtrdns.net.
twitter.com.        172800  IN  NS  d01-01.ns.twtrdns.net.
twitter.com.        172800  IN  NS  d01-02.ns.twtrdns.net.
;; ADDITIONAL SECTION:
ns3.p34.dynect.net. 172800  IN  A   208.78.71.34
ns4.p34.dynect.net. 172800  IN  A   204.13.251.34
r01-01.ns.twtrdns.net.  172800  IN  A   205.251.195.113
r01-02.ns.twtrdns.net.  172800  IN  A   205.251.197.74
d01-01.ns.twtrdns.net.  172800  IN  A   208.78.70.34
d01-02.ns.twtrdns.net.  172800  IN  A   204.13.250.34
;; Query time: 171 msec
;; SERVER: 192.5.6.30#53(192.5.6.30)
;; WHEN: Wed Sep 27 16:00:31 2017
;; MSG SIZE  rcvd: 270
到这里的结果就和刚才不一样了,可以看到,192.5.6.30 这个服务器正常返回了应该负责解析 twitter.com 的真实 ns 的服务器,既然都做到这里了,就继续下去吧,继续从里面随便抓一个出来
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
$ dig @208.78.71.34 twitter.com any
;; Truncated, retrying in TCP mode.
; <<>> DiG 9.8.3-P1 <<>> @208.78.71.34 twitter.com any
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16674
;; flags: qr aa rd; QUERY: 1, ANSWER: 28, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;twitter.com.           IN  ANY
;; ANSWER SECTION:
twitter.com.        293 IN  SOA ns1.p26.dynect.net. zone-admin.dyndns.com. 2007137844 3600 600 604800 60
twitter.com.        13999   IN  NS  ns2.p34.dynect.net.
twitter.com.        13999   IN  NS  r01-02.ns.twtrdns.net.
twitter.com.        13999   IN  NS  r01-01.ns.twtrdns.net.
twitter.com.        13999   IN  NS  d01-02.ns.twtrdns.net.
twitter.com.        13999   IN  NS  d01-01.ns.twtrdns.net.
twitter.com.        13999   IN  NS  ns3.p34.dynect.net.
twitter.com.        13999   IN  NS  ns1.p34.dynect.net.
twitter.com.        13999   IN  NS  ns4.p34.dynect.net.
twitter.com.        79  IN  A   199.59.148.10
twitter.com.        79  IN  A   199.16.156.6
twitter.com.        79  IN  A   199.59.150.7
twitter.com.        79  IN  A   199.16.156.102
twitter.com.        79  IN  A   199.16.156.38
twitter.com.        79  IN  A   199.16.156.70
twitter.com.        79  IN  A   199.59.149.198
twitter.com.        79  IN  A   199.16.156.198
twitter.com.        79  IN  A   199.59.149.230
twitter.com.        79  IN  A   199.59.148.82
twitter.com.        79  IN  A   199.16.156.230
twitter.com.        79  IN  A   199.59.150.39
twitter.com.        300 IN  TXT "v=spf1 ip4:199.16.156.0/22 ip4:199.59.148.0/22 ip4:8.25.194.0/23 ip4:8.25.196.0/23 ip4:204.92.114.203 ip4:204.92.114.204/31 ip4:23.21.83.90 include:_spf.google.com include:_thirdparty.twitter.com -all"
twitter.com.        300 IN  TXT "google-site-verification=h6dJIv0HXjLOkGAotLAWEzvoi9SxqP4vjpx98vrCvvQ"
twitter.com.        600 IN  MX  10 aspmx.l.google.com.
twitter.com.        600 IN  MX  20 alt2.aspmx.l.google.com.
twitter.com.        600 IN  MX  30 ASPMX3.GOOGLEMAIL.COM.
twitter.com.        600 IN  MX  20 alt1.aspmx.l.google.com.
twitter.com.        600 IN  MX  30 ASPMX2.GOOGLEMAIL.COM.
;; Query time: 21 msec
;; SERVER: 208.78.71.34#53(208.78.71.34)
;; WHEN: Wed Sep 27 16:01:08 2017
;; MSG SIZE  rcvd: 891
我们可以发现挂上 VPN 之后的解析流程才是正确无误的过程,但是为什么不挂上就不能正确解析?自然是 DNS 服务器被污染了。并且拦截的方式似乎也很弱智,发现 UDP 53 口的包带有 twitter.com 字样,直接返回一个随即、胡编出来的 IP 地址,也不管人家到底是不是直接要去查 twitter.com 的 A 记录。为了证明这种猜想,继续做一些试验吧。不如发一个错误的 DNS 包出去,看看返回什么结果。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
$ dig @202.204.49.251 twitter.com -t ns --->> 查询的服务器是 202.204.48.251
; <<>> DiG 9.8.3-P1 <<>> @202.204.49.251 twitter.com -t ns
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28290
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;twitter.com.           IN  NS
;; ANSWER SECTION:
twitter.com.        64  IN  A   243.185.187.39
;; Query time: 24 msec
;; SERVER: 202.204.49.251#53(202.204.49.251)
;; WHEN: Wed Sep 27 16:02:43 2017
;; MSG SIZE  rcvd: 45
这里的服务器是 iBeiKe 在教育网内的服务器,对于外网没有开除了 80 的任何口,而且也没有 53 的 UDP 开着,果然,够弱智!

tcpdump 抓包

tcpdump 这个东西虽然叫做 tcpdump,但是 UDP 抓起来也没有问题,随便抓抓 DNS 的解析包,不需要什么重型武器,这种轻量级别就很好用了。环境和上面一样,我用的无线网络,所以在 Mac OS X 的接口就是 en1 了。不上 VPN 看看结果如何吧
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
$ sudo tcpdump -i en1 -vvv udp
16:05:10.189549 IP (tos 0x0, ttl 64, id 51997, offset 0, flags [none], proto UDP (17), length 57)
    192.168.0.86.61289 > a.gtld-servers.net.domain: [udp sum ok] 4731+ NS? twitter.com. (29)
16:05:10.190103 IP (tos 0x0, ttl 255, id 51444, offset 0, flags [none], proto UDP (17), length 69)
    192.168.0.86.53167 > ns.szptt.net.cn.domain: [udp sum ok] 14187+ PTR? 30.6.5.192.in-addr.arpa. (41)
16:05:10.200364 IP (tos 0x0, ttl 45, id 59500, offset 0, flags [DF], proto UDP (17), length 73)
# 假的结果返回
    a.gtld-servers.net.domain > 192.168.0.86.61289: [udp sum ok] 4731 q: NS? twitter.com. 1/0/0 twitter.com. [1m38s] A 59.24.3.173 (45)
16:05:10.201166 IP (tos 0x0, ttl 197, id 55906, offset 0, flags [none], proto UDP (17), length 84)
    a.gtld-servers.net.domain > 192.168.0.86.61289: [udp sum ok] 4731* q: NS? twitter.com. 1/0/0 twitter.com. [1m] A 59.24.3.174 (56)
16:05:10.258033 IP (tos 0x0, ttl 51, id 56581, offset 0, flags [none], proto UDP (17), length 298)
# 正确的返回
    a.gtld-servers.net.domain > 192.168.0.86.61289: [udp sum ok] 4731- q: NS? twitter.com. 0/6/6 ns: twitter.com. [2d] NS ns3.p34.dynect.net., twitter.com. [2d] NS ns4.p34.dynect.net., twitter.com. [2d] NS r01-01.ns.twtrdns.net., twitter.com. [2d] NS r01-02.ns.twtrdns.net., twitter.com. [2d] NS d01-01.ns.twtrdns.net., twitter.com. [2d] NS d01-02.ns.twtrdns.net. ar: ns3.p34.dynect.net. [2d] A 208.78.71.34, ns4.p34.dynect.net. [2d] A 204.13.251.34, r01-01.ns.twtrdns.net. [2d] A 205.251.195.113, r01-02.ns.twtrdns.net. [2d] A 205.251.197.74, d01-01.ns.twtrdns.net. [2d] A 208.78.70.34, d01-02.ns.twtrdns.net. [2d] A 204.13.250.34 (270)
16:05:10.429786 IP (tos 0x0, ttl 51, id 0, offset 0, flags [none], proto UDP (17), length 73)
    a.gtld-servers.net.domain > 192.168.0.86.61289: [udp sum ok] 4731 q: NS? twitter.com. 1/0/0 twitter.com. [3m29s] A 78.16.49.15 (45)
16:05:10.718695 IP (tos 0x0, ttl 59, id 0, offset 0, flags [DF], proto UDP (17), length 101)
    ns.szptt.net.cn.domain > 192.168.0.86.53167: [udp sum ok] 14187 q: PTR? 30.6.5.192.in-addr.arpa. 1/0/0 30.6.5.192.in-addr.arpa. [1d] PTR a.gtld-servers.net. (73)
16:05:11.124993 IP (tos 0x0, ttl 4, id 27621, offset 0, flags [none], proto UDP (17), length 157)
    192.168.0.119.63409 > 239.255.255.250.ssdp: [udp sum ok] UDP, length 129
16:05:11.125357 IP (tos 0x0, ttl 1, id 29662, offset 0, flags [none], proto UDP (17), length 304)
    192.168.0.149.50587 > 239.255.255.250.ssdp: [udp sum ok] UDP, length 276
16:05:11.227349 IP (tos 0x0, ttl 4, id 27623, offset 0, flags [none], proto UDP (17), length 157)
    192.168.0.119.63409 > 239.255.255.250.ssdp: [udp sum ok] UDP, length 129
唔,有人抢在正确的包之前跑来了。你为什么这么积极呢?为什么呢…

转自:https://2.botu.me/post/2763.html