最近突然发现公司 ping google 会被解析为内网 ip
xxx@xxx ~ % ping google.com
PING google.com (10.xx.xx.xxx): 56 data bytes
64 bytes from 10.xx.xx.xxx: icmp_seq=0 ttl=56 time=54.002 ms
64 bytes from 10.xx.xx.xxx: icmp_seq=1 ttl=56 time=52.970 ms
64 bytes from 10.xx.xx.xxx: icmp_seq=2 ttl=56 time=52.414 ms

然后通过 dig 查看了一下，发现使用公司的内网 dns 会被解析到三个内网 ip ，如果使用公共 dns 就会解析到公网 ip 上，看了一下 google 的证书，和科学上网访问的证书是同一本（ SHA-256 指纹判定），想问一下这个是怎么实现的呢？这不就是中间人攻击吗
补充，访问 CloudFront 加速的网站也会被解析到和 Google 相同的内网 ip 上，并且证书和公网访问一样

公司内网系统查过了，这些 ip 确实对应一些内网的机器，然后在这些机器的外网防火墙上也看到了 Google 这些网站的白名单，同时这些机器在香港部署。reaceroute 也看了一下，Google 被公司解析的内网 ip 完全走内网，Google 的公网 ip 的路由走了香港的 ix ，路由不大一样。结论：初步判定是 sni proxy ，具体细节周一问下公司的 sre

更正 traceroute

反向代理吧

反向代理也需要拿到 Google 的私钥啊，可是怎么可能给私钥呢

应该是虚拟 IP ，类似于 Surge 的做法

sni 不需要

sni 不需要证书？那这么看很容易中间人攻击啊

fakeip

类似 fakeip ？

tun 模式吧

sni proxy 吧

证书对就行。IP 无所谓。

类似于 fakeip 吧

三层转发了一下而已https 是四层的

你们内网 time=54.002 ms 这走的什么隧道组的内网。。

不就是 fakeip 方式分流么

＃9 所以哪҉里去҄找一份҄sni 列表? spotify 好像不҄支持

iplc

大佬，确实是 sni proxy ，才疏学浅了，没明白 sni 是代表 sni proxy

请你复习一遍 OSI 网络参照模型，HTTP 协议位于应用层。另外如果你愿意你甚至可以把任意一个域名（例如 example.com ）解析为 127.0.0.1 ，然后通过 example.com 访问本机 443 端口提供的这个网站，只需要做一个 TCP 转发 (127.0.0.1:443 -> :443)。类似的名称（功能）：虚拟 IP ，端口转发，4 层反向代理，都可以做到这一点。你想想 Kubernetes Service 的 ClusterIP 是怎么实现的。中间人攻击不存在，除非中间人能解密 HTTPS 流量，或者你信任了中间人签发的根证书。

例如通过 nginx 就可以配一个端口转发，把本机 443 端口转发到 任意一个网站的 的 IP 的 443 端口，配置也很简单： docs.nginx.com/nginx/admin-guide/load-balancer/tcp-udp-load-balancer/

正向代理+隧道

www.haproxy.com/blog/layer-4-and-layer-7-proxy-mode 这篇文章介绍了七层反向代理和 四层反向代理的区别，七层反向代理的转发器需要解析 HTTP 报文，重新发送 HTTP 报文，所以才需要证书。四层的不需要。就好像你家的路由器也在转发你访问任意网站的流量，但是它不需要证书。

借楼一问。op 这是啥输入法，我乍一看回复以为是屏幕脏了，但复制出去才发现这字有东西。

同问这字？

你用 haproxy 或者 iptables 自己的 VPS 搞个转发就知道了。

公司帮你搭了个正向代理

也许是专线

这些知识都是怎么学的，感觉好复杂，看博客都是一些看不懂的专业术语

＃23 ＃22西里尔百万结合符

把你 cfw 的 tun 模式关了就行····

我看怎么是 虚拟 ip 然后做路由呢，很可能连 SNI proxy 都不算，直接走得是 3 层路由过 VPN 了，然后出口在做 NAT ，简单方便。是不是 SNI proxy 你要看 tcp 建立的时间，毕竟 SNI proxy 要先 tcp 连接了 读 SNI ，然后代理才会去请求源。traceroute 下试试看。

中国程序员网络知识 天下第一，都得改写 gfw

端口转发