分享如何使用 curl 和 openssl 命令简单测试 SNI 阻断

惊闻泉州已部署域名白名单，看到有人买域名买服务器来测试，其实用不着，还有人拿墙内的 IP 来测试，方法就错了

分享下使用 curl 和 openssl 进行简单测试的命令

随便找一个没有被墙境外 IP ，需要开着 https 服务，比如任意 cloudflare 的 IP ，此处使用 104.18.2.8 。任意编造一个白名单外的域名，比如 abc123.com

使用 openssl 测试：

openssl s_client -connect 104.18.2.8:443 -servername abc123.com

如果没有 SNI 阻断的话，返回结果如下：

CONNECTED(00000003)
140693079176320:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:../ssl/record/rec_layer_s3.c:1544:SSL alert number 40
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 302 bytes
Verification: OK

如果被 SNI 阻断的话，返回结果如下（本人所处地方没有白名单，所以使用黑名单里的域名测试，twitter.com ）：

CONNECTED(00000003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 303 bytes
Verification: OK

对比分析可以看到区别，被 SNI 阻断的域名不会收到任何服务器的回应，SSL handshake has read 0 bytes

使用 curl 测试

curl --resolve abc123.com:443:104.18.2.8 https://abc123.com -iv

如果没有 SNI 阻断的话，返回信息如下：

curl --resolve abc123.com:443:104.18.2.8 https://abc123.com -iv
* Expire in 0 ms for 6 (transfer 0x55d868a5dfb0)
* Added abc123.com:443:104.18.2.8 to DNS cache
* Hostname abc123.com was found in DNS cache
*   Trying 104.18.2.8...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x55d868a5dfb0)
* Connected to abc123.com (104.18.2.8) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS alert, handshake failure (552):
* error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure
* Closing connection 0
curl: (35) error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure

如果被 SNI 阻断的话，返回信息如下：

curl --resolve twitter.com:443:104.18.2.88 https://twitter.com -iv
* Expire in 0 ms for 6 (transfer 0x55dea6262fb0)
* Added twitter.com:443:104.18.2.88 to DNS cache
* Hostname twitter.com was found in DNS cache
*   Trying 104.18.2.88...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x55dea6262fb0)
* Connected to twitter.com (104.18.2.88) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to twitter.com:443
* Closing connection 0
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to twitter.com:443

对比分析可以看到区别，被 SNI 阻断的域名，同样收不到任何服务器的回应，正常的域名会有"TLSv1.3 (IN), TLS alert, handshake failure (552)"

测试时需要注意的是，被 SNI 阻断后，测试的 IP 也会被 IP 阻断一段时间，可以换一个 IP 继续测试

swiftg

2022-05-13 14:42:54 +08:00

@Liqianyu 又仔细测试了下，我原文最后写到的 SNI 阻断后会对被测试的 IP 进行 IP 阻断的说法不正确。

对于某些 IP ，如上面测试用的 cloudflare 的 IP ，SNI 阻断后会导致整个 IP 阻断，所有协议所有端口全都阻断。我测试到甚至整个 A 段的 IP TCP 端口全都阻断。访问 104.18.2.28 的 443 端口会导致 104.24.2.2 的所有端口被封，可谓株连九族

但对于另外一些 IP ，比如我测试的 akamai 的 IP ，如你所说，只会对该端口的 TCP 包进行丢包劣化，丢包率接近 100%，偶有几个包漏网，换 80 端口连接正常，tcmp 协议正常。差不多两分钟后 443 端口恢复正常。有趣的是，使用 v2ex.com 这种明显在黑名单里的域名作为 SNI 测试不会导致丢包劣化，看来黑名单里还有更黑的名单。但对于 cloudflare 的 IP ，使用 v2ex.com 和 twiiter 作为 SNI 域名，阻断的效果没有区别

测试丢包使用的命令 nping 23.56.30.124 --tcp-connect -p 443