Nginx 的 444 命令（强制切断 TCP 连接），用于对抗运营商检测家宽开服务是否有帮助？

[MFWT]

背景

我知道 VPN ，我也在用 VPN ，VPN 确实很方便，连上之后直接访问内网地址就可以获取到各项服务

但是，能不能再直接一点呢，比如临时给朋友开个 Web 页面传个文件什么的，用 VPN 还得教他半天，如果能直接浏览器打开那确实是挺好的

考虑到有朋友说路由器管理页面被主动探测到，又有朋友说 ocserv 运行几年毛事没有，也有朋友说裸 TLS 连接（内部没有 HTTP 协议，浏览器无法直接访问）也没啥问题，猜测运营商对于『家宽开 Web 服务』（此处仅讨论非标端口，80/443 就不必说了）大概可能会有这几种：

1. 对于裸 TLS 连接拦截较少
2. 模拟浏览器访问（比如 curl ），看看有没有内容（比如 HTTP 头）返回
3. 同 1 ，但是判定更严谨，检查返回码是不是 200 （或者其他方式来判定是不是可以直接访问）

测试

以下测试都假定已有可用的 TLS 环境（毕竟直接裸 HTTP 连接的话，是个人都知道你在干啥）

nginx 对于拒绝非合法访问，有个选项是 deny all ，但是实测 deny all 也会返回 HTTP 403 ，在某些运营商那里可能会被判定为情况 2 。因此我测试了一下 return 444 ，对于非白名单路径（实例是 private_path_as_a_token ）指示 nginx 直接切断连接

相关配置如下

  location / {
    keepalive_timeout 0;
    return 444;
  }
  
  location /private_path_as_a_token {
    root /home/html;
    index index.html;
  }

测试发现，在访问非白名单路径的时候（比如此时的根目录）确实会直接切断 TCP 连接，站在浏览器的角度看就是，这并非一个 HTTP 服务器：

* Trying 10.0.0.233:8000...
* Connected to 10.0.0.233 (10.0.0.233) port 8000 (#0)
> GET / HTTP/1.1
> Host: 10.0.0.233:8000
> User-Agent: curl/8.0.1
> Accept: */*

>
* Empty reply from server
* Closing connection 0
curl: (52) Empty reply from server

现在的问题是，如果我通过这个方式，在公网 IP （我的是公网 v6 ）上开放 HTTPS 服务，是否能规避一定程度上的运营商主动探测？

望各位朋友不吝赐教

[cheneydog]

你是哪里的？哪个运营商管这么多么？

[dzdh]

就是把根路径变变？

[YGBlvcAK]

我也是类似的方式，我用的 caddy ，非白名单路径直接 abort ，可以看我之前的主题 /923605

你这如果是其它路径，返回什么？比如/aaa ，也是 return 444 吗？

[hingle]

也许有可能防止运营商通过 HTTP 主动探测，但防不了用 TCP 主动探测，试试下面的命令
echo hello | nc 10.0.0.233 8000

[deorth]

有，帮助不大。就算是 https 他镜像你流量看 sni 就知道你在干嘛了

[deorth]

我现在的做法就是搞个 svcb 记录，自用的终端全都走 h3 。现在他们应该还没有 quic 流量的分析能力。后面看看什么时候服务端和终端都支持起来了，搞一波 ech

[MFWT]

@cheneydog 广东移动

[MFWT]

@YGBlvcAK 是，这么写的话实测非指定路径会回落到根路径，然后就 444

[MFWT]

@hingle 确实是个问题，nginx 直接返回 HTTP 信息了

[LinePro]

@hingle #4
@MFWT #9

error_page 400 =444 /;
在 OP 原有配置的基础上加上这条，应该可以解决此问题。

[YGBlvcAK]

@hingle 有意思，我发现我的 caddy （跑 webdav ）没有任何返回，又试了试 www.163.com 有返回：HTTP/1.1 400 Bad Request

[pupboss]

很管用，还能让一些爬虫抓瞎，因为爬虫也拿不到 444 这个状态码，只会发现连接被中止了，不懂 TCP 只知道 HTTP 皮毛的脚本小子完全不知道发生了什么

[LinePro]

说起这个我想起了某防火墙的主动探测原理 233
理论上探测者可以一个字节一个字节地把 GET / HTTP/1.1\r\n 和底下的请求头发过去，观察服务端在何时断开连接来判断是否为 HTTP 服务。

[laozhoubuluo]

一般来说建立 TLS 握手的时候是要传证书过去的，需要考虑服务器发过去的证书有没有穿帮的可能性。

```
# curl -vvv https://www.example.com
* Server certificate:
* subject: C=US; ST=California; L=Los Angeles; O=Internet▒Corporation▒for▒Assigned▒Names▒and▒Numbers; CN=www.example.org
* start date: Jan 13 00:00:00 2023 GMT
* expire date: Feb 13 23:59:59 2024 GMT
* subjectAltName: host "www.example.com" matched cert's "www.example.com"
* issuer: C=US; O=DigiCert Inc; CN=DigiCert TLS RSA SHA256 2020 CA1
* SSL certificate verify ok.
```

[idontnowhat2say]

我估计要是运营商用的是流量镜像的方式审查，你这没啥用。我以前给一个某个地级市运营商做实施的时候，机房的网工直接指着一个核心交换机的光口跟我说，这个口就是做流量镜像接给公安审查的。

[LinePro]

@laozhoubuluo #14

帮 OP 补充一下 nginx 关于这个问题的配置：
新一些的 nginx 可以用 ssl_reject_handshake on; 规避这个问题。
老版 nginx 的话可以随便自签个虚假证书给 default_server

当然只要 sni 不加密，运营商可以从流量中获取合法的 sni ，那么这方面配置对于 OP 所提的这个题目《用于对抗运营商检测家宽开服务是否有帮助？》而言意义不大。

[villivateur]

如果运营商不是通过探针的方式检查，而是直接看你流量特征，那你这样就没意义了。

[starryloki]

@LinePro OP 的方法并不完全使用域名来防止探测，还使用了路径，路径对于防火墙设备是不可见的

[MFWT]

@LinePro
实测有效，估计如果有其他错误状态码也可以依葫芦画瓢

[MFWT]

@LinePro

SNI 是肯定能获取的了（毕竟没有开 eSNI ），但是这个情况就不在本文考虑范围内了，本文主要考虑是『运营商不对 TLS 流量额外探测，仅主动探测此端口是否为 HTTP(S)服务器』的情况

[LinePro]

@starryloki #18

运营商不需要探测到合法路径，只需要知道开的是 HTTP(S) 服务就行，也属于题目中所说的家宽开服务了。

[leoking6]

@LinePro 您这个是对的，444 是低版本无奈之举，ssl_reject_handshake 才是正道

[lianyue]

走非 80 8080 443 8443 都会被检测到？

要不做个 ui 伪装成 监控 web 页面 走非上面的端口 比如 走 8000
需要登录才能继续操作

[oovveeaarr]

帮助不大，都是对流量做 DPI 的，没必要主动探测。

[BigShot404]

@lianyue #23 能，连你用哪个端口，请求的什么 URL ，一清二楚。

[xqzr]

配合 reset_timedout_connection on; 可以重置连接

[MFWT]

@lianyue 理论上运营商有这个能力做 DPI ，就看他们愿不愿意投入成本了，而且之前也有路由器/NAS 管理页面透出去而被查的，实属冤枉，但是运营商就是这么干的

[lianyue]

@MFWT 我想的是 伪装成监控, 就算被封了也可以 找借口说这是 监控 页面，走 https 海康威视 的 ui 被查了也有借口

[lianyue]

我以前申请公网 ip 也是 有监控 这个借口， 到现在 公网 ip 都还在

[yulihao]

@MFWT 广东移动不查吧，我广移 IPV6 挂 NAS 一个 web 页面（非标），套群晖 ddns 域名用这么多年了也没见上门

[yulihao]

@yulihao 无论是 tls 还是不加密都没被查过

[MFWT]

@yulihao

小心驶得万年船呢，不查的话最好，查的话就尽量减少特征暴露了

[Terminl]

不一定要阻断。也可以返回空信息。如果是自己用验证 UA 就可以了。