Кurl на Ubuntu 24.04: Ошибка получения (35)

Вопрос или проблема

Я сталкиваюсь с проблемами с curl на моей системе Ubuntu 24.04 при попытке доступа к HTTPS URL. В частности, когда я запускаю curl https://google.com, я получаю ошибку: curl: (35) Recv failure: Connection reset by peer.

Я успешно пингую google.com, и когда я запускаю curl -4 https://google.com, я получаю HTML-ответ, указывающий на 301 редирект на https://www.google.com/. Я подозреваю, что это может быть связано с конфигурацией DNS или настройками брандмауэра, но не знаю, как продолжить.

  1. Проверил, что OpenSSL и curl обновлены (OpenSSL 3.0.13 и curl 8.5.0).
  2. Проверил свой /etc/resolv.conf:
# Это файл /run/systemd/resolve/stub-resolv.conf, управляемый man:systemd-resolved(8).
# Не редактируйте.
#
# Этот файл может быть связан как /etc/resolv.conf. Если вы смотрите на
# /etc/resolv.conf и видите этот текст, значит, вы следовали по символьной ссылке.
#
# Это динамический файл resolv.conf для подключения местных клиентов к
# внутреннему DNS-резолверу systemd-resolved. Этот файл перечисляет все
# сконфигурированные домены поиска.
#
# Запустите "resolvectl status", чтобы увидеть детали о DNS-серверах,
# которые в данный момент используются.
#
# Обычно сторонние программы не должны иметь доступ к этому файлу напрямую, а только
# через символьную ссылку в /etc/resolv.conf. Чтобы управлять man:resolv.conf(5) другим
# способом, замените эту символьную ссылку на статический файл или другую символьную ссылку.
#
# Смотрите man:systemd-resolved.service(8) для получения дополнительных сведений о поддерживаемых режимах
# работы для /etc/resolv.conf.

nameserver 127.0.0.53
options edns0 trust-ad
search .
  1. Запустил resolvectl status:
Global
         Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub

Link 2 (enp7s0)
    Current Scopes: none
         Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 3 (wlp8s0)
    Current Scopes: DNS
         Protocols: +DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.163.60
       DNS Servers: 192.168.163.60 2a01:5ec0:e801:c85c::18
  1. Также попробовал с curl -vvv https://google.com. Вот вывод:
* Хост google.com:443 был разрешен.
* IPv6: 2001:4860:4802:32::78
* IPv4: 216.239.38.120
*   Пытаюсь [2001:4860:4802:32::78]:443...
* Подключен к google.com (2001:4860:4802:32::78) порт 443
* ALPN: curl предлагает h2,http/1.1
* TLSv1.3 (OUT), TLS рукопожатие, приветствие клиента (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* Recv failure: Connection reset by peer
* OpenSSL SSL_connect: Connection reset by peer в соединении с google.com:443 
* Закрытие соединения
curl: (35) Recv failure: Connection reset by peer

Я не знаю, почему, но когда я использую VPN (я использовал Nekoray), это работает.

Вывод при использовании VPN:

❯ curl -vvv https://google.com
* Использует переменную окружения прокси no_proxy == 'localhost,127.0.0.0/8,::1'
* Использует переменную окружения прокси https_proxy == 'http://127.0.0.1:2081/'
*   Пытаюсь 127.0.0.1:2081...
* Подключен к 127.0.0.1 (127.0.0.1) порт 2081
* Туннель CONNECT: HTTP/1.1 согласован
* выделение буфера подключения
* Установление HTTP прокси-туннеля к google.com:443
> CONNECT google.com:443 HTTP/1.1
> Host: google.com:443
> User-Agent: curl/8.5.0
> Proxy-Connection: Keep-Alive
> 
< HTTP/1.1 200 Соединение установлено
< 
* Фаза CONNECT завершена
* Туннель CONNECT установлен, ответ 200
* ALPN: curl предлагает h2,http/1.1
* TLSv1.3 (OUT), TLS рукопожатие, приветствие клиента (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS рукопожатие, приветствие сервера (2):
* TLSv1.3 (IN), TLS рукопожатие, Зашифрованные расширения (8):
* TLSv1.3 (IN), TLS рукопожатие, Сертификат (11):
* TLSv1.3 (IN), TLS рукопожатие, Проверка сертификата (15):
* TLSv1.3 (IN), TLS рукопожатие, Завершено (20):
* TLSv1.3 (OUT), TLS смена шифра, Изменить спецификацию шифра (1):
* TLSv1.3 (OUT), TLS рукопожатие, Завершено (20):
* SSL-соединение с использованием TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519 / id-ecPublicKey
* ALPN: сервер принял h2
* Сертификат сервера:
*  тема: CN=*.google.com
*  дата начала: 26 авг 2024 06:33:47 GMT
*  дата окончания: 18 ноя 2024 06:33:46 GMT
*  subjectAltName: хост "google.com" соответствует сертификату "google.com"
*  издатель: C=US; O=Google Trust Services; CN=WR2
*  SSL-сертификат успешно проверен.
*   Уровень сертификата 0: Тип открытого ключа EC/prime256v1 (256/128 бит/сек), подписанный с использованием sha256WithRSAEncryption
*   Уровень сертификата 1: Тип открытого ключа RSA (2048/112 бит/сек), подписанный с использованием sha256WithRSAEncryption
*   Уровень сертификата 2: Тип открытого ключа RSA (4096/152 бит/сек), подписанный с использованием sha384WithRSAEncryption
* использование HTTP/2
* [HTTP/2] [1] ОТКРЫТ поток для https://google.com/
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: google.com]
* [HTTP/2] [1] [:path: /]
* [HTTP/2] [1] [user-agent: curl/8.5.0]
* [HTTP/2] [1] [accept: */*]
> GET / HTTP/2
> Host: google.com
> User-Agent: curl/8.5.0
> Accept: */*
> 
* TLSv1.3 (IN), TLS рукопожатие, Билет новой сессии (4):
* TLSv1.3 (IN), TLS рукопожатие, Билет новой сессии (4):
* старый SSL идентификатор сессии устарел, удаление
< HTTP/2 301 
< location: https://www.google.com/
< content-type: text/html; charset=UTF-8
< content-security-policy-report-only: object-src 'none';base-uri 'self';script-src 'nonce-iuakndeP211B810I4MYmMQ' 'strict-dynamic' 'report-sample' 'unsafe-eval' 'unsafe-inline' https: http:;report-uri https://csp.withgoogle.com/csp/gws/other-hp
< date: Wed, 25 Sep 2024 12:28:25 GMT
< expires: Fri, 25 Oct 2024 12:28:25 GMT
< cache-control: public, max-age=2592000
< server: gws
< content-length: 220
< x-xss-protection: 0
< x-frame-options: SAMEORIGIN
< alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000
< 
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Мoved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
Документ был перемещен
<A HREF="https://www.google.com/">здесь</A>.
</BODY></HTML>
* Соединение #0 с хостом 127.0.0.1 осталось не тронутым

ОС: Ubuntu v24.04

Ответ или решение

Проблема с ошибкой curl: (35) Recv failure: Connection reset by peer при попытке доступа к HTTPS-URL, такой как https://google.com, может быть вызвана несколькими факторами. Давайте рассмотрим возможные причины и решения этой проблемы, основываясь на предоставленной вами информации:

1. Проверка настройки DNS

Хотя вы упомянули, что ваш DNS-сервер (192.168.163.60) работает, есть возможность, что он неправильно обрабатывает запросы к определенным сайтам или протоколам. Попробуйте заменить DNS-сервер на общедоступный, например, Google DNS (8.8.8.8 и 8.8.4.4) или Cloudflare DNS (1.1.1.1).

Пошаговая инструкция:

  • Откройте файл /etc/systemd/resolved.conf для редактирования:
    sudo nano /etc/systemd/resolved.conf
  • Найдите строку #DNS= и замените её на:
    DNS=8.8.8.8 8.8.4.4
  • Сохраните файл и перезапустите службу:
    sudo systemctl restart systemd-resolved

2. Настройка брандмауэра

Проблема может быть связана с правилами брандмауэра, блокирующими исходящие соединения. Чтобы проверить состояние UFW (Uncomplicated Firewall), выполните следующие команды:

sudo ufw status

Если UFW активен и блокирует некоторые порты, вы можете временно отключить его для тестирования:

sudo ufw disable

3. Проблемы с OpenSSL и Curl

Обновление OpenSSL и curl, которое вы уже проверили, — это хороший шаг. Убедитесь, что нет конфликтов между версиями библиотек. Также проверьте, что у вас установлены все необходимые пакеты для работы с HTTPS.

4. Проверка Proxy

Судя по вашему описанию, кажется, что с использованием VPN соединение проходит успешно. Это может указывать на наличие неправильно настроенного прокси-сервера. Проверьте переменные окружения, связанные с прокси, такие как http_proxy и https_proxy:

echo $http_proxy
echo $https_proxy

Если они установлены неправильно, попробуйте очистить их:

unset http_proxy
unset https_proxy

5. Логи системы

Обратите внимание на логи системы, связанные с сетью, которые могут содержать дополнительную информацию о причинах сбоя:

journalctl -xe

6. Проверьте настройки сети

Иногда проблема может быть связана с сетевыми настройками. Попробуйте перезагрузить сетевой интерфейс:

sudo systemctl restart NetworkManager

7. Обновление системы

Убедитесь, что ваша система обновлена полностью. Запустите:

sudo apt update && sudo apt upgrade

Заключение

Если после выполнения всех этих шагов проблема продолжает существовать, попробуйте проверить, не является ли это проблемой на уровне вашего интернет-провайдера или сетевого оборудования, такого как маршрутизатор. Также может быть полезным протестировать соединение на другом устройстве в той же сети.

Если ничего из вышеописанного не помогает, вы можете рассмотреть возможность использования VPN как временное решение до выяснения основной причины проблемы.

Оцените материал
Добавить комментарий

Капча загружается...