Proxmox «could not resolve host»: швидкий робочий процес для виявлення причин (DNS/IPv6/проксі)

January 19, 2026 • February 3, 2026 • Читання: 7 хв • Views: 6

Було корисно?

Немає нічого, що змушувало б вузол Proxmox відчувати себе «продакшн» так сильно, як момент, коли ви запускаєте apt update, а він відповідає: «could not resolve host». Раптом ваше вікно для патчу перетворюється на заручницьку ситуацію, ваш HA-кластер — «добре, але не зовсім», і ви дивитесь на проблему DNS, яка насправді може виявитися проблемою IPv6, маршрутизації або проксі, що існує лише в чиїйсь презентації PowerPoint.

Це швидкий, упереджений робочий процес для SRE та операторів, яким потрібно, щоб вузол оновився зараз, але які також хочуть виправити справжню причину, щоб вона не повернулася в наступне вікно обслуговування як погане продовження.

Швидка методика діагностики (перший/другий/третій)

Коли ви під контролем часу, не «пробуйте щось випадкове». Доведіть, де саме відмова. Цей план упорядкований так, щоб максимізувати сигнал за мінімальний час.

Перший: це DNS, чи базова досяжність?

Перевірте, чи вузол може дістатися до IP в інтернеті (без DNS). Якщо не може — припиніть звинувачувати DNS. Спочатку виправляйте маршрутизацію/файрвол.
Перевірте, чи вузол може розв’язати ім’я за допомогою налаштованого резолвера. Якщо ні — це проблема конфігурації DNS, недоступності DNS-сервера або сервісу резолвера.
Перевірте, чи вузол може підключитися до хоста репозиторію після резолюції. Якщо DNS працює, але TCP не вдається — це проксі/файрвол/MTU/TLS.

Другий: вирішіть, чи потрапило IPv6 у зону ураження

Перевірте, чи резолюція повертає AAAA-записи і чи система їх віддає перевагу.
Перевірте маршрутизацію IPv6. Поламаний дефолт-роут IPv6 може породити заплутані таймаути резолвера й симптоми «could not resolve host», залежно від клієнта.
Тимчасово примусово увімкніть IPv4 для швидкого операційного обходу (потім виправте IPv6 належним чином).

Третій: проксі (явні, автоконфіг, «прозорі») і особливості APT

Перевірте змінні оточення і конфіг APT для проксі. APT може працювати через проксі навіть тоді, коли ваша shell-сесія — ні.
Протестуйте прямий вихід проти проксі. Зробіть явний запит з і без проксі та порівняйте.
Підтвердіть поведінку DNS проксі. Деякі проксі резолвлять за вас; інші очікують, що вузол сам розв’яже ім’я.

Якщо слідуєте цьому порядку, ви зазвичай знайдете вузьке місце менше ніж за десять хвилин. Інакше ви витратите годину «лазячи по DNS», зламавши IPv6 і навчивши проксі брехати.

Ментальна модель: що насправді означає «could not resolve host» на Proxmox

На Proxmox (на базі Debian) «could not resolve host» зазвичай походить з одного з трьох шарів:

Резолверний шар: стек libc не може перетворити hostname в IP. Це може бути через те, що налаштований DNS-сервер недоступний, сервіс резолвера неправильно підключений, або вузол використовує несподіваний резолвер (systemd-resolved проти простого resolv.conf).
Транспортний шар, що маскується під DNS: деякі інструменти повідомляють про помилку резолюції, коли час очікування під час спроби резолюції залежить від доступності мережі (особливо при пріоритеті IPv6 або поламаних маршрутах).
Проксі-шар: клієнт вважає, що має говорити з проксі, проксі впав, проксі вимагає автентифікацію, або поведінка DNS проксі не відповідає вашій мережевій архітектурі.

Proxmox ускладнює це тим, що ваш вузол одночасно є мережеvим пристроєм. Він має бріджі, VLAN, іноді бонди, іноді кілька uplink-ів, іноді мережі управління зі спеціальним DNS. І він запускає критичні сервіси (corosync, pvedaemon, pveproxy), які ви не хочете зачіпати під час «спроби виправлення».

Правило перше: не редагуйте /etc/resolv.conf хаотично і не сподівайтесь. Доведіть шлях. Потім змініть мінімум необхідного.

Жарт #1: DNS — єдина система, де «на моєму ноуті працює» є моделлю загроз.

Цікаві факти та історичний контекст (так, це важливо)

resolv.conf старший за більшість ваших інструментів. Формат файлу походить з ранніх Unix-резолверних конвенцій і досі є опорою для багатьох сучасних налаштувань, навіть коли він — символічне посилання, яким керує щось інше.
systemd-resolved змінив стандартні режими відмов. Замість статичного /etc/resolv.conf із прямими upstream-резолверами багато систем тепер вказують на локальний stub (часто 127.0.0.53), а демон виконує роботу з upstream.
APT має свою мережеву особистість. Воно не поводиться точно так само, як curl або wget у питаннях обробки проксі, пріоритету IPv6 або звітності про помилки. Тестування за допомогою apt важливе.
Часткова реалізація IPv6 гірша за відсутність IPv6. Мережа, яка рекламує IPv6, але не маршрутизує його надійно, створює періодичні та важкодовідні проблеми з резолюцією й підключенням.
Happy Eyeballs існує тому, що IPv6 ламає людей. Сучасні клієнти пробують IPv6 і IPv4 паралельно, щоб зменшити сприйману затримку. Але не всі інструменти це реалізують однаково, і деякі все ще зависають.
Split-horizon DNS поширений в корпоративних мережах. Внутрішній DNS повертає інші відповіді, ніж публічний. Вузли Proxmox часто знаходяться в «напіввнутрішніх» сегментах, де неправильний резолвер дає неправильні відповіді.
glibc резолвер консервативний. Він може пробувати сервери по черзі, застосовувати таймаути і повторні спроби. Один мертвий nameserver першим у списку може додати великі затримки, що виглядають як «DNS не працює».
Кластери Proxmox залежать від резолюції більше, ніж ви думаєте. Можна працювати по IP, але багато операційних скриптів, метрик, інтеграцій бекапів і конфігів репозиторіїв припускають, що hostname працює стабільно.
PAC/WPAD автоконфіг проксі старий, але все ще викликає відмови. Клієнт, який підхопив налаштування проксі, яких не мав би підхоплювати, — класична пастка «вчора працювало, сьогодні не працює».

Практичні завдання: команди, очікуваний вихід і рішення (12+)

Це реальні операторські кроки. Кожен має: команду, що означає вихід, і яке рішення ви приймаєте далі. Виконуйте їх на вузлі Proxmox (pve), а не на ноутбуці — бо ваш ноут завжди бреше.

Завдання 1: Підтвердити, що помилка дійсно пов’язана з резолюцією імен

cr0x@server:~$ apt-get update
Hit:1 http://deb.debian.org/debian bookworm InRelease
Err:2 https://enterprise.proxmox.com/debian/pve bookworm InRelease
  Could not resolve 'enterprise.proxmox.com'
Reading package lists... Done
W: Failed to fetch https://enterprise.proxmox.com/debian/pve/dists/bookworm/InRelease  Could not resolve 'enterprise.proxmox.com'

Значення: APT стверджує, що резолюція DNS для конкретного хоста зазнала невдачі. Це все ще може бути неправильна конфігурація проксі або доступність IPv6, що викликає таймаути на шляху резолвера.

Рішення: Перейдіть до прямих тестів резолюції (getent, resolvectl, dig) перед тим, як щось редагувати.

Завдання 2: Перевірити, які резолвери система вважає своїми (шлях systemd-resolved)

cr0x@server:~$ resolvectl status
Global
         Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub
Current DNS Server: 10.10.0.53
       DNS Servers: 10.10.0.53 10.10.0.54
        DNS Domain: corp.example

Значення: Хост використовує systemd-resolved у режимі stub з переліченими upstream DNS-серверами. Добре: є джерело істини.

Рішення: Якщо DNS-сервери не відповідають очікуваним — виправте конфіг мережі (інтерфейси) або конфіг systemd-resolved; не жорстко правте /etc/resolv.conf, якщо ви не навмисно обходите resolved.

Завдання 3: Якщо resolvectl недоступний або виглядає порожнім, подивіться /etc/resolv.conf

cr0x@server:~$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 39 Nov 21 10:12 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

Значення: Це символічне посилання на stub-файл systemd-resolved. Редагувати його прямо — марна дія; його перезапишуть.

Рішення: Користуйтесь resolvectl, конфігом systemd-resolved або змініть DNS у налаштуванні інтерфейсу замість ручних правок.

Завдання 4: Тест резолюції через libc (це те, що використовують більшість додатків)

cr0x@server:~$ getent ahosts enterprise.proxmox.com
51.91.38.34    STREAM enterprise.proxmox.com
51.91.38.34    DGRAM
51.91.38.34    RAW

Значення: libc може розв’язати hostname. Якщо APT все ще падає, підозрюйте проксі, TLS-інтерцепцію або переривчасті таймаути DNS, а не повну відмову DNS.

Рішення: Якщо getent успішний — переходьте до тестів підключення. Якщо ні — зосередьтесь на резолвері та доступності DNS-сервера.

Завдання 5: Тест «сирого» DNS до конкретного nameserver (обхід локальної логіки резолвера)

cr0x@server:~$ dig @10.10.0.53 enterprise.proxmox.com +time=2 +tries=1

; <<>> DiG 9.18.24-1 <<>> @10.10.0.53 enterprise.proxmox.com +time=2 +tries=1
; (1 server found)
;; global options: +cmd
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19041
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
enterprise.proxmox.com. 300 IN A 51.91.38.34

;; Query time: 21 msec
;; SERVER: 10.10.0.53#53(10.10.0.53) (UDP)
;; WHEN: Tue Dec 26 10:12:11 UTC 2025
;; MSG SIZE  rcvd: 64

Значення: DNS-сервер доступний і відповідає. Якщо інші імена не працюють — це не «DNS впав», а «DNS вибірково ламався». Інша проблема.

Рішення: Якщо запит таймаутиться — протестуйте маршрути до DNS-сервера та перевірте правила файрволу між вузлом і резолвером.

Завдання 6: Переконатися, що ви можете дістатися до DNS-сервера взагалі (маршрутизація + ACL)

cr0x@server:~$ ping -c 2 10.10.0.53
PING 10.10.0.53 (10.10.0.53) 56(84) bytes of data.
64 bytes from 10.10.0.53: icmp_seq=1 ttl=63 time=0.612 ms
64 bytes from 10.10.0.53: icmp_seq=2 ttl=63 time=0.590 ms

--- 10.10.0.53 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 0.590/0.601/0.612/0.011 ms

Значення: Принаймні ICMP працює. Це не доказ, що UDP/53 працює, але знищує теорію «немає маршруту».

Рішення: Якщо ping не проходить — перевірте дефолтний маршрут, тегування VLAN, конфігурацію bridge і політики файрволу.

Завдання 7: Підтвердити дефолтні маршрути (IPv4 і IPv6), щоб виключити «DNS через нікуди»

cr0x@server:~$ ip route
default via 10.10.0.1 dev vmbr0 proto kernel
10.10.0.0/24 dev vmbr0 proto kernel scope link src 10.10.0.20

cr0x@server:~$ ip -6 route
default via fe80::1 dev vmbr0 proto ra metric 1024 expires 1532sec
2001:db8:10:10::/64 dev vmbr0 proto kernel metric 256

Значення: У вас є дефолтні маршрути для обох стеків. Якщо дефолтний маршрут IPv6 присутній, але upstream зламаний, деякі клієнти будуть пробувати IPv6 першими й зависати.

Рішення: Якщо IPv6 виглядає підозрілим (маршрут є, але upstream не працює), протестуйте IPv6-доступність явно і вирішіть, чи вимкнути IPv6 тимчасово, чи виправити RA/маршрут.

Завдання 8: Тест підключення без DNS (підтвердити egress)

cr0x@server:~$ curl -I --connect-timeout 3 https://1.1.1.1
HTTP/1.1 400 Bad Request
Server: cloudflare
Date: Tue, 26 Dec 2025 10:13:01 GMT
Content-Type: text/html
Content-Length: 155
Connection: close

Значення: Ви можете дістатися до інтернету і встановити TLS до відомого IP. 400 — це нормально; шлях мережі працює.

Рішення: Якщо це не працює — зупиніться: у вас проблема з egress/маршрутом/файрволом, а не з DNS.

Завдання 9: Тест DNS + TCP до хоста репозиторію (перевірка «end-to-end»)

cr0x@server:~$ curl -I --connect-timeout 5 https://enterprise.proxmox.com/debian/pve/dists/bookworm/InRelease
HTTP/2 200
date: Tue, 26 Dec 2025 10:13:33 GMT
content-type: application/octet-stream
content-length: 1880

Значення: DNS і HTTPS працюють наскрізь. Якщо APT все ще падає, ймовірно, проблема в конфігурації проксі APT, відмінностях у використанні IPv6 або перехідних таймаутах резолвера.

Рішення: Якщо curl працює, але APT ні — порівняйте налаштування проксі і спробуйте примусово IPv4 для APT як тест.

Завдання 10: Перевірити конфігурацію проксі, що впливає на APT (поширено в корпоративних мережах)

cr0x@server:~$ grep -R "Acquire::http::Proxy" -n /etc/apt/apt.conf /etc/apt/apt.conf.d 2>/dev/null
/etc/apt/apt.conf.d/80proxy:1:Acquire::http::Proxy "http://proxy.corp.example:3128";
/etc/apt/apt.conf.d/80proxy:2:Acquire::https::Proxy "http://proxy.corp.example:3128/";

Значення: APT примушено йти через проксі, навіть якщо ваша shell-сесія — ні. Якщо той проксі впав або поводиться неправильно, APT може показувати оманливі помилки.

Рішення: Перевірте доступність проксі, автентифікацію та поведінку DNS. Якщо вузол не має використовувати проксі — видаліть цю конфігурацію свідомо (не просто закоментуйте і забудьте).

Завдання 11: Перевірити змінні оточення проксі в shell (вони можуть саботувати curl/wget теж)

cr0x@server:~$ env | grep -i proxy
http_proxy=http://proxy.corp.example:3128
https_proxy=http://proxy.corp.example:3128
no_proxy=localhost,127.0.0.1,10.0.0.0/8

Значення: Shell у вас прописаний під проксі. Деякі інструменти поважають ці змінні, деякі — ні. Змішана поведінка — джерело суперечливих тестів.

Рішення: Для чистих тестів запускайте команди з проксі увімкненим/вимкненим явно.

Завдання 12: Доведіть доступність проксі і чи резолвить він DNS за вас

cr0x@server:~$ curl -I --proxy http://proxy.corp.example:3128 --connect-timeout 5 https://enterprise.proxmox.com/
HTTP/1.1 200 Connection established

HTTP/2 200
date: Tue, 26 Dec 2025 10:14:11 GMT
content-type: text/html; charset=utf-8

Значення: Проксі доступний і може встановити тунель для HTTPS. Якщо проксі повертає сам помилки «could not resolve host», то DNS проксі поламаний, а не ваш вузол.

Рішення: Якщо проксі працює, а пряма дорога ні — мережа вимагає виходу через проксі. Якщо пряма дорога працює, а проксі ні — позбавте вузли залежності від проксі, якщо політика дозволяє.

Завдання 13: Примусити IPv4 в одиничному тесті, щоб ізолювати проблеми переваги IPv6

cr0x@server:~$ curl -4 -I --connect-timeout 5 https://enterprise.proxmox.com/
HTTP/2 200
date: Tue, 26 Dec 2025 10:14:40 GMT
content-type: text/html; charset=utf-8

Значення: Шлях IPv4 працює. Якщо звичайний curl зависає або падає, ймовірно IPv6 поламаний або фільтрується.

Рішення: Виправте маршрутизацію IPv6 або вимкніть IPv6 на вузлі/мережі до повної підтримки.

Завдання 14: Перевірити конфігурацію NSS (рідко, але катастрофічно при помилці)

cr0x@server:~$ grep -E "^(hosts:)" /etc/nsswitch.conf
hosts:          files dns

Значення: Резолюція hostname використовує /etc/hosts потім DNS. Якщо цей рядок дивний (відсутній dns або включає поламані модулі), отримаєте безглузді відмови.

Рішення: Тримайте files dns, якщо немає дуже вагомої причини діяти інакше.

Завдання 15: Перевірити /etc/hosts на самонанесені поранення

cr0x@server:~$ cat /etc/hosts
127.0.0.1 localhost
10.10.0.20 pve01.corp.example pve01

Значення: Це адекватно: localhost мапиться на 127.0.0.1; IP управління вузла мапиться на його hostname. Якщо ви мапите випадкові зовнішні імена тут — ви заслужили свою відмову.

Рішення: Фіксуйте лише те, що потрібно (зазвичай власне ім’я вузла). Використовуйте DNS для всього іншого.

Завдання 16: Захопити DNS-пакети (коли потрібен доказ, а не думки)

cr0x@server:~$ tcpdump -ni vmbr0 port 53 -c 5
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on vmbr0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:15:11.123456 IP 10.10.0.20.41788 > 10.10.0.53.53: 1234+ A? enterprise.proxmox.com. (39)
10:15:11.144321 IP 10.10.0.53.53 > 10.10.0.20.41788: 1234 1/0/1 A 51.91.38.34 (55)
10:15:11.145001 IP 10.10.0.20.35321 > 10.10.0.53.53: 5678+ AAAA? enterprise.proxmox.com. (39)
10:15:11.165210 IP 10.10.0.53.53 > 10.10.0.20.35321: 5678 0/1/1 (94)
5 packets captured

Значення: Ви бачите запити й відповіді. Тут: A-запис повертається, AAAA — ні (можливо NODATA). Це само по собі не помилка.

Рішення: Якщо ви бачите запити, що виходять, але немає відповідей — це проблема на шляху/ACL. Якщо ви бачите відповіді, але додатки все ще падають — дивіться вибір резолвера, кешування або поведінку проксі.

Завдання 17: Перевірити стан systemd-resolved і логи

cr0x@server:~$ systemctl status systemd-resolved --no-pager
● systemd-resolved.service - Network Name Resolution
     Loaded: loaded (/lib/systemd/system/systemd-resolved.service; enabled; preset: enabled)
     Active: active (running) since Tue 2025-12-26 09:55:02 UTC; 20min ago
       Docs: man:systemd-resolved.service(8)
   Main PID: 612 (systemd-resolve)
     Status: "Processing requests..."
      Tasks: 1 (limit: 38351)
     Memory: 7.2M
        CPU: 1.104s
     CGroup: /system.slice/systemd-resolved.service
             └─612 /lib/systemd/systemd-resolved

cr0x@server:~$ journalctl -u systemd-resolved -n 20 --no-pager
Dec 26 10:02:11 server systemd-resolved[612]: Using DNS server 10.10.0.53 for interface vmbr0.
Dec 26 10:07:44 server systemd-resolved[612]: Switching to DNS server 10.10.0.54 for interface vmbr0.
Dec 26 10:08:10 server systemd-resolved[612]: Using degraded feature set UDP instead of TCP for DNS server 10.10.0.54.

Значення: Resolved перемикається між серверами або деградує транспорт. Це сильна підказка, що ваші DNS-сервери хиткі або заблоковані для TCP/53/EDNS0 шляхів.

Рішення: Ескалюйте до команди, що відповідає за DNS-інфраструктуру, або скоригуйте резолвери, які використовує вузол (обирати стабільні локальні резолвери).

Завдання 18: Перевірити конфіг репозиторію Proxmox (бо «could not resolve host» іноді значить «неправильний хост»)

cr0x@server:~$ grep -R "proxmox" -n /etc/apt/sources.list /etc/apt/sources.list.d 2>/dev/null
/etc/apt/sources.list.d/pve-enterprise.list:1:deb https://enterprise.proxmox.com/debian/pve bookworm pve-enterprise

Значення: Хост репозиторію — саме те, що APT намагається розв’язати. Якщо ви скопіювали конфіг з вікі або старого образу, ви могли вказати hostname, який заблокований, застарів або доступний лише через проксі.

Рішення: Підтвердіть, що ви використовуєте правильний репозиторій згідно з вашим статусом підписки і політикою мережі. Не «фіксуйте DNS», щоб дістатися до репо, яке вам не дозволено використовувати.

DNS-стек у Proxmox: resolv.conf, systemd-resolved і звичні пастки

Більшість розгортань Proxmox — це по суті Debian з певними уподобаннями. Debian дає вам вибір для резолюції імен: класичний resolv.conf або systemd-resolved як локальний stub-резолвер. Вузли Proxmox часто налаштовуються через /etc/network/interfaces (ifupdown2) і іноді наслідують DNS від DHCP, іноді через статичну конфігурацію.

Знайте, яким шляхом резолвера ви користуєтесь

Найшвидший показник: що в /etc/resolv.conf?

Якщо він вказує на 127.0.0.53 (stub) — ви на systemd-resolved і upstream DNS контролюється там.
Якщо він містить nameserver 10.x.x.x прямо — ймовірно, ви на класичному resolv.conf менеджменті (або resolved у «foreign» режимі).
Якщо він перезаписується при кожному перезавантаженні — у вас, ймовірно, DHCP-клієнт, network manager або ifupdown хуки керують ним.

Оператори обпікаються, бо «виправляють» DNS правкою resolv.conf, це працює 20 хвилин, а потім мережевий стек перезаписує його. Наступне вікно оновлень стає фестивалем дежавю.

Віддавайте перевагу стабільним джерелам резолверів для вузлів

В корпоративному середовищі найкращі DNS-сервери для Proxmox вузлів зазвичай:

Локальні рекурсивні резолвери, призначені для інфраструктури (зазвичай внутрішні), з моніторингом і резервуванням.
Резолвери доступні на VLAN управління з явними правилами файрволу.

Найгірші DNS-сервери для вузлів Proxmox зазвичай:

Випадкові споживчі резолвери, доступні «іноді» через NAT-шляхи.
DNS в офісах-філіях, які зникають під час подій WAN.
Усе, що залежить від captive portal, перевірки стану кінцевої точки або «інтерактивної» веб-авторизації.

Поводження з таймаутами: один мертвий nameserver може зіпсувати вам день

Резолвер libc зазвичай пробує сервери по черзі, з таймаутами і повторними спробами. Якщо ваш перший nameserver мертвий, а другий здоровий — резолюція все одно буде повільною і може виглядати як відмова під навантаженням.

Якщо ви бачите довгі паузи під час apt update перед тим, як воно падає, підозрюйте таймаути замість чистого NXDOMAIN. Це маршрутизація, файрвол або мертвий резолвер, а не друкарська помилка в імені.

Коротка цитата для дисципліни

Надія — не стратегія. — часто приписують в опер-культурі (парафразована ідея)

Режими відмов IPv6, які маскуються під DNS

IPv6 не є лиходієм. Лиходій — напів-IPv6: коли вузол отримує IPv6-адресу і дефолт-роут (через RA), але upstream маршрутизація, файрвол або проксі фактично не підтримують IPv6 для вихідного трафіку.

Ось як це стає проблемою «could not resolve host»:

Ваш резолвер повертає і A, і AAAA записи.
Клієнт віддає перевагу AAAA (IPv6) або пробує його першим.
Спроба підключення зависає або падає.
Додаток повідомляє загальну помилку. Деякі інструменти звинувачують DNS, бо резолюція імен брала участь.

Патерни, що кричать «IPv6 вас обманює»

getent ahosts повертає IPv6 і IPv4 записи, але працює лише IPv4-з’єднання.
curl -4 працює; звичайний curl повільний або падає.
У вас є дефолтний маршрут IPv6, але немає стабільної upstream-підтримки IPv6.

Що з цим робити

У ідеальному світі ви виправляєте IPv6 правильно: коректні RA, маршрути, файрволи, DNS. У реальному світі вам також потрібен безпечний операційний обхід. Два прагматичні підходи:

Примусово IPv4 для APT під час інциденту (короткочасний обхід).
Вимкнути IPv6 на інтерфейсі управління, якщо ваша організація ще не підтримує його повністю (середньострокове очищення).

Будьте дисципліновані: якщо вимикаєте IPv6, задокументуйте це і відстежуйте роботу з повторного увімкнення, коли мережа буде готова. «Тимчасово» — так ви закладаєте технічний борг на роки.

Жарт #2: IPv6 — чудово, поки хтось не розгорне його «як концепт», а не як мережу.

Корпоративний проксі та режими відмов «прозорого» проксі

Вузли Proxmox — це сервери. Але вони часто живуть у мережах, створених для кінцевих пристроїв. Так виникають проксі. Іноді явні. Іноді «прозорі». Іноді вирішено через PAC-файл, який ніколи не мав використовувати сервер, але сюрприз: хтось вніс змінні оточення в /etc/environment і тепер APT веде переговори зі squid, що думає, ніби він HR-браузер.

Режими відмов проксі, що виглядають як DNS

Проксі впав: клієнт не може підключитися, помилка піднімається як «could not resolve host» залежно від інструменту і конфігурації.
Проксі вимагає автентифікацію: APT може падати рано. curl покаже 407. Деякі інструменти повідомляють загальні помилки резолюції після повторів.
Проксі резолвить DNS за вас: ваш вузол ніколи не резолвить зовнішні імена; проксі робить це. Якщо DNS проксі ламається — усі вузли одночасно «мають проблеми з DNS».
Проксі не резолвить DNS: він очікує, що клієнт розв’яже і потім CONNECT по IP або по імені. Якщо DNS клієнта неправильний — проксі ніяк не допоможе.
TLS-інтерцепція: менше про резолюцію, більше про «APT не може завантажити», але діагностика часто починається з першого рядка помилки.

Правила обробки проксі, які я застосовую на вузлах Proxmox

Будьте явними. Якщо вузол має використовувати проксі — конфігуруйте це в файлах APT, а не в випадкових shell-профілях.
Обмежте область. Використовуйте no_proxy для підмереж кластера, storage і management, щоб внутрішній трафік не йшов через проксі.
Тестуйте обидва шляхи. Майте стандартний «прямий» тест і стандартний «через проксі» тест, щоб ви могли швидко ізолювати домен відмови.

Поширені помилки: симптом → корінь проблеми → виправлення

Це секція, де ви впізнаєте свою останню відмову.

1) Симптом: `apt update` каже «could not resolve host», але `dig` працює

Корінь проблеми: APT використовує проксі (конфіг APT), і проксі не може розв’язати або підключитись. Ваші прямі DNS-тести його обходили.
Виправлення: Перевірте /etc/apt/apt.conf.d на директиви проксі Acquire::; протестуйте проксі з curl через --proxy. Виправте проксі або видаліть проксі-конфіг.

2) Симптом: DNS працює для деяких імен, падає для інших

Корінь проблеми: split-horizon DNS, умовна переадресація або резолвер, що блокує певні домени/категорії.
Виправлення: Запитайте те саме ім’я у кількох резолверах (dig @server), порівняйте відповіді, оберіть відповідний резолвер для ролі вузла.

3) Симптом: Усе повільно; іноді працює через 30–60 секунд

Корінь проблеми: перший nameserver мертвий/фільтрований, другий — нормальний; таймаути резолвера витрачають час перед failover.
Виправлення: Видаліть або знизьте пріоритет мертвих резолверів; переконайтеся, що файрвол дозволяє UDP/53 і TCP/53 до ваших резолверів.

4) Симптом: `curl -4` працює; plain `curl` зависає або падає; APT нестабільний

Корінь проблеми: поламаний маршрут IPv6 або фільтрація upstream IPv6. Клієнт пробує IPv6 першим.
Виправлення: Виправте IPv6 належним чином (маршрутизація/RA/файрвол) або вимкніть IPv6 на інтерфейсі управління. Як обхід, примусіть IPv4 для APT.

5) Симптом: Редагування `/etc/resolv.conf` «вирішує» проблему до перезавантаження

Корінь проблеми: resolv.conf керується (systemd-resolved, DHCP-клієнт, ifupdown хуки). Ваша ручна правка буде перезаписана.
Виправлення: Налаштуйте DNS у правильному шарі: конфіг інтерфейсу, налаштування systemd-resolved або опції DHCP. Не воюйте з автоматизацією.

6) Симптом: Вузол резолвить внутрішні імена добре, зовнішні — ні

Корінь проблеми: внутрішній резолвер не має рекурсії до інтернету або файрвол блокує вихідний DNS з цього сегменту, очікуючи проксі.
Виправлення: Використовуйте резолвери, що надають рекурсію для вузлів, які потребують оновлень, або забезпечте контрольований шлях egress (проксі або DNS-forwarder) явно.

7) Симптом: Лише вузли Proxmox падають, VM — в порядку

Корінь проблеми: хост-мережа відрізняється від мережі VM: ACL управлінського VLAN, помилкове тегування vmbr0, правила файрволу хоста або неправильний gateway на хості.
Виправлення: Порівняйте маршрути та DNS хоста і VM, перевірте bridge/VLAN конфіг, підтвердіть дефолтний маршрут хоста і доступність DNS-серверів на vmbr інтерфейсах.

8) Симптом: Помилка з’являється після змін для «затвердіння»

Корінь проблеми: правила файрволу блокують вихідний UDP/53 або TCP/53, або блокують IPv6 ICMP (що ламає PMTUD і neighbor discovery, викликаючи дивності).
Виправлення: Дозвольте потрібний DNS-трафік до резолверів; дозвольте необхідні типи ICMP/ICMPv6; перевірте з tcpdump і явними тестами.

Контрольні списки / покроковий план

Контрольний список A: 10-хвилинний план «запустити оновлення»

Доведіть egress по IP: curl -I https://1.1.1.1. Якщо зламано — виправляйте маршрути/файрвол перед DNS.
Доведіть резолюцію через libc: getent ahosts enterprise.proxmox.com. Якщо зламано — фокус на конфіг резолвера.
Доведіть доступність DNS-сервера: dig @<dns> enterprise.proxmox.com. Якщо таймаути — виправляйте ACL/маршрути до DNS.
Перевірте джерело істини резолвера: resolvectl status і ls -l /etc/resolv.conf. Не правте неправильний шар.
Перевірте налаштування проксі: grep -R Acquire:: /etc/apt/apt.conf.d і env | grep -i proxy.
Спробуйте примусове IPv4 як діагностику: curl -4 -I https://enterprise.proxmox.com/.
Перезапустіть apt-get update: підтвердіть, що виправлення реальне, а не плацебо.

Контрольний список B: План «зробити фікс постійним» (після інциденту)

Виберіть модель власності DNS: systemd-resolved + DNS інтерфейсу або класичний resolv.conf. Документуйте це.
Зробіть DNS-сервери явними для статичних мереж управління. Залежність від DHCP у дата-центрі прийнятна, поки вона працює — поки ні.
Перевірте позицію щодо IPv6: або підтримуйте його наскрізь, або вимкніть навмисно на цьому сегменті. Ніяких напівзаходів.
Стандартизувати конфіг проксі: файл проксі APT керується конфігураційним менеджментом; тримайте shell-профілі чистими для операторів.
Додайте легкий health-check для вузла: періодична перевірка DNS + доступності репо з чітким алертингом по шару, в якому сталася відмова.

Контрольний список C: Збір доказів для ескалації (коли це не ваша вина)

Захопіть конфіг резолвера: resolvectl status, /etc/resolv.conf, /etc/nsswitch.conf.
Захопіть докази DNS-запитів: виводи dig @dns host і уривки tcpdump.
Захопіть таблиці маршрутів: ip route, ip -6 route.
Захопіть конфіг проксі: файл проксі APT, змінні оточення, і тест curl --proxy.
Запишіть часові мітки. DNS-команди люблять часові мітки, бо логи існують. Vibes — ні.

Три міні-історії з корпоративного середовища з передової

Міні-історія 1: Інцидент через неправильне припущення

Команда успадкувала маленький кластер Proxmox, який мав змішання мереж управління і гостьових VLAN. Все виглядало чисто: vmbr0 для управління, vmbr1 для гостьових мереж. Оновлення були «інколи нестабільні», що всі інтерпретували як «інтернет такий інтернет». Ніхто не хотів брати відповідальність.

Під час планового оновлення apt update почав падати з «could not resolve host» для кількох репозиторіїв. Інженер зробив звичну річ: замінив /etc/resolv.conf на публічні резолвери і пішов далі. Працювало. Декілька годин. Потім автоматика обслуговування перезавантажила вузли по черзі і проблема повернулася на кожному перезавантаженні. Почалася паніка.

Неправильне припущення було простим: вони думали, що resolv.conf — авторитет. Насправді — ні. Система користувалась systemd-resolved, а DHCP на vmbr0 підсовував DNS-сервери з relay філії, які іноді втрачали upstream. «Фікс» перезаписувався саме тоді, коли це було критично: під час перезавантажень.

Коли вони відобразили ланцюжок резолверів, справжній фікс був нудний: прив’язати стабільні внутрішні рекурсивні резолвери для інтерфейсу управління і припинити споживати DNS від DHCP на цьому VLAN. Потім задокументували модель власності резолверів у стандарті збірки. Наступне оновлення пройшло тихо — найвища похвала для SRE.

Міні-історія 2: Оптимізація, яка відкотилася назад

Проект безпеки вирішив «оптимізувати DNS», змусивши всі серверні запити йти через центральний фільтруючий резолвер для стандартизації логування і блокування категорій. Технічно це зменшило ризики і спростило аудит.

Але вузли Proxmox опинилися за резолвером, який лімітував спалахи запитів і мав агресивні таймаути під навантаженням. PVE вузли дуже «балакучі» під час вікон обслуговування: вони звертаються до Debian mirror-ів, Proxmox репозиторіїв, іноді Ceph, плюс інтеграції моніторингу і бекапів. Новий резолвер нормально працював у звичайні години, але летів під час хвиль патчів.

Перший симптом — «could not resolve host» в APT. Другий симптом — повільні UI у pveproxy, коли він намагався резолвити зовнішні кінцеві точки для інтеграцій. Інженери «вирішили» це, додавши ще один nameserver (публічний) як fallback. Це створило порушення політики і, важливіше, недетермінізм: іноді внутрішній DNS, іноді зовнішній.

Кінцевий фікс був не героїчним. Вони створили виділений шар резолверів для інфраструктури з більшою пропускною здатністю і налаштували таймаути/повтори, і прив’язали мережі Proxmox до нього. Фільтруючий резолвер залишився для кінцевих пристроїв. Урок був корпоративно болючий: оптимізація має свою ціну.

Міні-історія 3: Нудна, але правильна практика, що врятувала ситуацію

Інша компанія мала майже старомодну звичку: кожне збирання вузла Proxmox включало невеликий «контракт перевірки доступності». Він запускався після провізії і щодня надалі. Перевіряв три речі: розв’язати відоме ім’я через налаштований резолвер, з’єднатися з відомим IP напряму, і завантажити маленький файл з репо-оригіну для цього середовища. Результати йшли в моніторинг з явними мітками: DNS, маршрутизація або repo/proxy.

Одного вівторка рано декілька команд почали скаржитись на недоступність зовнішніх сервісів. Кластер Proxmox виглядав здоровим. VM працювали. Ніхто не хотів чіпати гіпервайзери.

Але тоді спрацював алерт: «DNS-відмова на шляху резолвера management VLAN». Не «apt зламався». Не «Proxmox не може оновитись». Чистий DNS-фейл по всіх вузлах з часовими мітками і останньо відомим станом. Ops команда передала мережникам захоплення пакетів з неприйнятими UDP/53 запитами і DNS сервіс відновили швидко.

Ця нудна практика не запобігла інциденту. Вона запобігла другому інциденту: коли п’ять інженерів витрачають півдня на випадкові правки конфігів продакшн-гіпервайзерів, бо не знають, який шар падає.

FAQ

1) Чому Proxmox показує «could not resolve host» під час `apt update`?

Тому що APT не може перетворити hostname репозиторію в IP через шлях резолвера вузла. Це може бути реальна відмова DNS, недоступні DNS-сервери, пріоритет IPv6, або плутанина через проксі.

2) Якщо `ping 8.8.8.8` працює, чи це доводить, що проблема в DNS?

Ні. Це доводить базовий IPv4 egress і маршрутизацію для ICMP до цієї адреси. DNS може бути все ще поламаним, заблокованим або неправильно налаштованим. Також ICMP не доводить, що TCP/443 працює.

3) Якщо `dig` працює, але APT падає, що підозрювати перш за все?

Конфігурацію проксі і відмінності в пріоритеті IPv6. Перевірте /etc/apt/apt.conf.d на директиви Acquire::, потім протестуйте curl -4 проти дефолтного.

4) Чи просто відредагувати `/etc/resolv.conf`?

Тільки якщо ви підтвердили, що його не керує systemd-resolved або DHCP-хук. Якщо це символічне посилання на systemd-resolved — редагування тимчасове. Виправляйте DNS у правильному шарі власності.

5) Як IPv6 може зламати резолюцію DNS?

Сам IPv6 не ламає DNS. Але якщо мережа рекламує IPv6 і клієнти віддають йому перевагу, спроби підключення можуть падати або зависати, і інструменти можуть повідомляти заплутані помилки, що виглядають як проблеми резолюції.

6) Який найшвидший спосіб довести, що це проблема IPv6?

Запустіть той самий тест з примусовим IPv4: curl -4 -I https://host. Якщо примусове IPv4 працює надійно, а дефолт — ні, підозрюйте маршрутизацію або фільтрацію IPv6.

7) Чи може кластер Proxmox (corosync) постраждати від проблем DNS?

Сам corosync зазвичай працює по IP, але операційні скрипти, доступ до репо, метрики, бекапи і деякі інтеграції залежать від стабільної резолюції імен. DNS-проблеми не завжди зламають кластер, але вони зламають обслуговування — саме тоді, коли сюрпризи небажані.

8) Я за корпоративним проксі. Чи повинні вузли Proxmox його використовувати?

Якщо політика вимагає — так, явним і узгодженим способом. Налаштуйте проксі для APT у керованому файлі, тримайте no_proxy коректним для мереж кластера і storage, і тестуйте доступність проксі як частину health-check’ів вузла.

9) Чому це трапляється лише після перезавантаження?

Бо DNS-налаштування часто інжектуються під час завантаження через DHCP або керовані сервіси. Ваша ручна правка перезаписується. Перевірте через ls -l /etc/resolv.conf і resolvectl status.

10) Коли ескалювати до DNS/мережевої команди?

Коли ви можете показати: запити виходять з вузла, DNS-сервер недоступний або не відповідає, або логи resolved показують перемикання/деградований стан. Приходьте з packet capture і часовими мітками, а не з інтерпретаціями.

Висновок: практичні наступні кроки

«Could not resolve host» на вузлі Proxmox рідко є містерією. Це питання робочого процесу. Якщо ви доведете домен відмови в порядку — egress по IP, libc резолюція, доступність DNS-сервера, пріоритет IPv6, потім поведінка проксі — ви перестанете трактувати DNS як фольклор.

Наступні кроки, які дійсно окупаються:

Стандартизувати власність резолверів (systemd-resolved або ні) і задокументувати це у збірці вузла.
Закріпіть стабільні DNS-сервери для мережі управління і забезпечте явний дозвіл UDP/53 і TCP/53.
Розв’яжіть питання IPv6 свідомо: або підтримка наскрізь, або вимкнення на сегменті. Напів-IPv6 — це борг з відсотками.
Зробіть використання проксі явним і тестованим. Конфіг APT проксі не має бути полюванням на скарби.
Додайте малий плановий connectivity-check, щоб виявляти дрейф DNS/proxy/маршрутів раніше, ніж настане ніч патчів.

Схожі статті

Виправлення помилок apt update на Proxmox: DNS, репозиторії та GPG-ключі (покроково)