Ubuntu 24.04: IPv6 ламає випадкові сайти — виправте двостек правильно (не просто відключайте IPv6)

Що зазвичай означає «випадкові збої» у двостеку

Коли користувачі кажуть «випадкові сайти не завантажуються», вони насправді описують ефект вибірки.
Деякі ресурси публікують записи AAAA (адреси IPv6), інші — ні. Деякі CDN направляють вас на IPv6‑край, який доступний, інші — на той, який недоступний.
Деякі сайти розміщені за мережами, де PMTUD має працювати коректно; інші — ні. Деякі кінцеві точки використовують QUIC поверх UDP; інші — TCP.

На хості з двостеком багато стеків клієнтів спробують IPv6 першими, якщо існує запис AAAA. Якщо маршрут IPv6 зламаний або DNS повертає неправильні IPv6‑відповіді,
ви отримаєте таймаути, довге завантаження сторінок або аргументи «на моєму телефоні працює, на ноутбуці ні». Зрештою Happy Eyeballs може повернутися на IPv4, але «зрештою»
— це не стратегія для користувацького досвіду.

Ваша мета — не «змінити IPv6 на нуль». Ваша мета — зробити IPv6 правильним, щоб двостек поводився як нудна комунальна послуга.
Нудність — це добре. Нудність платить рахунки.

Жарт №1: Відключати IPv6, бо він нестабільний, — це як виймати детектор диму, бо він пищить, коли сідає батарейка. Тихо, так. Розумно — ні.

Факти й контекст, що пояснюють, чому це відбувається

• Факт 1: IPv6 був стандартизований наприкінці 1990‑х, але розгортання в корпоративному сегменті відставало десятиліттями; «майже працює» — звичайне явище.
• Факт 2: Багато ОС за замовчуванням віддають перевагу IPv6, коли присутні і A, і AAAA, керуючись правилами вибору адрес RFC 6724.
• Факт 3: «Happy Eyeballs» (спочатку RFC 6555, пізніше оновлений) існує саме тому, що шляхи IPv6 були часто зламані.
• Факт 4: Router Advertisements (RA) можуть налаштувати IPv6 без DHCPv6; ця зручність також полегшує приховування помилкової конфігурації.
• Факт 5: DNS64/NAT64 можуть дозволити клієнтам лише з IPv6 звертатися до IPv4‑сервісів; коли це розгорнуто випадково або частково зламано, виникають сюрреалістичні помилки.
• Факт 6: Black‑hole із Path MTU раніше були помітніші в IPv4 через поведінку фрагментації; в IPv6 маршрутизатори не фрагментують за вас.
• Факт 7: Деякі VPN‑клієнти та «агенти безпеки» все ще неправильно обробляють IPv6, особливо роздільний тунелювання й маршрути DNS для AAAA.
• Факт 8: Хмарні провайдери й CDN часто мають різні IPv6 і IPv4‑края; ви не завжди потрапляєте «на той самий сервер, просто інша IP‑адреса».
• Факт 9: systemd-resolved змінив спосіб, яким багато Linux‑десктопів і серверів роблять резолюцію; він швидкий, коли налаштований правильно, і заплутаний, коли ні.

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

Перше: підтвердіть, чи збігаються збої з запитами AAAA (IPv6)

Якщо зламані сайти стабільно мають записи AAAA, а працюючі — ні, припиніть прикидатися, що це «випадково». Це пріоритет IPv6 + зламаний шлях IPv6.
Якщо існують і A, і AAAA, і по IPv4 працює, але по IPv6 зависає — ви дивитесь на проблеми маршрутизації, MTU, фаєрвола або транспорту DNS.

Друге: перевірте налаштування IPv6 на локальному хості й маршрут за замовчуванням

Найшвидший спосіб втратити післяобідній час — відлагоджувати поведінку додатків, не підтвердивши, що ядро має дійсну IPv6‑адресу,
маршрут за замовчуванням і працююче виявлення сусідів.

Третє: протестуйте базову досяжність IPv6 і поведінку DNS окремо

Проблеми DNS і проблеми маршрутизації пакетів можуть виглядати однаково в браузері. Розділіть їх рано:
(1) чи ви швидко резолвите AAAA, і (2) чи можете ви швидко підключитися до отриманої IPv6‑адреси?

Четверте: якщо «підключається, але зависає», підозрюйте MTU/PMTUD або станний фаєрвол

TCP‑хендшейк успішний, TLS застиг, HTTP зависає, QUIC не працює: саме тут живуть MTU‑чорні діри і таймаути стану фаєрвола.
Діагностуйте цільовими ping’ами і дампами, а не інтуїцією.

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

Ось завдання, які я реально виконую на хості з Ubuntu 24.04, коли двостек здається проклятим. Кожне завдання включає, що означає вивід і яке рішення прийняти далі.
Виконуйте їх у порядку; зазвичай ви знайдете винуватця на завданні 7–10.

Завдання 1: підтвердити, що хост має глобальну IPv6‑адресу й правильний інтерфейс

cr0x@server:~$ ip -6 addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: enp0s31f6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP
    inet6 fe80::a00:27ff:fe4e:66a1/64 scope link
       valid_lft forever preferred_lft forever
    inet6 2001:db8:120:34::25/64 scope global dynamic mngtmpaddr
       valid_lft 7100sec preferred_lft 3500sec

Значення: Потрібна адреса scope global на очікуваному інтерфейсі (не лише fe80::/64 link‑local).
Якщо ви бачите лише link‑local, IPv6 не дійде до інтернету без спеціальних тунелів.

Рішення: Немає глобальної IPv6? Стоп. Виправляйте RA/DHCPv6 у мережі або конфігурацію netplan перед відлагодженням браузерів.

Завдання 2: перевірити, що існує IPv6‑маршрут за замовчуванням і він вказує кудись осмислено

cr0x@server:~$ ip -6 route show
2001:db8:120:34::/64 dev enp0s31f6 proto kernel metric 256 pref medium
fe80::/64 dev enp0s31f6 proto kernel metric 256 pref medium
default via fe80::1 dev enp0s31f6 proto ra metric 1024 pref medium

Значення: Маршрут за замовчуванням через link‑local шлюз (наприклад fe80::1), вивчений через RA, — нормальний.
Ненормально мати відсутній default або кілька default, що флапають між інтерфейсами.

Рішення: Відсутній маршрут за замовчуванням? Зосередьтеся на Router Advertisements (або статичних маршрутах) перед DNS. Кілька default? Можливо, це VPN, Wi‑Fi + Ethernet або неправильно вказані метрики маршрутів.

Завдання 3: перевірити, що виявлення сусідів не провалюється (перевірка L2/L3)

cr0x@server:~$ ip -6 neigh show dev enp0s31f6
fe80::1 lladdr 00:11:22:33:44:55 router STALE

Значення: Якщо запис маршрутизатора так і не зʼявляється або сидить у стані FAILED, у вас немає базової IPv6‑сусідності.

Рішення: Якщо виявлення сусідів зламане, підозрюйте VLAN, ізоляцію Wi‑Fi, RA‑guard, безпеку на комутаторі або надмірний локальний фаєрвол.

Завдання 4: протестувати сиру IPv6‑досяжність на відомій адресі (обійти DNS)

cr0x@server:~$ ping -6 -c 3 2606:4700:4700::1111
PING 2606:4700:4700::1111(2606:4700:4700::1111) 56 data bytes
64 bytes from 2606:4700:4700::1111: icmp_seq=1 ttl=57 time=9.89 ms
64 bytes from 2606:4700:4700::1111: icmp_seq=2 ttl=57 time=10.12 ms
64 bytes from 2606:4700:4700::1111: icmp_seq=3 ttl=57 time=10.02 ms

--- 2606:4700:4700::1111 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms

Значення: Успішний ICMPv6 не гарантує, що TCP працюватиме, але невдача тут — велика червона ознака: IPv6 фундаментально зламаний.

Рішення: Якщо це не працює, але IPv4 ping працює, зосередьтеся на маршрутизації/фаєрволі/ISP/VPN, а не на налаштуваннях додатків.

Завдання 5: підтвердити, що DNS повертає AAAA і A, і наскільки швидко

cr0x@server:~$ resolvectl query example.com
example.com: 2606:2800:220:1:248:1893:25c8:1946
             93.184.216.34

-- Information acquired via protocol DNS in 42.0ms.
-- Data is authenticated: no

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

Рішення: Повільний DNS? Досліджуйте upstream‑сервери systemd‑resolved, поведінку EDNS або проблеми з перехопленням DNS у VPN.

Завдання 6: подивитися, які DNS‑сервери задіяні (важливо по‑лінку)

cr0x@server:~$ resolvectl status
Global
         Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub
Current DNS Server: 2001:4860:4860::8888
       DNS Servers: 2001:4860:4860::8888 8.8.8.8

Link 2 (enp0s31f6)
    Current Scopes: DNS
         Protocols: +DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 2001:4860:4860::8888
       DNS Servers: 2001:4860:4860::8888 8.8.8.8

Значення: systemd‑resolved може мати DNS на рівні інтерфейсу. VPN часто інжектує DNS на свій лінк, що може змінити або зламати AAAA‑відповіді.

Рішення: Якщо DNS‑сервери різні по лінкам, підтвердіть, що маршрут за замовчуванням і DNS‑лінк відповідають вашим намірам (особливо при роздільному тунелюванні VPN).

Завдання 7: примусити підключення по IPv6 і IPv4 окремо до того самого хоста

cr0x@server:~$ curl -6 -I --max-time 8 https://example.com
HTTP/2 200
cache-control: max-age=604800
content-type: text/html; charset=UTF-8
server: ECS (nyb/1D2A)

cr0x@server:~$ curl -4 -I --max-time 8 https://example.com
HTTP/2 200
cache-control: max-age=604800
content-type: text/html; charset=UTF-8
server: ECS (nyb/1D2A)

Значення: Якщо -4 працює, а -6 таймаутиться (або зависає посеред передачі), у вас реальна проблема з IPv6‑шляхом.

Рішення: Якщо тільки IPv6 не працює — переходьте до задач з MTU і фаєрволом. Якщо обидва не працюють — це ширша проблема з підключенням, проксі або TLS‑перехопленням.

Завдання 8: перевірити вибір маршруту для конкретного IPv6‑призначення

cr0x@server:~$ ip -6 route get 2606:4700:4700::1111
2606:4700:4700::1111 from :: via fe80::1 dev enp0s31f6 proto ra metric 1024 pref medium

Значення: Підтверджує, який інтерфейс/шлюз буде використаний. Якщо показано VPN‑інтерфейс або несподіваний NIC, ви знайшли джерело «випадковості».

Рішення: Неправильний egress‑інтерфейс? Виправте метрики маршрутів, конфігурацію netplan або політику маршрутизації VPN.

Завдання 9: протестувати симптоми MTU/PMTUD за допомогою «do not fragment»‑подібного запиту (стиль IPv6)

cr0x@server:~$ ping -6 -c 3 -s 1452 2606:4700:4700::1111
PING 2606:4700:4700::1111(2606:4700:4700::1111) 1452 data bytes
1452 bytes from 2606:4700:4700::1111: icmp_seq=1 ttl=57 time=10.88 ms
1452 bytes from 2606:4700:4700::1111: icmp_seq=2 ttl=57 time=10.95 ms
1452 bytes from 2606:4700:4700::1111: icmp_seq=3 ttl=57 time=11.01 ms

--- 2606:4700:4700::1111 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms

Значення: Це не ідеальна перевірка PMTUD, але якщо маленькі пінги проходять, а більші не працюють або зависають, підозрюйте MTU‑чорну діру.
VPN‑тунелі й PPPoE — повторювані підозрювані.

Рішення: Якщо великі пакети не проходять — обмежте MSS на краю, налаштуйте MTU інтерфейсу або виправте блокування ICMPv6 Packet Too Big.

Завдання 10: перевірити, що ICMPv6 не «забезпечено» до смерті локально

cr0x@server:~$ sudo nft list ruleset | sed -n '1,160p'
table inet filter {
  chain input {
    type filter hook input priority filter; policy drop;
    ct state established,related accept
    iif "lo" accept
    ip6 nexthdr icmpv6 icmpv6 type { echo-request, echo-reply, nd-neighbor-solicit, nd-neighbor-advert, nd-router-solicit, nd-router-advert, packet-too-big, time-exceeded, parameter-problem } accept
    tcp dport { 22 } accept
  }
  chain forward {
    type filter hook forward priority filter; policy drop;
  }
  chain output {
    type filter hook output priority filter; policy accept;
  }
}

Значення: В IPv6 ICMPv6 не є опційним. Якщо хтось заблокував «весь ICMP» із міркувань безпеки, ви можете зламати виявлення сусідів і PMTUD.

Рішення: Переконайтеся, що дозволені критичні типи ICMPv6. Якщо ви на сервері з policy drop, будьте явними.

Завдання 11: перевірити перемикачі ядра для відключення IPv6 (так, люди так роблять)

cr0x@server:~$ sysctl net.ipv6.conf.all.disable_ipv6 net.ipv6.conf.default.disable_ipv6
net.ipv6.conf.all.disable_ipv6 = 0
net.ipv6.conf.default.disable_ipv6 = 0

Значення: Якщо ці значення = 1, IPv6 відключено на рівні ядра. Іноді це робиться «тимчасово» і потім закріплюється.

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

Завдання 12: підтвердити, куди насправді вказує /etc/resolv.conf

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

Значення: Ubuntu зазвичай використовує systemd‑stub‑резольвер. Якщо ви очікували NetworkManager або статичний resolv.conf, ваша ментальна модель застаріла.

Рішення: Якщо це stub-resolv.conf, користуйтеся resolvectl як джерелом істини. Якщо це статичний файл — переконайтеся, що там вказані досяжні DNS‑сервери по обох стеках.

Завдання 13: переконатися, що у вас немає збоїв транспорту DNS по IPv6

cr0x@server:~$ resolvectl query -4 example.com
example.com: 93.184.216.34

-- Information acquired via protocol DNS in 16.8ms.

cr0x@server:~$ resolvectl query -6 example.com
example.com: 2606:2800:220:1:248:1893:25c8:1946

-- Information acquired via protocol DNS in 2105ms.

Значення: Той самий запит, але транспорт IPv6 до резольвера повільний. Це саме по собі може зробити «випадкові сайти» погано відчутними.

Рішення: Виправте досяжність IPv6 до вашого DNS‑резольвера або тимчасово віддавайте перевагу IPv4‑резолверам, поки ремонтуєте маршрути/MTU для IPv6 до IPv6‑резольвера.

Завдання 14: захопіть докази (короткий цільовий tcpdump)

cr0x@server:~$ sudo tcpdump -ni enp0s31f6 ip6 and host 2606:4700:4700::1111
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on enp0s31f6, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:14:01.233445 IP6 2001:db8:120:34::25 > 2606:4700:4700::1111: ICMP6, echo request, seq 1, length 64
12:14:01.243110 IP6 2606:4700:4700::1111 > 2001:db8:120:34::25: ICMP6, echo reply, seq 1, length 64

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

Рішення: Використайте це, щоб довести, де сидить збій, перед тим як міняти конфіги «щоб подивитися».

Головні кореневі причини: DNS, маршрутизація, MTU, RA/DHCPv6 і фаєрволи

1) Відповіді DNS нормальні; транспорт DNS — ні

Один із підлих варіантів: ваш резольвер доступний по IPv4 і IPv6, але шлях IPv6 до резольвера зламаний (MTU, асиметрична маршрутизація, фаєрвол).
systemd‑resolved може віддати перевагу IPv6‑адресі резольвера, затримати запити й потім повторити. Для додатка це виглядає як «деякі домени таймаутяться».

Виправлення — не видаляти AAAA (ви не можете) і не відключати IPv6 (не варто). Потрібно зробити IPv6‑шлях до DNS надійним або обмежити, які DNS‑сервери використовуються на яких інтерфейсах, щоб не віддавати перевагу зламаному транспорту.

2) Є маршрут за замовчуванням, але виграє не той

Двостек‑збої люблять мультихомінг: Ethernet + Wi‑Fi, LAN + VPN, мости Docker і «корисні» мережеві інструменти, що додають маршрути.
У вас може бути цілком робочий IPv4‑default, але зламаний IPv6‑default, і хост все одно обиратиме IPv6 для ресурсів з AAAA.

Виправляйте метрики маршрутів або видаліть джерело хибних RA. У підприємствах підозріло ставтеся до гостьового Wi‑Fi, який рекламує IPv6, але насправді не маршрутизує його.
Це трапляється частіше, ніж здається, бо хтось просто поставив галочку «увімкнути IPv6» на периферійних пристроях і ніколи не перевірив апстрім.

3) MTU‑чорні діри (класика «підключається, потім зависає»)

IPv6 вимагає, щоб PMTUD працював правильно; маршрутизатори не фрагментують для вас. Якщо десь блокуються повідомлення ICMPv6 Packet Too Big,
або тунель знижує MTU і ніхто про це не повідомив кінцеві точки, TCP може підключитися, а потім зависнути на більших TLS‑записах або HTTP‑відповідях.

VPN — типовий винуватець. Також фаєрволи з політикою deny‑за‑замовчуванням, які випадково відкидають невідомі типи ICMPv6.
Коли чуєте «завантажуються маленькі сторінки, але не великі» — не сперечайтеся. Тестуйте MTU.

4) RA і DHCPv6 не узгоджені з реальністю

IPv6‑конфіг може приходити з Router Advertisements (SLAAC), DHCPv6 або обох джерел.
Мережа може видати вам глобальну IPv6‑адресу, але не дати робочий маршрут за замовчуванням, або видати DNS‑сервери, які недосяжні.
В результаті ви «налаштовані», але не функціональні.

На клієнтах Ubuntu netplan + NetworkManager або systemd‑networkd можуть поводитися по‑різному щодо RA і DHCPv6.
Переконайтеся, який renderer активний і який компонент має приймати RA.

5) Фаєрволи: «блокувати ICMP» — це не план

В IPv4 іноді можна уникнути строгих правил ICMP. В IPv6 — ні.
Виявлення сусідів, виявлення маршрутизаторів і PMTUD залежать від ICMPv6.
Блокування його не робить вас безпечнішими; воно робить вас сліпими й періодично зламаними.

systemd-resolved в Ubuntu 24.04: чому довіряти, що перевіряти

Ubuntu 24.04 у типовій конфігурації використовує systemd‑resolved. Він робить кешування, DNS на рівні лінку, розділену (split) DNS і представляє локальний stub‑резольвер.
Це нормально. Але це також часте джерело плутанини, бо люди дивляться /etc/resolv.conf і думають, що дізналися щось важливе.
Часто вони дізналися лише те, що це символьне посилання.

Чому я довіряю

• resolvectl status — це поточна істина щодо того, які DNS‑сервери використовуються по інтерфейсу й глобально.
• resolvectl query — пристойний спосіб виміряти час відповіді DNS без додаткових інструментів.
• Кешування systemd‑resolved загалом стабільне й пришвидшує звичні запити.

Що я перевіряю

• Чи не інжектував VPN DNS‑сервери і чи не став він дефолтним маршрутом для IPv6 (часте випадкове явище).
• Чи досяжні DNS‑сервери через IPv6 без проблем MTU або фаєрвола.
• Чи не існують правила split‑DNS, які посилають деякі домени на внутрішні резольвери, що не повертають AAAA або таймаутяться.

Якщо підозрюєте, що systemd‑resolved загіпав, ви можете перезапустити його — після того, як зафіксували симптоми. Перезапуск до фіксації симптомів — спосіб втратити корені проблеми.

cr0x@server:~$ sudo systemctl restart systemd-resolved
cr0x@server:~$ resolvectl statistics
Transactions
  Current Transactions: 0
  Total Transactions: 1249
Cache
  Current Cache Size: 317
  Cache Hits: 802
  Cache Misses: 447
DNSSEC Verdicts
  Secure: 0
  Insecure: 1249
  Bogus: 0

Значення: Ви підтверджуєте, що демон здоровий і кешує. Це не доводить здоровʼя апстріма.

Рішення: Якщо перезапуски «виправляють», у вас все одно є коренева причина; ви просто додали ритуал. Поверніться до дослідження досяжності транспорту й DNS по лінках.

Підводні камені netplan, які тихо ламають IPv6

Netplan класний, коли ви тримаєте його декларативним і нудним. Менш класний, коли правите YAML під напругою о 2:00 ночі.
YAML — мова, яка карає надмірну самовпевненість.

Плутанина renderer: NetworkManager vs systemd‑networkd

На десктопах зазвичай NetworkManager. На серверах — systemd‑networkd. Їхня поведінка щодо RA, DHCPv6 і DNS може відрізнятися.
Під час відлагодження визначте renderer і не змішуйте припущення.

cr0x@server:~$ sudo netplan get
network:
  version: 2
  renderer: networkd
  ethernets:
    enp0s31f6:
      dhcp4: true
      dhcp6: true
      accept-ra: true

Значення: Цей хост приймає RA і використовує DHCPv6. Якщо випадково поставили accept-ra: false, ви можете втратити маршрут за замовчуванням.

Рішення: Якщо IPv6 частково налаштований, перевірте, що dhcp6 і accept-ra відповідають вашому мережевому дизайну.

Поганий статичний IPv6 + RA: проблема «двох істин»

Статична IPv6‑адреса з неправильним префіксом у поєднанні з RA може дати дивну поведінку.
Хост думає, що має глобальну адресу; віддалені відповіді йдуть в інше місце або повертаються по різному шляху.
IPv4 при цьому все ще працює, тому всі звинувачують «додаток».

cr0x@server:~$ ip -6 route show table main | head
default via fe80::1 dev enp0s31f6 proto ra metric 1024 pref medium
2001:db8:120:34::/64 dev enp0s31f6 proto kernel metric 256 pref medium
2001:db8:120:99::/64 dev enp0s31f6 proto kernel metric 256 pref medium

Значення: Дві on‑link глобальні префікси на одному інтерфейсі можуть бути валідними, але часто це ознака колізії старої статичної конфігурації з нинішнім RA.

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

Поширені помилки (симптом → причина → виправлення)

1) Симптом: «Деякі сайти таймаутяться, але ping6 працює»

Коренева причина: ICMPv6 echo працює, але TCP/UDP блокується або NAT64/DNS64 заважає, або MTU зламаний для більших пакетів.

Виправлення: Тестуйте curl -6 -I, потім перевірте MTU. Переконайтеся, що фаєрвол дозволяє вихідний IPv6 і критичні типи ICMPv6, особливо Packet Too Big.

2) Симптом: «IPv6 DNS‑запити повільні; IPv4 DNS швидкий»

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

Виправлення: Змініть DNS на досяжний резольвер через IPv6, або тимчасово віддавайте перевагу IPv4‑транспорту DNS, доки не відремонтуєте досяжність IPv6 до резольвера.

3) Симптом: «Працює по Wi‑Fi, ламається по Ethernet (або навпаки)»

Коренева причина: Різні RA, різні DNS‑сервери або різні IPv6‑маршрути за замовчуванням і метрики по лінках.

Виправлення: Порівняйте resolvectl status і ip -6 route на кожному лінку. Виправте метрики маршрутів або зупиніть джерело хибних RA.

4) Симптом: «Після увімкнення VPN випадкові сайти ламаються»

Коренева причина: VPN рекламує себе як default route для IPv6, але не несе IPv6‑трафік належним чином; або перехоплює DNS і неправильно обробляє AAAA.

Виправлення: Переконайтеся, що VPN підтримує IPv6 наскрізь, або налаштуйте split tunneling правильно. Перевірте за допомогою ip -6 route get для проблемних адрес.

5) Симптом: «Браузер крутиться, але curl -4 працює одразу»

Коренева причина: IPv6 має пріоритет; відкладені fallback‑механізми Happy Eyeballs роблять браузер схожим на завислий.

Виправлення: Виправте шлях IPv6 (не ховайте його). Тимчасово можна скорегувати DNS або маршрути так, щоб IPv6 використовувався тільки коли дійсно працює.

6) Симптом: «Тільки великі завантаження падають по IPv6»

Коренева причина: MTU‑чорна діра або блокування ICMPv6 Packet Too Big.

Виправлення: Дозвольте ICMPv6 PTB. Обмежте MSS на краю, якщо контролюєте його. Зменшіть MTU тунелю або виправте PMTUD повністю.

7) Симптом: «IPv6‑адреса є, але немає маршруту за замовчуванням»

Коренева причина: RA не отримано, RA ігнорується (accept-ra: false), RA фільтрується (RA‑guard) або маршрутизатор не рекламує дефолт.

Виправлення: Підтвердіть отримання RA в логах networkd/NetworkManager; виправте netplan; налаштуйте RA‑guard на комутаторі.

8) Симптом: «Все працює деякий час, потім ламається до повторного підключення»

Коренева причина: Приватні адреси обертаються й якийсь апстрімний ACL або зламаний кеш сусідів не встигає; або застарілі маршрути від тимчасового інтерфейсу.

Виправлення: Шукайте флапи маршрутів і зміни адрес. Для серверів використовуйте стабільну адресацію; для клієнтів виправте апстрімні фільтри й стабільність маршрутизації.

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

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

Середня компанія розгорнула Ubuntu 24.04 на флоті девелоперів. За день служба підтримки отримала нову категорію: «інтернет нестабільний».
Розробники повідомляли, що встановлення пакетів зависає, деякі SaaS‑дашборди підвантажуються наполовину, і переадресації аутентифікації іноді провалюються.
Мережевики наполягали, що WAN чистий. Команда кінцевих точок наполягала, що це оновлення браузера. Всі були праві, що найнеприємніший вид правоти.

Неправильне припущення було дрібним і смертельним: «якщо клієнт має IPv6‑адресу, IPv6 має працювати». На гостьовому Wi‑Fi і на деяких поверхах точки доступу надсилали Router Advertisements з глобальним префіксом (тому клієнти налаштовували IPv6), але апстрімна маршрутизація для цього префікса була відсутня на одному дистрибутивному комутаторі.
IPv6‑пакети виходили з клієнта і зникали в порожнечу. IPv4 працював, тому ніхто не отримав виклику «інтернет впав».

Шаблон симптомів виглядав випадковим, бо лише призначення з AAAA викликали зламаний IPv6‑шлях. І оскільки різні CDN повертали AAAA для різних регіонів,
дві людини можуть сидіти поруч і потрапляти на різні проблемні краї.

Виправлення було нудне: припинити рекламувати те, що не можете маршрутизувати. Вони виправили конфігурацію RA на постраждалих SSID і перевірили, що кожен рекламований префікс має апстрім‑маршрут.
Також додали просту клієнтську перевірку при підключенні пристроїв: якщо існує IPv6‑маршрут за замовчуванням, перевірити короткий перелік тестів IPv6‑досяжності перед оголошенням мережі «здоровою».

Міні‑історія 2: Оптимізація, що обернулась боком

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

Це добре працювало в головному офісі. Добре в дата‑центрах. Але віддалені офіси почали скаржитися, що «Microsoft‑сервіси повільні» і «деякі сайти ніколи не завантажуються».
Команда ганялася за кешами браузера, агентами безпеки і навіть за CPU Throttling — бо проблеми не відтворювалися в корпоративній LAN.

Відкат до змішаних резолверів негайно зменшив вплив, але реальне виправлення — привести в порядок MTU для IPv6: дозволити критичні ICMPv6, обмежити MSS де потрібно
і перевірити реальними розмірами корисних даних. Урок не в тому, що IPv6 поганий. Урок у тому, що якщо ви оптимізуєте систему, яку не вимірюєте, ви просто винайшли новий клас інцидентів.

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

Фінансова компанія (така, що любить заморожування змін і ненавидить сюрпризи) мала сувору практику: кожна мережева зміна вимагала перевірки двостеку з канаркового хоста.
Не якийсь складний синтетичний моніторинг — просто скрипт на невеликому Ubuntu VM в кожному сайті, що логував часи DNS, цілісність маршрутів v4/v6 і кілька HEAD‑запитів по обох стеках.

Під час планового оновлення прошивки фаєрвола інженер застосував «затверджений» шаблон політики. Шаблон дозволяв очікувані типи ICMP для IPv4,
але для IPv6 за замовчуванням стояло «deny unknown ICMPv6». Виявлення сусідів й Packet Too Big постраждали як побічний ефект.
За кілька хвилин логи канарки показали, що IPv6 HTTP‑запити зависають, тоді як IPv4 лишався здоровим.

Нудна практика врятувала день, бо зафіксувала регресію до того, як користувачі помітили проблему. On‑call не довелося інтерпретувати нечіткі тикети «Slack якийсь дивний».
Вони мали часові позначки, режими відмов і чіткий diff: IPv6 зламався саме при застосуванні шаблона політики.

Виправлення теж було нудним: явно дозволити типи ICMPv6, необхідні для ND, RA і PMTUD. Постмортем був коротким, спокійним і корисним.
Ніхто не вивчив чарівний трюк. Усі зберегли вихідні вихідні.

Чеклісти / покроковий план

Покроково: зробіть двостек правильним на Ubuntu 24.04

1. Підтвердіть, що симптом пов’язаний з IPv6.
   Використайте curl -4 vs curl -6 для невдалого хостнейму. Якщо IPv6 падає — перестаньте звинувачувати браузер.
2. Перевірте IPv6‑адресу + маршрут за замовчуванням.
   Подивіться ip -6 addr і ip -6 route. Відсутність глобальної адреси або дефолтного маршруту означає, що ви не готові до відлагодження додатків.
3. Підтвердіть виявлення сусідів.
   Перевірте ip -6 neigh. Якщо запис маршрутизатора відсутній або у стані FAILED — у вас проблеми L2/L3 або фільтрація RA.
4. Протестуйте досяжність IPv6 без DNS.
   PING відомої IPv6‑адреси. Якщо не доходить — фокус на апстрім маршрутизації/фаєрвол/VPN.
5. Тестуйте час відповіді DNS і транспорт.
   Використовуйте resolvectl query, порівняйте -4 і -6. Повільний IPv6 DNS — це все одно відмова IPv6.
6. Підтвердіть, які DNS‑сервери використовуються по лінку.
   resolvectl status. Якщо VPN інжектує DNS — перевірте, чи це задумано і чи працює через IPv6.
7. Перевірте MTU і сигнали PMTUD.
   Використайте великі IPv6‑пінги і шукайте зависання. Якщо ви контролюєте край — переконайтеся, що дозволені повідомлення ICMPv6 Packet Too Big.
8. Аудит політики фаєрвола щодо реалій IPv6.
   Використайте nft list ruleset. Дозвольте критичні типи ICMPv6. Не «захищайте» протокол у стан повної відмови.
9. Зафіксуйте правильність netplan.
   Перевірте renderer, accept‑RA, налаштування DHCPv6. Застосовуйте зміни обережно і мінімально.
10. Захопіть докази до і після змін.
    Короткий tcpdump коштує тисячі Slack‑ниток. Збережіть із часовою міткою і імʼям інтерфейсу.

Операційний чекліст: щоб не повернулося

• Тримайте канарку з двостеком (часи DNS + HTTP по v4/v6) на кожному сайті/VLAN/VPN‑профілі.
• Вимагайте від ревʼюерів змін явно враховувати правила ICMPv6, а не як примітку.
• Відстежуйте джерела RA; «хибний RA» — реальна режим несправності, а не теорія.
• Документуйте метрики маршрутів і політику маршрутизації коли задіяні VPN.
• Коли змінюєте MTU десь — валідовуйте IPv6 PMTUD реальними розмірами корисних даних.

Цитата, яку варто тримати на моніторі

«Надія — не стратегія.» — Джин Кранс (парафразована ідея)

Підставте «відключення IPv6» замість «надії» — і отримаєте мораль усієї цієї історії.

FAQ

1) Чому ламаються лише деякі сайти?

Бо лише деякі сайти публікують AAAA‑записи, і лише деякі CDN направляють вас на IPv6‑край, який ваша мережа не може стабільно досягти.
Ваш браузер намагається IPv6 першим, натрапляє на мертву дорогу, а потім зрештою повертається на IPv4.

2) Можна просто відключити IPv6 на Ubuntu 24.04?

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

3) Якщо ping6 працює, хіба це не доводить, що IPv6 у порядку?

Ні. ICMPv6 echo може пройти, тоді як TCP/UDP не працює через політику фаєрвола, проблеми MTU/PMTUD або асиметричну маршрутизацію.
Розглядайте ping6 як відправну точку, а не вердикт.

4) Яка найпоширеніша реальна причина?

Зламаний IPv6‑маршрут, рекламований через RA (клієнти отримують адреси і віддають перевагу IPv6), при цьому апстрім фактично не маршрутизує цей префікс.
Друге місце — MTU‑чорні діри через блокування ICMPv6 Packet Too Big.

5) Як зрозуміти, чи systemd‑resolved винен?

Якщо resolvectl query повільний або непослідовний, і особливо якщо resolvectl status показує недосяжні DNS‑сервери,
резольвер лише виявляє проблему транспорту. Сам демон рідко є кореневою причиною.

6) Чому VPN погіршує ситуацію?

VPN часто змінюють маршрути й DNS‑сервери. Якщо VPN заявляє дефолтний маршрут IPv6, але не несе IPv6‑трафік, хост буде відправляти IPv6 у тунель, що веде в нікуди.
Або DNS‑резольвер VPN неправильно обробляє AAAA. У будь‑якому разі — двостек підсилює ефект збоїв.

7) Які типи ICMPv6 потрібно дозволити?

Мінімум: neighbor solicitation/advertisement, router solicitation/advertisement, packet‑too‑big, time‑exceeded і parameter‑problem.
Точна політика залежить від середовища, але «блокувати весь ICMPv6» — це самозадіяна генерація відмови.

8) Як MTU‑проблеми проявляються в браузерах?

Ви побачите підключення, що стартують, але не завершуються: TLS‑хендшейки зависають, великі ресурси таймаутяться, або QUIC падає, тоді як TCP іноді працює.
Якщо малі payload‑и проходять, а більші ні — одразу підозрюйте MTU/PMTUD.

9) Чи це специфічно для Ubuntu 24.04?

Основні режими відмов універсальні. Те, що змінюється між релізами — це внутрішні компоненти: поведінка резольвера, дефолтні налаштування netplan, версії NetworkManager,
і наскільки агресивно додатки віддають перевагу IPv6. Ubuntu 24.04 достатньо сучасна, щоб не обходити ваше зламане IPv6.

10) Яке найшвидше безпечне тимчасове помʼякшення, поки я ремонтую мережу?

Віддавайте перевагу стабільному транспорту DNS і стабільній маршрутизації. Наприклад, переконайтеся, що DNS‑сервери досяжні через IPv6 (або тимчасово використовуйте IPv4‑резолвери),
і не дозволяйте зламаному інтерфейсу/VPN бути дефолтним маршрутом IPv6. Уникайте відключення IPv6 на рівні ядра, хіба що ви ізолюєте активний інцидент.

Висновок: наступні кроки, що не застаріють

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

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

Жарт №2: Хороша новина — в IPv6 достатньо адресів для кожного вашого пристрою. Погана новина — також достатньо способів їх неправильно налаштувати.