Linux: apt/yum/dnf зависают — проверяем DNS, IPv6 и MTU (практический чеклист)

Симптом знакомый: apt update висит на «Connecting…», yum или dnf периодически уходят в таймаут, а браузер при этом «вроде работает». На практике это почти всегда один из трёх классов проблем: DNS (включая systemd-resolved), IPv6-связность (или её поломанная половинка) и MTU/PMTUD (когда TCP-сессия есть, но крупные пакеты «застревают»).

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

Как понять, на каком этапе зависает пакетный менеджер

Первое правило: не лечим «интернет», пока не увидим, где именно пауза — на DNS, на TCP/TLS или на скачивании конкретного файла.

apt: включаем подробный вывод

sudo apt-get -o Debug::Acquire::http=true -o Debug::Acquire::https=true update

В выводе важны места, где долго нет прогресса: «Resolving…» (DNS), «Connecting…» (маршрутизация/IPv6/файрвол), «Handshake…» (TLS/прокси/перехват), «Waiting for headers…» (часто MTU/PMTUD или проблемы на пути).

dnf/yum: смотрим, что именно ждёт

sudo dnf -v makecache

sudo yum -v makecache

Если видно много ретраев к одному зеркалу — это уже подсказка: либо DNS отдаёт «плохой» адрес, либо IPv6 пытается, но не может, либо MTU ломает крупные ответы.

Быстрая проверка «вне пакетного менеджера»

Чтобы исключить особенности apt/dnf и проверить базовую HTTPS-доставку до репозитория, сделайте запрос вручную.

curl -I -v https://deb.debian.org/

Если нужен детальный трассинг по времени:

curl --trace-time --trace-ascii /tmp/curl.trace -L https://deb.debian.org/

Файл /tmp/curl.trace покажет, на каком шаге зависает: DNS, connect, TLS, чтение.

DNS-диагностика: systemd-resolved и /etc/resolv.conf

Пакетные менеджеры очень чувствительны к DNS. Даже кратковременные SERVFAIL или таймауты превращаются в «apt update stuck» и «dnf timeout», потому что репозитории — это много доменов, редиректов и CDN.

Проверяем, кто резолвит имена

resolvectl status

ls -l /etc/resolv.conf

Если /etc/resolv.conf — ссылка на /run/systemd/resolve/stub-resolv.conf, то запросы идут через локальный stub 127.0.0.53 (это systemd-resolved). Тогда «сломаться» может как апстрим DNS, так и сам resolved (кэш, DNSSEC, split DNS, корпоративные настройки).

Тест резолвинга (A/AAAA) и сравнение результатов

getent ahosts deb.debian.org

resolvectl query deb.debian.org

Если вы видите AAAA-записи (IPv6) — это нормально, но дальше важно, работает ли IPv6-маршрут, иначе получите «подвисания» на connect.

Когда проблема именно в systemd-resolved

Частая история: resolved «залип» на проблемном апстриме или спорит с DNSSEC. Для диагностики смотрим логи и статистику.

sudo journalctl -u systemd-resolved --since "-30 min"

resolvectl statistics

В логах ищите массовые SERVFAIL, timeout, сообщения про DNSSEC/validation.

Минимальный безопасный сброс

sudo resolvectl flush-caches

sudo systemctl restart systemd-resolved

После этого повторите resolvectl query и пробный curl -I -v. Если стало лучше — причина почти наверняка в локальном резолвере или апстриме DNS.

Не торопитесь «просто прописать публичный DNS» везде и навсегда. На серверах с VPN, приватными зонами или split DNS это может сломать доступ к внутренним именам. Сначала выясните, откуда должны приходить DNS-настройки (DHCP, NetworkManager, systemd-networkd, cloud-init).

Если вы размещаете проекты на VDS, имеет смысл один раз зафиксировать рабочую схему DNS (кто управляет /etc/resolv.conf, какие апстримы, нужен ли DNSSEC), чтобы обновления не «вставали» после очередного изменения сети или VPN.

IPv6: когда AAAA есть, а пути нет

Типичный сценарий: DNS отдаёт AAAA, клиент пробует IPv6, а IPv6 фактически не работает (нет маршрута, режется файрволом, сломан RA/DHCPv6, проблемы у провайдера). Из-за Happy Eyeballs часть приложений быстро переключается на IPv4, а часть — «думает» дольше, что выглядит как зависание.

Проверяем адреса и маршрут по умолчанию

ip -6 addr

ip -6 route

Должен быть default route вида default via .... Если его нет — IPv6 «номинальный» (адрес может быть, а выхода нет).

Проверяем связность до внешнего мира

ping -6 -c 3 2606:4700:4700::1111

curl -6 -I -v https://deb.debian.org/

Если curl -6 стабильно не работает, а curl -4 работает — это почти доказательство, что таймауты пакетного менеджера вызваны проблемным IPv6.

Проверка гипотезы: принудительно IPv4

Для apt:

sudo apt-get -o Acquire::ForceIPv4=true update

Для dnf/yum проще всего проверить репозиторий через curl -4. Если форс IPv4 резко лечит ситуацию — дальше устраняем IPv6 (маршрут, firewall, RA) или отключаем его осознанно.

Аккуратное отключение IPv6 (временный workaround)

Если нужно быстро восстановить обновления и вы понимаете последствия, можно временно выключить IPv6 через sysctl (до перезагрузки или до применения постоянной конфигурации).

sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1

sudo sysctl -w net.ipv6.conf.default.disable_ipv6=1

Если проблема исчезла — возвращайтесь к корню: почему IPv6 не маршрутизируется или где он фильтруется.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

MTU и PMTUD: «подключается, но не качает»

MTU-проблемы — один из самых неприятных источников «зависаний» без явных ошибок. Классика: вы подключены через туннель (VPN, PPPoE, overlay), MTU меньше стандартных 1500, а ICMP (особенно ICMPv6) где-то режется. В итоге PMTUD не работает, большие TCP-сегменты теряются, и загрузка метаданных репозитория подвисает.

Быстрая проверка MTU на интерфейсе

ip link show

Смотрите MTU у основного интерфейса (часто eth0, ens3, enp*) и у туннелей.

Проверяем «проходимый размер» (IPv4)

Идея: найти максимальный размер без фрагментации (DF). Для Ethernet 1500 полезная нагрузка ICMP обычно 1472 (1500 - 20 IP - 8 ICMP).

ping -c 3 -M do -s 1472 1.1.1.1

Если получаете Message too long или таймаут — уменьшайте -s (например, 1464, 1452, 1412) и фиксируйте рабочее значение.

Проверяем «проходимый размер» (IPv6)

Для IPv6 PMTUD критичнее, а фильтрация ICMPv6 ломает сеть сильнее.

ping -6 -c 3 -s 1452 2606:4700:4700::1111

Если на небольших размерах работает, а на больших — нет, и при этом apt/dnf зависают на TLS или скачивании, MTU/PMTUD — главный подозреваемый.

Что делать, если PMTUD ломается

• Разрешить ICMP/ICMPv6 (особенно Packet Too Big, Time Exceeded) на пути. Жёсткие правила файрвола часто и являются причиной.

• Понизить MTU на проблемном интерфейсе или туннеле до гарантированно проходного (например, 1450 или 1420 — зависит от оверлея/VPN).

• Проверить MSS clamping на пограничных устройствах, если вы контролируете NAT/шлюз.

tcpdump: подтверждаем, что именно «висит»

Если нужно доказательство на уровне пакетов (или вы не доверяете симптомам), включайте tcpdump. Важно: не снимайте «всё подряд» часами — фильтруйте по хосту/порту.

Смотрим DNS-запросы

sudo tcpdump -ni any port 53

Если видите повторяющиеся запросы без ответов — проблема между вами и DNS-сервером (маршрутизация, firewall, апстрим). Если ответы есть, но с большими задержками — виноват DNS-апстрим или перегруженный локальный резолвер.

Смотрим HTTPS к репозиторию

sudo tcpdump -ni any 'tcp port 443'

Признаки MTU/PMTUD: повторные retransmissions, «дырки» в ACK, зависание после отправки ClientHello/ServerHello или при скачивании больших объектов. Признаки проблемного IPv6: попытки connect по IPv6 без дальнейшего прогресса.

Частые причины и быстрые исправления (по симптомам)

Симптом: «Resolving…» долго, потом таймаут

• Проверить resolvectl status, апстрим DNS и логи systemd-resolved.

• Сравнить getent ahosts и resolvectl query.

• Сбросить кэш: resolvectl flush-caches и повторить проверку.

Симптом: «Connecting…» или «Handshake…» висит, но DNS быстрый

• Проверить IPv6: curl -6 и ip -6 route. Для проверки гипотезы временно форсировать IPv4.

• Проверить MTU: ping -M do для IPv4 и тест ping -6 для IPv6.

• Снять короткий tcpdump на 443 и посмотреть retransmissions.

Симптом: работает только через VPN или только без VPN

• Сверить DNS до и после VPN (split DNS может менять резолвинг репозиториев или ломать DNSSEC).

• Проверить MTU туннеля: VPN часто требует меньший MTU.

• Проверить, не становится ли VPN IPv6-маршрут дефолтным и не ломает ли выход.

Мини-ранбук: от «apt update stuck» до диагноза за 10 минут

1. DNS: resolvectl query deb.debian.org и getent ahosts deb.debian.org.

2. IPv6: curl -6 -I -v https://deb.debian.org/ и ip -6 route.

3. IPv4: curl -4 -I -v https://deb.debian.org/ (сравнить задержки).

4. MTU/PMTUD: ping -c 3 -M do -s 1472 1.1.1.1 (уменьшать размер до успешного).

5. Подтверждение пакетами: короткий захват tcpdump -ni any port 53 или tcpdump -ni any 'tcp port 443'.

Что полезно зафиксировать в постмортеме

Чтобы проблема не повторялась «внезапно» через месяц, стоит записать:

• Какие DNS-серверы использовались (из resolvectl status), включён ли DNSSEC, есть ли split DNS.

• Состояние IPv6: адрес, default route, правила firewall для ICMPv6.

• Фактический рабочий MTU на пути и где он менялся (интерфейс, VPN, облачная сеть).

• Один «эталонный» лог: curl --trace-time и небольшой фрагмент tcpdump, подтверждающий причину.

Если зависания проявляются на нескольких проектах и вы хотите сократить количество сетевых «сюрпризов», часто проще переносить прод на управляемую инфраструктуру с предсказуемой сетью и фаерволами. Для небольших сайтов и сервисов подойдёт виртуальный хостинг, а для кастомных сетевых настроек и тонкой диагностики удобнее VDS.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Итог

Когда yum «висит», dnf уходит в таймаут или apt update застревает, в большинстве случаев виноваты не репозитории, а сеть: DNS/systemd-resolved, «кривой» IPv6 или MTU/PMTUD. Сильная сторона подхода выше — вы быстро отделяете DNS от маршрутизации, а маршрутизацию от MTU, подтверждаете гипотезу инструментами (curl trace, tcpdump) и применяете именно то исправление, которое нужно, без лишних «магических» правок.