Сервер без IPv4: що ламається і як допомагає NAT64

Коли серверу не потрібен власний IPv4

Сервер без власного IPv4 має лише адресу IPv6: назовні він ходить по IPv6, а до ресурсів, що залишилися на IPv4, — через шлюз NAT64. Це вигідно, коли адреса коштує грошей, а сервісу потрібні лише з’єднання по IPv6. Якщо без сервісів лише з IPv4 не обійтися, доведеться додавати шлюз.

Підходять внутрішні сервіси за проксі, тестові стенди та вузли кластера. Обережніше з поштовим сервером: частина отримувачів може приймати пошту лише по IPv4. Про звичайний NAT є окрема стаття: що таке NAT і як він працює.

Скільки коштує окремий IPv4 і чому він дорожчає

Публічна адреса IPv4 стала платною статтею: AWS бере 0,005 долара на годину за кожну адресу з 1 лютого 2024 року, Hetzner Cloud — 0,50 євро на місяць за Primary IPv4, а Primary IPv6 безкоштовний. Для одного сервера це небагато, для парку з багатьох машин уже помітно.

Перерахунок мій, а не ціна AWS: 0,005 × 24 × 30 дає близько 3,6 долара. Сторінку цін Hetzner правили у 2023 році, а ціни відтоді піднімали, тому 0,50 євро звірте на живій сторінці.

Причина дефіциту — вичерпання пулу. RIPE NCC вичерпав свій пул IPv4 у листопаді 2019 року, і тепер адреси видаються з повернених за листом очікування. На 23 жовтня 2026 року в ньому стояли 806 заявників (LIR), перший чекав 487 днів: близько 800 заявників і приблизно 16 місяців. Число змінюється, дивіться сторінку листа очікування RIPE NCC.

Чим публічна адреса відрізняється від приватної, розібрано в статті про білу та сіру IP-адресу.

Що ламається на голому IPv6-only

Ламається все, що живе лише на IPv4. Найчастіший приклад — GitHub: на 9 листопада 2026 року у github.com, api.github.com, codeload.github.com, objects.githubusercontent.com та ghcr.io немає записів AAAA, тому git clone з GitHub без NAT64 не запрацює. AAAA є лише у raw.githubusercontent.com. Це замір, а не припущення.

Повторіть перевірку самі: записи можуть змінитися, а порожній вивід означає, що в імені немає адреси IPv6.

dig AAAA github.com +short
dig AAAA raw.githubusercontent.com +short

Для рівноваги: більша частина екосистеми вже доступна по IPv6. Записи AAAA на 9 листопада 2026 року є в решти перевірених імен, список у таблиці.

Застереження: перевірялися записи DNS, а не фактична робота по IPv6. CDN і редиректи можуть вести на імена без AAAA, тому справжню перевірку дає пробне встановлення пакета й пробний клон репозиторію.

Як працюють NAT64 і DNS64

NAT64 (RFC 6146) — шлюз, який приймає з’єднання по IPv6 і від свого імені відкриває з’єднання до сервера по IPv4. DNS64 (RFC 6147) — розширення DNS: для імені без запису AAAA воно вигадує її із запису A. Разом вони дають клієнту лише з IPv6 доступ до ресурсів лише з IPv4.

Синтезовані адреси будуються з префікса. Стандартний префікс — 64:ff9b::/96 (RFC 6052), він не годиться для приватних адрес IPv4; для таких випадків RFC 8215 резервує локальний префікс 64:ff9b:1::/48. Якщо програма звертається до IPv4 за числовою адресою, оминаючи DNS, DNS64 не допоможе: для цього описаний 464XLAT (RFC 6877).

Google Public DNS64 (2001:4860:4860::6464 та 2001:4860:4860::64) — це лише DNS64. Без шлюзу NAT64 він марний: відповіді вкажуть на адреси з 64:ff9b::/96, куди у вас немає маршруту.

Як підключити DNS64 за кроками

Потрібні два компоненти: DNS-резолвер із функцією DNS64 і робочий шлюз NAT64, до якого є маршрут. Резолвер без шлюзу не допоможе, а шлюз без резолвера ніхто не знайде. Спочатку переконайтеся, що IPv6 на сервері взагалі налаштований, потім діяйте за кроками: від перевірки адреси до пробного з’єднання.

1. Перевірте, що в сервера є адреса IPv6 і маршрут за замовчуванням; налаштування описане в статті налаштування IPv6 на VPS з Linux.
2. Вкажіть адресу DNS64-резолвера в налаштуваннях системи: у /etc/resolv.conf або в конфігурації мережі; якщо DNS веде systemd-resolved, дивіться результат у resolvectl status.
3. Запитайте ім’я без AAAA і переконайтеся, що прийшла синтезована адреса з префікса шлюзу.
4. Перевірте реальне з’єднання, а не лише відповідь DNS: curl -6 до сайту без запису AAAA.

ip -6 route show default
dig AAAA github.com +short @<DNS64-resolver>
getent ahostsv6 github.com
curl -6 -sI https://github.com | head -n 1

Якщо синтезована адреса прийшла, а з’єднання не йде, проблема в шлюзі: резолвер видав адресу, але маршруту до NAT64 немає.

Що перевірити перед відмовою від IPv4

Перед відмовою від IPv4 складіть список усього, до чого сервер звертається назовні, і перевірте кожне ім’я на AAAA. Усе, чого немає в IPv6, піде через NAT64 і стане єдиною точкою відмови. Якщо список довгий або важлива надійність, залиште IPv4 хоча б на вході.

• GitHub і все, що збирається з його репозиторіїв, — без NAT64 не запрацює.
• Зовнішні API і платіжні шлюзи: запитайте в постачальника, чи є в них IPv6.
• Доступ до самого сервера: ваш домашній або офісний провайдер має давати IPv6, інакше потрібен проміжний вузол.

Якщо адреса IPv4 усе ж потрібна, додаткові адреси описані в статті про додаткові підмережі IPv4.

Часті запитання

Чи можна зробити git clone з GitHub на сервері лише з IPv6?

Без NAT64 — ні: на 9 листопада 2026 року у github.com немає запису AAAA, перевірте самі командою dig AAAA github.com +short. Через DNS64 і шлюз NAT64 клон працює як звичайне з’єднання.

Чи вистачить одного Google DNS64?

Ні. Це лише резолвер: він поверне адреси з 64:ff9b::/96, а без шлюзу NAT64 пакети за ними нікуди не підуть.

Що робити клієнтам ZevsHost?

На спільному хостингу мережа не у вашому керуванні. У наших тарифах VPS виділена адреса IPv4 уже входить у ціну, а у виділеного сервера видається адреса IPv4 і блок /64 IPv6 — заощаджувати на адресі у нас не треба. NAT64 знадобиться, якщо ви свідомо будуєте мережу без IPv4 або ходите по IPv6 на чужий майданчик; на власному сервері його налаштовуєте ви.