Вопрос или проблема
Некоторые сайты не принимают HTTP-запросы с моего VPS.
Например, https://openvpn.net отклоняет запрос:
root@vm3226933:~# curl -vvvv --head https://openvpn.net
* Trying 104.19.190.106:443...
* Connected to openvpn.net (104.19.190.106) port 443 (#0)
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
* OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to openvpn.net:443
* Closing connection 0
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to openvpn.net:443
Дополнительный низкоуровневый запрос:
root@vm3226933:~# openssl s_client -connect openvpn.net:443 -debug -trace
CONNECTED(00000003)
Sent Record
Header:
Version = TLS 1.0 (0x301)
Content Type = Handshake (22)
Length = 312
ClientHello, Length=308
client_version=0x303 (TLS 1.2)
Random:
gmt_unix_time=0x5284377E
random_bytes (len=28): 8E8BCFC1833EC97B58643C21A64FA2CBC6A3DE29BC3D5361FDFC29EC
session_id (len=32): CCFFFE0BE78882B46FA491614BE65EBCE2852139F82D614E75B3DFC85C2E7F6F
cipher_suites (len=62)
{0x13, 0x02} TLS_AES_256_GCM_SHA384
{0x13, 0x03} TLS_CHACHA20_POLY1305_SHA256
{0x13, 0x01} TLS_AES_128_GCM_SHA256
{0xC0, 0x2C} TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
{0xC0, 0x30} TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
{0x00, 0x9F} TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
{0xCC, 0xA9} TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
{0xCC, 0xA8} TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
{0xCC, 0xAA} TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
{0xC0, 0x2B} TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
{0xC0, 0x2F} TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
{0x00, 0x9E} TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
{0xC0, 0x24} TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
{0xC0, 0x28} TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
{0x00, 0x6B} TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
{0xC0, 0x23} TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
{0xC0, 0x27} TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
{0x00, 0x67} TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
{0xC0, 0x0A} TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
{0xC0, 0x14} TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
{0x00, 0x39} TLS_DHE_RSA_WITH_AES_256_CBC_SHA
{0xC0, 0x09} TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
{0xC0, 0x13} TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
{0x00, 0x33} TLS_DHE_RSA_WITH_AES_128_CBC_SHA
{0x00, 0x9D} TLS_RSA_WITH_AES_256_GCM_SHA384
{0x00, 0x9C} TLS_RSA_WITH_AES_128_GCM_SHA256
{0x00, 0x3D} TLS_RSA_WITH_AES_256_CBC_SHA256
{0x00, 0x3C} TLS_RSA_WITH_AES_128_CBC_SHA256
{0x00, 0x35} TLS_RSA_WITH_AES_256_CBC_SHA
{0x00, 0x2F} TLS_RSA_WITH_AES_128_CBC_SHA
{0x00, 0xFF} TLS_EMPTY_RENEGOTIATION_INFO_SCSV
compression_methods (len=1)
No Compression (0x00)
extensions, length = 173
extension_type=server_name(0), length=16
0000 - 00 0e 00 00 0b 6f 70 65-6e 76 70 6e 2e 6e 65 .....openvpn.ne
000f - 74 t
extension_type=ec_point_formats(11), length=4
uncompressed (0)
ansiX962_compressed_prime (1)
ansiX962_compressed_char2 (2)
extension_type=supported_groups(10), length=22
ecdh_x25519 (29)
secp256r1 (P-256) (23)
ecdh_x448 (30)
secp521r1 (P-521) (25)
secp384r1 (P-384) (24)
ffdhe2048 (256)
ffdhe3072 (257)
ffdhe4096 (258)
ffdhe6144 (259)
ffdhe8192 (260)
extension_type=session_ticket(35), length=0
extension_type=encrypt_then_mac(22), length=0
extension_type=extended_master_secret(23), length=0
extension_type=signature_algorithms(13), length=42
ecdsa_secp256r1_sha256 (0x0403)
ecdsa_secp384r1_sha384 (0x0503)
ecdsa_secp521r1_sha512 (0x0603)
ed25519 (0x0807)
ed448 (0x0808)
rsa_pss_pss_sha256 (0x0809)
rsa_pss_pss_sha384 (0x080a)
rsa_pss_pss_sha512 (0x080b)
rsa_pss_rsae_sha256 (0x0804)
rsa_pss_rsae_sha384 (0x0805)
rsa_pss_rsae_sha512 (0x0806)
rsa_pkcs1_sha256 (0x0401)
rsa_pkcs1_sha384 (0x0501)
rsa_pkcs1_sha512 (0x0601)
ecdsa_sha224 (0x0303)
rsa_pkcs1_sha224 (0x0301)
dsa_sha224 (0x0302)
dsa_sha256 (0x0402)
dsa_sha384 (0x0502)
dsa_sha512 (0x0602)
extension_type=supported_versions(43), length=9
TLS 1.3 (772)
TLS 1.2 (771)
TLS 1.1 (770)
TLS 1.0 (769)
extension_type=psk_key_exchange_modes(45), length=2
psk_dhe_ke (1)
extension_type=key_share(51), length=38
NamedGroup: ecdh_x25519 (29)
key_exchange: (len=32): 1B7EC7B0AE2011F2A401C8E0A4B9E866D566027013D37EE4ADFE0F39393C8156
write to 0x555d7a5089c0 [0x555d7a51f070] (317 bytes => 317 (0x13D))
0000 - 16 03 01 01 38 01 00 01-34 03 03 52 84 37 7e 8e ....8...4..R.7~.
0010 - 8b cf c1 83 3e c9 7b 58-64 3c 21 a6 4f a2 cb c6 ....>.{Xd<!.O...
0020 - a3 de 29 bc 3d 53 61 fd-fc 29 ec 20 cc ff fe 0b ..).=Sa..). ....
0030 - e7 88 82 b4 6f a4 91 61-4b e6 5e bc e2 85 21 39 ....o..aK.^...!9
0040 - f8 2d 61 4e 75 b3 df c8-5c 2e 7f 6f 00 3e 13 02 .-aNu...\..o.>..
0050 - 13 03 13 01 c0 2c c0 30-00 9f cc a9 cc a8 cc aa .....,.0........
0060 - c0 2b c0 2f 00 9e c0 24-c0 28 00 6b c0 23 c0 27 .+./...$.(.k.#.'
0070 - 00 67 c0 0a c0 14 00 39-c0 09 c0 13 00 33 00 9d .g.....9.....3..
0080 - 00 9c 00 3d 00 3c 00 35-00 2f 00 ff 01 00 00 ad ...=.<.5./......
0090 - 00 00 00 10 00 0e 00 00-0b 6f 70 65 6e 76 70 6e .........openvpn
00a0 - 2e 6e 65 74 00 0b 00 04-03 00 01 02 00 0a 00 16 .net............
00b0 - 00 14 00 1d 00 17 00 1e-00 19 00 18 01 00 01 01 ................
00c0 - 01 02 01 03 01 04 00 23-00 00 00 16 00 00 00 17 .......#........
00d0 - 00 00 00 0d 00 2a 00 28-04 03 05 03 06 03 08 07 .....*.(........
00e0 - 08 08 08 09 08 0a 08 0b-08 04 08 05 08 06 04 01 ................
00f0 - 05 01 06 01 03 03 03 01-03 02 04 02 05 02 06 02 ................
0100 - 00 2b 00 09 08 03 04 03-03 03 02 03 01 00 2d 00 .+............-.
0110 - 02 01 01 00 33 00 26 00-24 00 1d 00 20 1b 7e c7 ....3.&.$... .~.
0120 - b0 ae 20 11 f2 a4 01 c8-e0 a4 b9 e8 66 d5 66 02 .. .........f.f.
0130 - 70 13 d3 7e e4 ad fe 0f-39 39 3c 81 56 p..~....99<.V
read from 0x555d7a5089c0 [0x555d7a516e53] (5 bytes => -1)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 317 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
read from 0x555d7a5089c0 [0x555d7a3f1080] (8192 bytes => 0)
В то же время другие сайты возвращают HTTP 200:
root@vm3226933:~# curl -vvvv --head https://pq.hosting
* Trying 5.252.34.78:443...
* Connected to pq.hosting (5.252.34.78) port 443 (#0)
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
* 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 h2
* Server certificate:
* subject: CN=*.pq.hosting
* start date: Jun 17 13:20:00 2024 GMT
* expire date: Jul 19 13:19:59 2025 GMT
* subjectAltName: host "pq.hosting" matched cert's "pq.hosting"
* issuer: C=BE; O=GlobalSign nv-sa; CN=GlobalSign GCC R6 AlphaSSL CA 2023
* SSL certificate verify ok.
* using HTTP/2
* h2h3 [:method: HEAD]
* h2h3 [:path: /]
* h2h3 [:scheme: https]
* h2h3 [:authority: pq.hosting]
* h2h3 [user-agent: curl/7.88.1]
* h2h3 [accept: */*]
* Using Stream ID: 1 (easy handle 0x55fa9d20dce0)
> HEAD / HTTP/2
> Host: pq.hosting
> user-agent: curl/7.88.1
> accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
< HTTP/2 200
HTTP/2 200
< server: nginx
server: nginx
< date: Mon, 30 Dec 2024 19:30:55 GMT
date: Mon, 30 Dec 2024 19:30:55 GMT
< content-length: 13534
content-length: 13534
< set-cookie: __js_p_=55,1800,0,0,1; Path=/
set-cookie: __js_p_=55,1800,0,0,1; Path=/
< cache-control: no-cache
cache-control: no-cache
< content-type: text/html; charset=utf-8
content-type: text/html; charset=utf-8
<
* Connection #0 to host pq.hosting left intact
VPS обновлен командой apt-update и apt-upgrade, имеет последнюю версию openssl:
root@vm3226933:~# uname -a
Linux vm3226933.stark-industries.solutions 6.1.0-26-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.112-1 (2024-09-30) x86_64 GNU/Linux
root@vm3226933:~# cat /etc/debian_version
12.8
root@vm3226933:~# openssl version
OpenSSL 3.0.15 3 Sep 2024 (Library: OpenSSL 3.0.15 3 Sep 2024)
Для диагностики проблемы я установил Linux локально и запросил 'проблемный' сайт:
debian12@debian12:~$ curl -vvvv --head https://openvpn.net
* Trying 104.19.190.106:443...
* Connected to openvpn.net (104.19.190.106) port 443 (#0)
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
* 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 h2
* Server certificate:
* subject: CN=*.openvpn.net
* start date: Feb 5 21:17:59 2024 GMT
* expire date: Feb 5 16:13:59 2025 GMT
* subjectAltName: host "openvpn.net" matched cert's "openvpn.net"
* issuer: C=US; ST=Arizona; L=Scottsdale; O=GoDaddy.com, Inc.; OU=http://certs.godaddy.com/repository/; CN=Go Daddy Secure Certificate Authority - G2
* SSL certificate verify ok.
* using HTTP/2
* h2h3 [:method: HEAD]
* h2h3 [:path: /]
* h2h3 [:scheme: https]
* h2h3 [:authority: openvpn.net]
* h2h3 [user-agent: curl/7.88.1]
* h2h3 [accept: */*]
* Using Stream ID: 1 (easy handle 0x5596424bace0)
> HEAD / HTTP/2
> Host: openvpn.net
> user-agent: curl/7.88.1
> accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
< HTTP/2 200
HTTP/2 200
< date: Mon, 30 Dec 2024 19:19:09 GMT
date: Mon, 30 Dec 2024 19:19:09 GMT
< content-type: text/html
content-type: text/html
< last-modified: Thu, 28 Nov 2024 17:28:54 GMT
last-modified: Thu, 28 Nov 2024 17:28:54 GMT
< etag: W/"6748a856-399b4"
etag: W/"6748a856-399b4"
< cf-cache-status: HIT
cf-cache-status: HIT
< age: 5590
age: 5590
< expires: Tue, 31 Dec 2024 00:19:09 GMT
expires: Tue, 31 Dec 2024 00:19:09 GMT
< cache-control: public, max-age=18000
cache-control: public, max-age=18000
< server: cloudflare
server: cloudflare
< cf-ray: 8fa4613e7b66f117-DME
cf-ray: 8fa4613e7b66f117-DME
<
* Connection #0 to host openvpn.net left intact
Те же самые версии ПО:
debian12@debian12:~$ uname -a
Linux debian12 6.1.0-27-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.115-1 (2024-11-01) x86_64 GNU/Linux
debian12@debian12:~$ cat /etc/debian_version
12.8
debian12@debian12:~$ openssl version
OpenSSL 3.0.15 3 Sep 2024 (Library: OpenSSL 3.0.15 3 Sep 2024)
Мой хостинг-провайдер говорит, что серверы блокируют запросы.
Верно ли это или openssl неправильно сконфигурирован?
write:errno=104
…
Мой хостинг-провайдер говорит, что серверы блокируют запросы
Это, вероятно, правильная интерпретация. errno=104 означает “сброс соединения”, что может быть вызвано сервером (или каким-то обратным прокси перед ним), который принудительно закрывает соединение. Обычно это не связано с проблемами TLS, здесь обычно появляется предупреждение SSL.
Сервер openvpn.net находится за CDN cloudflare. Этот CDN имеет множество опций для блокировки нежелательных соединений, таких как боты или атакой отказа в обслуживании. Поставщик, которого вы, кажется, используете для вашего VM (Starck Industries), не имеет очень хорошую репутацию в этом отношении, см., например, Stark Industries Solutions: An Iron Hammer in the Cloud. Поэтому вполне вероятно, что они решили заблокировать доступ от этого провайдера по соображениям безопасности.
Ответ или решение
Проанализируем проблему с установкой TLS-соединения
Вы столкнулись с проблемой, когда некоторые веб-сайты, в частности openvpn.net, отказываются обрабатывать HTTP-запросы с вашего VPS, в то время как другие сайты, такие как pq.hosting, работают корректно. Это явление может быть связано с несколькими факторами.
1. Ошибка errno=104
Сообщение об ошибке errno=104, возникающее при попытке установить TLS-соединение, указывает на "сброс соединения". Это означает, что сервер или промежуточный прокси-сервер принудительно закрывает соединение. Этот тип ошибок часто не связан с ошибками в настройках TLS, которые обычно сопровождаются предупреждениями SSL.
2. Возможные причины сброса соединения
Современные CDN-сети, такие как Cloudflare, под управлением которой находится openvpn.net, имеют инструменты для блокировки потенциально нежелательных соединений. Одной из частых причин блокировки может быть подозрение на вредоносную активность, исходящую с IP-адресов, предоставляемых определенными провайдерами хостинга.
На основании вашего описания, провайдер вашего VPS, вероятно, Stark Industries. Этот провайдер, как следует из публикации на krebsonsecurity.com, имеет не лучшую репутацию, что может стать причиной ограничения доступа с его IP-адресов к определённым ресурсам, чтобы предотвратить DDOS-атаки или другие вредоносные действия.
3. Диагностика и решение
-
Проверьте блокировку IP: Вы можете попробовать использовать инструменты, такие как traceroute или telnet, чтобы определить, где именно происходит сброс соединения. Это может помочь понять, происходит ли блокировка на уровне сети или на стороне сервера.
-
Обратитесь к провайдеру: Свяжитесь с вашим провайдером VPS, чтобы уточнить, включены ли какие-либо ограничения или блокировки для вашего IP.
-
Используйте VPN или прокси: Иногда использование VPN или прокси-сервера с другим IP-адресом может обойти подобные блокировки.
-
Настройки брандмауэра: Убедитесь, что настройки брандмауэра на вашем VPS не препятствуют исходящему трафику на порт 443.
-
Обновления и патчи: Держите вашу систему и OpenSSL в актуальном состоянии, хотя уже указано, что они обновлены, подобная проверка никогда не будет лишней.
Заключение
Проблема с установкой TLS-соединения может быть связана не с ошибкой в конфигурации OpenSSL, а с блокировками на стороне CDN или сетевого оборудования из-за репутации хостинг-провайдера. Рекомендуется рассмотреть возможность смены IP или даже провайдера хостинга. Такое решение поможет избежать дальнейших проблем с доступом к ресурсам. Тщательная диагностика поможет определить точную причину сбоя и принять соответствующие меры.