Команда curl: удаленный сервер не может ответить после подтверждения TLS в вычислительном узле Google
В вычислительном узле Google, когда я запускаю эту команду
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, потому что я пробовал GET на другом сайте, который поддерживает только HTTP1.1 с TLS1.2, и он также работал и регистрировал те же строки. Эта проблема возникает только для этого одного сайта, то есть https://www1.nseindia.com/, и отлично работает для всех других сайтов, которые я пробовал.
Мои вопросы:
- Почему канал связи не работает после подтверждения TLS? Если это была проблема с брандмауэром, я ожидал, что канал TLS никогда не будет установлен.
- В чем основная причина того, что команда curl не работает на этом сайте?
- Как я могу заставить команду curl работать на этом сайте?
Примечание. Это нормально работает на всех остальных вычислительных узлах, не принадлежащих Google, которые я тестировал.
Я очень надеюсь, что это просто проблема с брандмауэром. Обязательно попросите подробностей, если это поможет кому-нибудь ответить на этот вопрос.
4 ответа
Из опубликованных результатов / журналов похоже, что хостинг-сервер, независимо от платформы (gcp и т. Д.), Отправленные запросы принимаются / отклоняются в зависимости от региона, обычно это делается для предотвращения сбора данных / веб-поиска, и это может быть один из механизмов безопасности, реализованных на стороне удаленного сервера (nseindia). Это было бы причиной
curl -v https://www1.nseindia.com переходит в устаревший сеанс после завершения TLS Handshake.
@blueboy1115 Большое спасибо за проверку. Основываясь на вашем тестировании, я думаю, вы правы, и сервер блокирует связь, если IP-адрес, вероятно, не находится в Индии. Мои экземпляры облака Google не из Индии, потому что у облака Google нет ресурсов, которые можно было бы выделить для нового экземпляра в Индии.
Этот сайт доступен в любом браузере и на скриптах Python, которые я запускаю на своем ноутбуке в Индии. Но одни и те же сценарии Python застревают, когда я запускаю экземпляр виртуальной машины Google, размещенный в Америке, Сингапуре и Сиднее.
В экземпляре Google:
- Когда я меняю URL-адрес с https://www1.nseindia.com/ на https://www.nseindia.com/, запрос становится HTTP2 и корректно завершается с ошибкой.
* 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://www.nseindia.com/" on this server.<P> Reference #18.5a0a0f17.1601529013.19fc9a7 </BODY> </HTML>
-В моем ноутбуке с Windows в Индии Интересно, что на моем ноутбуке с Windows у индийского интернет-провайдера, где сайт работает в браузере и доступен на скриптах Python с библиотекой urllib, команда curl не работает как для www1.nseindia.com, так и для http://www.nseindia.com после тайм-аута, и оба пытаются использовать http1.1, потому что мой локон Windows не поддерживает HTTP2.
Я пришел к выводу, что сервер поддерживает только HTTP2 и отклоняет IP-адреса, которые не размещены в Индии после подтверждения TLS. Это причина, по которой он работает на моем локальном ноутбуке через браузер и через python с urllib.
Если у кого-то есть другие выводы, поделитесь.
Я выполнил тест на завиток из разных сред, но результат всегда один и тот же: завиток застрял без ответа.
Я пробовал с GCP (windows и linux), ubuntu PC, Windows PC, а также попросил провести тест с моим другом далеко от меня, и результат был таким же.
Итак, согласно вашему первому вопросу; это заставляет меня думать, что на хосте url есть что-то, что после того, как рукопожатие TLS завершено; "блокирует" или "останавливает" связь.
Я не совсем уверен, может ли это быть сертификат или сам сервер. Если возможно, не могли бы вы поделиться завитком, когда он показывает, что тест был завершен? Также было бы полезно, если бы поделился местом проведения теста.
Ваш второй и третий вопрос заключается в том, что если он работает, просто выполняя завиток, позвольте мне рассмотреть, могу ли я подумать в другом тесте или чем-то, что могло бы помочь нам найти ответы.
В моем случае мне пришлось отключить ipv6 на прокси-сервере, например, в Ubuntu:
sysctl -w net.ipv6.conf.all.disable_ipv6=1
sysctl -w net.ipv6.conf.default.disable_ipv6=1