惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
G
Google Developers Blog
小众软件
小众软件
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
博客园 - 【当耐特】
爱范儿
爱范儿
博客园 - 聂微东
美团技术团队
大猫的无限游戏
大猫的无限游戏
The Cloudflare Blog
酷 壳 – CoolShell
酷 壳 – CoolShell
有赞技术团队
有赞技术团队
云风的 BLOG
云风的 BLOG
罗磊的独立博客
V
Visual Studio Blog
WordPress大学
WordPress大学
Stack Overflow Blog
Stack Overflow Blog
雷峰网
雷峰网
人人都是产品经理
人人都是产品经理
Blog — PlanetScale
Blog — PlanetScale
V
V2EX
The GitHub Blog
The GitHub Blog
Apple Machine Learning Research
Apple Machine Learning Research
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报

Yesterday17's Blog

2026 新年解密红包 / Melody Flag | Yesterday17's Blog 谈谈 Iori 的设计思路(二):如何实现一个 Showroom 录制工具? | Yesterday17's Blog 谈谈 Iori 的设计思路(一):从 Nico Timeshift 说起 | Yesterday17's Blog Iori Minyami 0.1.0 发布 | Yesterday17's Blog 2025 新年解密红包 / Melody Flag | Yesterday17's Blog 使用 Cloudflare Warp 解决罗森票务的海外登录问题 | Yesterday17's Blog How To Blog 04: The Astro v5 Era | Yesterday17's Blog 谈谈 tokio::select! 的公平性 | Yesterday17's Blog Learning Pingora 05 - Connect with TLS | Yesterday17's Blog Leaving Bytedance | Yesterday17's Blog 大橋彩香 AsiaTour「Reflection」上海公演 个人向记录 & Repo | Yesterday17's Blog Recoving from burnout - What happened? | Yesterday17 Yubikey 重建手册 | Yesterday17's Blog How To Blog 03: Heimus | Yesterday17's Blog 🪧 Blog Migration Accouncement | Yesterday17's Blog Learn Your IDE - VSCode 是如何仅重启插件的? | Yesterday17's Blog How To Blog 02: Astro❤️Password | Yesterday17's Blog How To Blog 01: Why, How, and the Future | Yesterday17's Blog Learning Pingora 04 - Establish L4 Connection | Yesterday17's Blog Learning Pingora 03 - Upstreams and Peers | Yesterday17's Blog Learning Pingora 02 - A Simple HTTP Server | Yesterday17's Blog Learning Pingora 01 - Getting Started | Yesterday17's Blog 2024 新年解密红包 / Melody Flag | Yesterday17's Blog 向新的一年飞驰——记录 2023 | Yesterday17's Blog 「サクラノ刻」对话选摘(2) | Yesterday17's Blog PGP Key Revocation 注销声明 | Yesterday17's Blog 「サクラノ刻」对话选摘(1) | Yesterday17's Blog 2023 新年解密红包 / Melody Flag | Yesterday17's Blog 『蒼の彼方のフォーリズム』通关感想 | Yesterday17's Blog 单显卡直通教程 | Yesterday17's Blog
Nginx+dnsmasq 实现旁路由透明代理 | Yesterday17's Blog
Yesterday17 · 2020-04-28 · via Yesterday17's Blog

又是折腾的一天。明明 ddl 就在眼前了,为什么……会这样呢……

这次折腾的是路由器级别的透明代理,不过形式稍微有点不同,正如之前发的那一串推所说,是以 DNS 的形式实现的透明代理,因此只要是连上主路由器的设备一般都能正常使用。

当然了,也是有例外的,比如有些设备强制使用自己的 DNS 设置,对于这种设备就没有办法了。不过我这里也没有这样的设备,而就手机平板而言,都是可以正常连接的。

连上主路由并能正常刷推的破手机
连上主路由并能正常刷推的破手机

当然了,前提是本机已经配置好了透明代理,这里就来简单介绍一下好了~

SNI 代理

SNIServer Name Indication 的简称,其主要的用途是能让同一个端口下提供复数张证书,由此达到多个网站共用 443 端口的目的。

那 SNI 代理又是什么呢?我们先来看 SNI。从原理来说,SNI 本身是在 TLSClientHello 的实现的,如 [RFC 3546] 定义:

In order to provide the server name, clients MAY include an extension of type “server_name” in the (extended) client hello.

我们发现,SNI 其实只是在 ClientHello 时附带的一个明文字符串(下称域名)而已,因此对于代理而言,我们就有操作的空间了。

首先,由于域名是明文的,因此我们就得到了需要访问的域名信息。在此之后,我们只要将所有的信息原封不动地转发给域名对应的服务器就可以了(当然,也包括 ClientHello)。

由于整个过程没有任何 MiTM 的因素存在,因此我们不需要对证书作任何处理;从原理上来讲,SNI 代理其实只是做了转发处理,因此实际上客户端和服务端的交互仍然是点对点的;唯一的区别可能就在 traceroute 上了。对客户端而言,从包到达 SNI 代理服务器那一刻起,之后的路径就无法掌控了。

SNI 代理因其不需要配置证书的特性而广泛地运用于 DNS 解锁流媒体服务母猪连结解 ban 等领域。同样,因为 SNI 代理是使用 DNS 的,因此对任何网络而言,配置透明代理都变得无比简单:只需要路由器能将对应需要透明代理的域名的 IP 设置为 SNI 代理的服务器 IP 就可以了。

dnsmasq+某 list

dnsmasq 是大名鼎鼎的 DNS 客户端,而某 list 也是人尽皆知的域名列表。这里我们通过将某 list 转换为 dnsmasq 规则来实现透明代理的 DNS 服务器。

首先是规则转换,我们使用的是 [1],不过这里需要修改一下。脚本的输出默认是 server=,即选择 DNS;而我们想要的是直接返回 IP,即 address=。将对应 IP 设置为本机在局域网中的 IP 就可以了。

此外,dnsmasq 还需要一个上游 DNS 服务器以返回列表以外的网站 IP。这里你可以选择任意一个没有污染的 DNS 服务器,或者使用 clash 的内置 DNS 服务器等等。我这里用的是 clash 的内置 DNS 服务器,配置的端口为 53;而 dnsmasq 配置的端口为 5353

在配置完 dnsmasq 之后,我们还需要将外部流量的 DNS 端口引导过来。我们使用 iptables 进行端口转发:

sudo iptables -t nat -A PREROUTING -p udp --dport 53 -j REDIRECT --to-port 5353

配置 SNI 代理

接下来就是整个过程的核心了:配置 SNI Proxy。我们使用 Nginxstream 来完成这一目标:

stream {

server {

listen 443;

ssl_preread on;

resolver 127.0.0.1 ipv6=off;

proxy_pass $ssl_preread_server_name:$server_port;

}

}

我们使 stream 监听 443 端口,并开启 ssl_preread 以使用 $ssl_preread_server_name,使得我们可以读到 SNI 信息。这里我们设置了 resolver,即 DNS 解析服务器。ipv6=off 是针对无 ipv6 的环境的,如果有 ipv6 的话可以删去(

配置 http 代理

https 可以正常访问之后,我们也不能把 http 丢下。相比之下,http 的配置就相对简单了。这里的关键是 proxy_bind $remote_addr transparent;,它实现了 http 的透明代理:

http {

# ...

server {

listen 80 default_server;

resolver 127.0.0.1 ipv6=off;

location / {

proxy_pass $scheme://$host$request_uri;

proxy_bind $remote_addr transparent;

proxy_set_header Host $host;

}

}

}

配置路由器

最后也是最简单的一步就是配置路由器了,我们将首选 DNS 设置为本机 IP,备用 DNS 设置为其他的 DNS,以保证在本机不可用的情况下也可以正常上网:

备用 DNS 服务器使用了阿里 DNS
备用 DNS 服务器使用了阿里 DNS

至此,整个旁路由透明代理配置完成。

结语

其实某种意义上我也不知道这算不算旁路由,只是感觉这个概念比较符合这种配置而已。毕竟我这电脑和路由器隔了整整一堵墙呢,而且只是把路由的 DNS 引导到了本机而已,网关之类的并没有任何改变。或许也正是由于离路由器远,我才能想到这样的路由器透明代理的方案吧。

从某种意义上来说,这个方案需要改进的地方还是挺多的。首先是规则问题,是不是应该用 dnsmasq-chinalist 以实现更广泛的非国内域名加速服务?其次是本地双 DNS 的问题,这个可能难以改变(因为 Nginx 需要查询真实 IP),但是不是可以对调一下,省去那一步 iptables?最后就是 meta 域名,对于顶级域,目前的 Nginx 似乎还无法正常处理,这也是一个迫切(或许)需要解决的问题。

不过从 ddl 角度来看,我大概是疯了吧,明明还有那么多事来着(

如果有帮到你/有所疑问的话,欢迎在评论区留言(