这是一个创建于 629 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近突然发现公司 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 上，并且证书和公网访问一样
第 1 条附言 2024-01-20 18:29:57 +08:00
公司内网系统查过了，这些 ip 确实对应一些内网的机器，然后在这些机器的外网防火墙上也看到了 Google 这些网站的白名单，同时这些机器在香港部署。
reaceroute 也看了一下，Google 被公司解析的内网 ip 完全走内网，Google 的公网 ip 的路由走了香港的 ix ，路由不大一样。
结论：初步判定是 sni proxy ，具体细节周一问下公司的 sre
reaceroute 也看了一下，Google 被公司解析的内网 ip 完全走内网，Google 的公网 ip 的路由走了香港的 ix ，路由不大一样。
结论：初步判定是 sni proxy ，具体细节周一问下公司的 sre
第 2 条附言 2024-01-20 18:30:54 +08:00
更正 traceroute
 | 1 cjpjxjx 2024-01-19 20:02:41 +08:00 via iPhone 反向代理吧 |
 | 3 xfn 2024-01-19 20:04:57 +08:00 应该是虚拟 IP ，类似于 Surge 的做法 |
 | 6 a href="/member/seers" class="dark">seers 2024-01-19 20:07:54 +08:00 via iPhone fakeip |
 | 7 jemyzhang 2024-01-19 20:08:11 +08:00 via iPhone 类似 fakeip ？ |
 | 8 UXha45veSNpWCwZR 2024-01-19 20:09:17 +08:00 via iPhone tun 模式吧 |
 | 9 onetown 2024-01-19 20:09:27 +08:00  4 sni proxy 吧 |
 | 10 kneo 2024-01-19 20:15:56 +08:00 via Android 证书对就行。IP 无所谓。 |
 | 11 SenLief 2024-01-19 20:19:06 +08:00 1 类似于 fakeip 吧 |
 | 12 shenyuzhi 2024-01-19 20:23:19 +08:00 三层转发了一下而已 https 是四层的 |
 | 13 yumusb 2024-01-19 20:30:55 +08:00 你们内网 time=54.002 ms 这走的什么隧道组的内网。。 |
 | 14 paranoiagu 2024-01-19 20:44:46 +08:00 via Android 不就是 fakeip 方式分流么 |
 | 18 beyondstars 2024-01-19 22:04:07 +08:00 4 请你复习一遍 OSI 网络参照模型，HTTP 协议位于应用层。 另外如果你愿意你甚至可以把任意一个域名（例如 example.com ）解析为 127.0.0.1 ，然后通过 https://example.com 访问本机 443 端口提供的这个网站，只需要做一个 TCP 转发 (127.0.0.1:443 -> <remote-ip>:443)。类似的名称（功能）：虚拟 IP ，端口转发，4 层反向代理，都可以做到这一点。你想想 Kubernetes Service 的 ClusterIP 是怎么实现的。 中间人攻击不存在，除非中间人能解密 HTTPS 流量，或者你信任了中间人签发的根证书。 |
| 19 beyondstars 2024-01-19 22:05:38 +08:00 例如通过 nginx 就可以配一个端口转发，把本机 443 端口转发到 任意一个网站的 的 IP 的 443 端口，配置也很简单： https://docs.nginx.com/nginx/admin-guide/load-balancer/tcp-udp-load-balancer/ |
 | 20 mytsing520 PRO 正向代理+隧道 |
| 21 beyondstars 2024-01-19 22:09:40 +08:00 https://www.haproxy.com/blog/layer-4-and-layer-7-proxy-mode 这篇文章介绍了七层反向代理和 四层反向代理的区别，七层反向代理的转发器需要解析 HTTP 报文，重新发送 HTTP 报文，所以才需要证书。 四层的不需要。就好像你家的路由器也在转发你访问任意网站的流量，但是它不需要证书。 |
 | 22 orzorzorzorz 2024-01-19 22:56:44 +08:00 @basncy 借楼一问。op 这是啥输入法，我乍一看回复以为是屏幕脏了，但复制出去才发现这字有东西。 |
 | 24 ZhiyuanLin 2024-01-19 23:05:40 +08:00 你用 haproxy 或者 iptables 自己的 VPS 搞个转发就知道了。 |
 | 25 cloverzrg2 2024-01-20 00:21:32 +08:00 公司帮你搭了个正向代理 |
 | 26 BeiChuanAlex 2024-01-20 00:38:09 +08:00 也许是专线 |
 | 27 notabigdirector 2024-01-20 09:20:59 +08:00 这些知识都是怎么学的，感觉好复杂，看博客都是一些看不懂的专业术语 |
 | 28 wuvvu 2024-01-20 10:47:06 +08:00 1 |
 | 29 JK2333 2024-01-20 13:30:32 +08:00 把你 cfw 的 tun 模式关了就行 |
 | 30 tywtyw2002 2024-01-20 14:41:19 +08:00 我看怎么是 虚拟 ip 然后做路由呢，很可能连 SNI proxy 都不算，直接走得是 3 层路由过 VPN 了，然后出口在做 NAT ，简单方便。 是不是 SNI proxy 你要看 tcp 建立的时间，毕竟 SNI proxy 要先 tcp 连接了 读 SNI ，然后代理才会去请求源。 traceroute 下试试看。 |
 | 31 Rorysky 2024-01-20 15:30:56 +08:00 @notabigdirector 中国程序员网络知识 天下第一，都得改写 gfw |
 | 32 louisxxx 2024-01-21 08:20:34 +08:00 via iPhone 端口转发 |
Select Language