Все об Arch Linux
Arch Linux будет тем, что вы из него сделаете!
Все об Arch Linux
Arch Linux будет тем, что вы из него сделаете!
Если AUR отдаёт EOF или error: failed retrieving file ... from aur.archlinux.org, а вместе с ними TLS-ошибки вроде tls: handshake failure, первым делом проверь четыре вещи: дату и время системы, DNS, MTU и версию openssl. Чаще всего причина в одной из них, и лечится она за пару минут. Отдельный случай: EOF из-за приоритета IPv6 в Go-резолвере, ему посвящена отдельная статья, ссылку дам ниже.
AUR-хелперы скачивают PKGBUILD и файлы с aur.archlinux.org по HTTPS. Любой сбой на пути от твоего компьютера до сервера превращается в одну из двух ошибок: EOF (соединение оборвалось до конца ответа) или tls: handshake failure (не удалось установить защищённое соединение). Причин несколько, и почти все они не связаны с самим AUR.
Самая коварная: сбитые часы. TLS-сертификаты живут по времени: если системная дата ушла вперёд или назад, клиент считает сертификат истёкшим или ещё не выпущенным и рвёт соединение. Вторая по частоте: DNS. Резолвер отдаёт неверный или чужой IP, и ты стучишься не туда. Дальше идут сетевые проблемы: маленький MTU с фрагментацией пакетов, блокировка провайдером по DPI, нестабильный VPN. И наконец, устаревшие библиотеки TLS на самой системе.
Важно понимать: EOF и TLS-ошибки это симптомы, а не диагноз. Одна и та же ошибка появляется и при сбитых часах, и при блокировке провайдером. Поэтому иди по порядку, от простого к сложному.
Разные сообщения намекают на разные слои. unexpected EOF обычно значит, что соединение оборвалось на середине передачи: пакеты теряются или кто-то рвёт поток. tls: handshake failure значит, что стороны не договорились о параметрах шифрования: устаревший клиент, сбитые часы или вмешательство в трафик. x509: certificate has expired почти всегда указывает на дату системы, а не на реальный сертификат. connection reset by peer значит, что сервер или промежуточное устройство принудительно закрыло соединение, типично для DPI.
Сбитые часы: причина номер один для серий TLS-ошибок. Проверка занимает секунду:
timedatectl
Смотри на строки System clock synchronized: yes и NTP service: active. Если синхронизации нет, включаем её:
sudo timedatectl set-ntp true
После этого убедись, что время совпадает с реальным. Разница даже в несколько минут ломает проверку сертификатов: сервер AUR видит запрос «из будущего» и отказывает. Если NTP не поднимается, возможно, проблема в DNS или в блокировке NTP-портов провайдером. Настройка часового пояса и NTP разобрана в статье «Часовой пояс и время: настройка NTP».
Забойный DNS-сервер отдаёт неверный IP для aur.archlinux.org, и хелпер уходит в никуда. Проверь, что резолвит система:
resolvectl status
Команда покажет активные DNS-серверы. Теперь резолвим адрес репозитория:
getent ahosts aur.archlinux.org
В ответе должны быть IPv4- и IPv6-адреса. Если там мусор, пустота или неожиданный IP, меняй DNS. Для точной проверки можно спросить конкретный резолвер напрямую:
dig @1.1.1.1 aur.archlinux.org +short
Если dig через 1.1.1.1 возвращает адрес, а системный резолвер нет, значит, проблема в DNS-сервере, а не в сети. Быстрый способ: переключиться на DoH или на публичные резолверы. В systemd-resolved это делается правкой /etc/systemd/resolved.conf:
sudo nano /etc/systemd/resolved.conf
Пропиши DNS=1.1.1.1 8.8.8.8 и DNSOverTLS=yes, затем перезапусти службу:
sudo systemctl restart systemd-resolved
После смены DNS повтори getent ahosts aur.archlinux.org, должен появиться нормальный адрес. Если DNS чист, а проблема осталась, двигайся дальше.
curl показывает, что именно происходит при установке соединения. Запусти:
curl -vI https://aur.archlinux.org
Флаг -v включает подробный вывод, -I запрашивает только заголовки. Смотри на строки Connected to aur.archlinux.org и SSL connection using TLS.... Если соединение обрывается на TLS handshake, проблема в TLS-стеке или в сети. Если curl работает, а yay или paru падает, дело в самом хелпере: он написан на Go и использует свой резолвер. Это отдельный случай, о нём ниже.
Обрати внимание на версию TLS в выводе. Современный сервер AUR требует TLS 1.2 или 1.3. Если curl договаривается о TLS 1.3, а хелпер падает, дело в его библиотеках, а не в сети. Если же curl сам не может подняться выше TLS 1.0, система отстала от жизни, и нужен апдейт openssl.
Проверь также, что сертификаты на месте:
curl -vI https://aur.archlinux.org 2>&1 | grep -i "subject\|issuer"
Если curl ругается на неизвестного издателя или истёкший сертификат, обнови ca-certificates:
sudo pacman -Syu ca-certificates
Если соединение рвётся на больших ответах, но работает на маленьких, подозревай MTU. Типичная картина: curl висит, потом EOF, а мелкие запросы проходят. Особенно часто это случается на VPN, PPPoE и в сетях с туннелями: там максимальный размер пакета меньше стандартных 1500 байт, и крупные TLS-ответы режутся на куски, которые теряются.
Проверь текущий MTU интерфейса:
ip link show
Если стандартные 1500 не проходят, попробуй уменьшить до 1400:
sudo ip link set dev eth0 mtu 1400
Подставь имя своего интерфейса вместо eth0 (посмотри его в ip link show). После этого повтори curl -vI https://aur.archlinux.org. Если заработало, пропиши MTU в настройках сети, чтобы он не сбрасывался после перезагрузки. Для systemd-networkd это строка MTUBytes=1400 в файле .network, для NetworkManager в профиле соединения.
Проверить фрагментацию можно и без curl: пинг с запретом фрагментации покажет, какой размер пакета реально проходит:
ping -M do -s 1472 -c 3 aur.archlinux.org
Размер 1472 плюс 28 байт заголовков даёт ровно 1500. Если пакеты теряются, уменьшай -s и подбирай рабочий MTU. Найденное значение и прописывай в настройки сети.
Некоторые провайдеры режут трафик по DPI: они видят TLS-хендшейк к неугодному хосту и рвут соединение. Симптомы те же: EOF или tls: handshake failure, при этом curl к другим сайтам работает. Отличить блокировку просто: попробуй тот же curl через прокси или VPN.
curl -vI --proxy socks5h://127.0.0.1:1080 https://aur.archlinux.org
Если через прокси соединение устанавливается, а напрямую нет, это DPI. Обход: VPN или прокси для всех запросов хелпера. Настройка прокси через переменные окружения описана в статье «Pacman и прокси: переменные окружения».
Нестабильный VPN сам по себе тоже даёт EOF: если соединение рвётся на середине ответа, проверь стабильность туннеля и MTU внутри него. Иногда помогает смена протокола с UDP на TCP или наоборот. Если VPN периодически переподключается, каждый разрыв приходится на момент скачивания, и хелпер падает с EOF. В таком случае сначала чини VPN, а уже потом смотри на AUR.
Если curl и браузер работают, а yay падает с EOF, это почти наверняка IPv6-кейс из статьи «yay выдаёт EOF при обновлении AUR: дело в IPv6». Проверяется одной командой:
getent ahosts aur.archlinux.org | head -3
Если первой строкой идёт IPv6-адрес, а IPv6-маршрута нет, ставь precedence ::ffff:0:0/96 100 в /etc/gai.conf. Если же curl тоже падает, или ошибки появляются у всех программ сразу, причина не в IPv6, а в одной из проблем выше: время, DNS, MTU, блокировка или устаревший openssl.
Если все проверки чистые, а ошибки остались, обнови системные библиотеки TLS. Старый openssl или glibc не умеют новые версии протокола и шифров, которые требует сервер:
sudo pacman -Syu openssl glibc ca-certificates
После обновления перезапусти хелпер. Иногда помогает и обновление самого хелпера: свежий yay или paru содержит исправления сетевого кода. Сравнение хелперов: в статье «yay vs paru: какой безопаснее». Общая методика диагностики таких проблем: в статье «Методика решения проблем в Arch Linux».
Почти наверняка. Проверь getent ahosts aur.archlinux.org | head -3. Если первой строкой идёт IPv6, это тот самый кейс из раздела выше, лечится строкой precedence ::ffff:0:0/96 100 в gai.conf.
Скорее всего, ничего не сломалось, а обновился сервер AUR и ужесточил требования к TLS. Проверь версию openssl и обнови его. Если обновление не помогло, смотри дату и время, они часто сбиваются после перезагрузки без NTP. Ещё один вариант: после обновления перезапустился не весь стек, и старый процесс держит старое соединение. Полный перезапуск терминала и хелпера решает и это.
Это классический признак проблем с MTU или нестабильного соединения. Мелкие запросы проходят, а крупный ответ рвётся на середине. Проверь ping -M do -s 1472 и уменьши MTU до 1400. Если после этого большие пакеты качаются, причина найдена.
Сравни прямое соединение и соединение через прокси или VPN. Если через прокси curl -vI https://aur.archlinux.org работает, а напрямую нет, это DPI. Менять DNS в этом случае бесполезно, нужен туннель.
Если DNS-сервер провайдера отдаёт неверные адреса или режет запросы, да. DoH шифрует запросы и обходит подмену. Но если проблема в DPI на уровне TLS, DoH не поможет: блокируется само соединение, а не резолвинг.
EOF и TLS-ошибки при работе с AUR почти всегда лечатся за пару минут. Порядок такой: проверь timedatectl, потом DNS через resolvectl status и getent, потом curl -vI https://aur.archlinux.org. Если соединение рвётся на больших ответах, уменьши MTU. Если работает через прокси, а напрямую нет, это блокировка провайдера, обходи её VPN. И не забудь про IPv6-кейс: если падает только yay, а curl жив, виноват приоритет адресов, а не сеть. Диагностика занимает меньше времени, чем кажется, а каждая проверка отсекает целый класс причин.
Задай вопрос в чате — отвечаем быстро, по делу и без воды.
Комментарии