1

在谷歌计算节点中，当我运行此命令时curl -v https://www1.nseindia.com/，该命令在 TLS 握手后立即卡住。

* Expire in 50 ms for 1 (transfer 0x562c94210f50)
*   Trying 23.199.139.58...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x562c94210f50)
* Connected to www1.nseindia.com (23.199.139.58) 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 handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: C=IN; ST=Maharashtra; L=Mumbai; O=National Stock Exchange of India Ltd.; CN=www.nseindia.com
*  start date: Sep  2 00:00:00 2020 GMT
*  expire date: Dec 12 12:00:00 2020 GMT
*  subjectAltName: host "www1.nseindia.com" matched cert's "www1.nseindia.com"
*  issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=GeoTrust RSA CA 2018
*  SSL certificate verify ok.
> GET / HTTP/1.1
> Host: www1.nseindia.com
> User-Agent: curl/7.64.0
> Accept: */*
> 
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing

tshark 清楚地表明 TLS 握手已经完成，并且 curl 客户端确实发送了 HTTP GET 请求，之后服务器没有响应。

Running as user "root" and group "root". This could be dangerous.
Capturing on 'ens4'
    1 0.000000000   10.148.0.2 → 23.199.139.58 TCP 74 51830 → 443 [SYN] Seq=0 Win=65320 Len=0 MSS=1420 SACK_PERM=1 TSval=2896975156 TSecr=0 WS=128
    2 0.014462698 23.199.139.58 → 10.148.0.2   TCP 74 443 → 51830 [SYN, ACK] Seq=0 Ack=1 Win=28960 Len=0 MSS=1460 SACK_PERM=1 TSval=979210844 TSecr=2896975156 WS=12
8
    3 0.014506462   10.148.0.2 → 23.199.139.58 TCP 66 51830 → 443 [ACK] Seq=1 Ack=1 Win=65408 Len=0 TSval=2896975170 TSecr=979210844
    4 0.015855789   10.148.0.2 → 23.199.139.58 TLSv1 583 Client Hello
    5 0.029133295 23.199.139.58 → 10.148.0.2   TCP 66 443 → 51830 [ACK] Seq=1 Ack=518 Win=30080 Len=0 TSval=979210859 TSecr=2896975171
    6 0.029490908 23.199.139.58 → 10.148.0.2   TLSv1.3 4162 Server Hello, Change Cipher Spec, Application Data
    7 0.029515497   10.148.0.2 → 23.199.139.58 TCP 66 51830 → 443 [ACK] Seq=518 Ack=4097 Win=62848 Len=0 TSval=2896975185 TSecr=979210859
    8 0.031222072 23.199.139.58 → 10.148.0.2   TCP 1474 443 → 51830 [ACK] Seq=4097 Ack=518 Win=30080 Len=1408 TSval=979210861 TSecr=2896975171 [TCP segment of a rea
ssembled PDU]
    9 0.031238234   10.148.0.2 → 23.199.139.58 TCP 66 51830 → 443 [ACK] Seq=518 Ack=5505 Win=64128 Len=0 TSval=2896975187 TSecr=979210861
   10 0.042769026 23.199.139.58 → 10.148.0.2   TLSv1.3 858 Application Data, Application Data, Application Data
   11 0.042797990   10.148.0.2 → 23.199.139.58 TCP 66 51830 → 443 [ACK] Seq=518 Ack=6297 Win=64128 Len=0 TSval=2896975198 TSecr=979210872
   12 0.043898975   10.148.0.2 → 23.199.139.58 TLSv1.3 146 Change Cipher Spec, Application Data
   13 0.044187939   10.148.0.2 → 23.199.139.58 TLSv1.3 169 Application Data
   14 0.057149099 23.199.139.58 → 10.148.0.2   TLSv1.3 353 Application Data
   15 0.057313736 23.199.139.58 → 10.148.0.2   TLSv1.3 353 Application Data
   16 0.057462731   10.148.0.2 → 23.199.139.58 TCP 66 51830 → 443 [ACK] Seq=701 Ack=6871 Win=64128 Len=0 TSval=2896975213 TSecr=979210887
   17 0.274408940   10.148.0.2 → 23.199.139.58 TCP 169 [TCP Retransmission] 51830 → 443 [PSH, ACK] Seq=598 Ack=6871 Win=64128 Len=103 TSval=2896975430 TSecr=9792108
87
   18 0.494346208   10.148.0.2 → 23.199.139.58 TCP 169 [TCP Retransmission] 51830 → 443 [PSH, ACK] Seq=598 Ack=6871 Win=64128 Len=103 TSval=2896975650 TSecr=9792108
87
   19 0.938332610   10.148.0.2 → 23.199.139.58 TCP 169 [TCP Retransmission] 51830 → 443 [PSH, ACK] Seq=598 Ack=6871 Win=64128 Len=103 TSval=2896976094 TSecr=9792108
87
   20 1.834328400   10.148.0.2 → 23.199.139.58 TCP 169 [TCP Retransmission] 51830 → 443 [PSH, ACK] Seq=598 Ack=6871 Win=64128 Len=103 TSval=2896976990 TSecr=9792108

杀死 curl 客户端后，我还可以看到 [FIN, ACK]，但是当客户端卡住时，服务器没有入口响应。

* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing

我们可以排除来自 curl 的以下日志，因为我在另一个仅支持 HTTP1.1 和 TLS1.2 的站点上尝试了 GET，它也可以工作并记录相同的行。这个问题只发生在这个站点上，即https://www1.nseindia.com/并且对于我尝试过的所有其他站点都运行良好。

我的问题是：

  1. 为什么 TLS 握手后通信通道不起作用？如果这是防火墙的问题，我的预期是 TLS 通道永远不会建立。
  2. 对此站点的 curl 命令不起作用的根本原因是什么？
  3. 如何使该站点的 curl 命令正常工作？

注意：这在我测试过的所有其他非谷歌计算节点上都可以正常工作。

我真的希望这只是一个防火墙问题。如果可以帮助任何人回答这个问题，请询问更多详细信息。

4

3 回答 3

0

我已经从不同的环境中进行了一些卷曲测试，但结果总是一样的，卷曲卡住而没有响应。

我从 GCP（windows 和 linux）、ubuntu PC、Windows PC 都试过了，还请了一个离我很远的朋友测试，结果是一样的。

所以，根据你的第一个问题；这让我觉得 url 主机上有一些东西，在 TLS 握手完成后；“阻止”或“停止”通信。

我不太确定它是证书还是服务器本身。如果可能的话，您能否在显示测试完成时分享一个卷曲？如果共享测试的位置也会很有帮助。

您的第二个和第三个问题是，如果它只是执行 curl，让我回顾一下我是否可以在另一个测试中思考或可以帮助我们找到答案的东西。

于 2020-09-28T22:27:53.207 回答
0

@blueboy1115 非常感谢您检查这一点。根据您的测试，我想您是对的，如果 IP 可能不在印度，则服务器会阻止通信。我的谷歌云实例不是来自印度，因为谷歌云没有任何资源可分配给印度的新实例。

我在印度的笔记本电脑上运行的任何浏览器和 python 脚本都可以访问该站点。但是，当我在美国、新加坡和悉尼托管的 google VM 实例上执行时，相同的 python 脚本会卡住。

在谷歌实例中：

* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x55e45a305f50)
> GET / HTTP/2
> Host: www.nseindia.com
> User-Agent: curl/7.64.0
> Accept: */*
> 
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
< HTTP/2 403 
< server: AkamaiGHost
< mime-version: 1.0
< content-type: text/html
< content-length: 265
< expires: Thu, 01 Oct 2020 05:10:13 GMT
< date: Thu, 01 Oct 2020 05:10:13 GMT
< 
<HTML><HEAD>
<TITLE>Access Denied</TITLE>
</HEAD><BODY>
<H1>Access Denied</H1>
 
You don't have permission to access "http&#58;&#47;&#47;www&#46;nseindia&#46;com&#47;" on this server.<P>
Reference&#32;&#35;18&#46;5a0a0f17&#46;1601529013&#46;19fc9a7
</BODY>
</HTML>

-在我在印度的 Windows 笔记本电脑上有趣的是，在我在印度 ISP 上的 Windows 笔记本电脑上，该网站正在浏览器上运行，并且可以使用 urllib 库通过 python 脚本访问，www1.nseindia.com 和www.nseindia的 curl 命令都失败.com超时后，都尝试 http1.1，因为我的 Windows curl 不支持 HTTP2。

我得出的结论是，服务器仅支持 HTTP2 并拒绝在 TLS 握手后不在印度托管的 IP 地址。这就是为什么它可以通过浏览器和带有 urllib 的 python 在我的本地笔记本电脑上运行的原因。

如果有人有任何其他结论，请分享。

于 2020-10-01T05:34:31.713 回答
0

从发布的结果/日志看来，无论平台如何（gcp 等），托管服务器似乎都在该区域接受/拒绝发送的请求，通常这样做是为了防止数据/网络抓取，这可能是在远程服务器端（nseindia）实现的安全机制之一。这就是curl -v https://www1.nseindia.com在 TLS 握手完成后进入陈旧会话的原因。

于 2021-05-21T13:36:39.873 回答