Вопрос или проблема
Я сталкиваюсь с проблемами с 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 или настройками брандмауэра, но не знаю, как продолжить.
- Проверил, что OpenSSL и curl обновлены (
OpenSSL 3.0.13
иcurl 8.5.0
). - Проверил свой
/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 .
- Запустил
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
- Также попробовал с
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 как временное решение до выяснения основной причины проблемы.