Що таке CGNAT? Чому Port Forwarding не працює та як це обійти

Коли правильне перенаправлення портів все одно нікуди не веде

Ваш NAS відкривається нормально вдома. Сервіс працює, а правило перенаправлення портів вказує на правильну локальну адресу. Потім ви перемикаєте телефон на мобільні дані, спробуєте ще раз і отримуєте timeout. Та сама закономірність може вплинути на домашній ігровий сервер, VPN сервер, CCTV трансляцію або самостійно розміщену програму.

Швидка відповідь полягає в тому, що правило може бути правильним, але знаходитися за іншою межею. З Carrier-Grade NAT (CGNAT) ISP ділить публічні IPv4 адреси і приймає перше вхідне рішення вище за течією. Ви контролюєте правило на своєму домашньому маршрутизаторі, але нове інтернет-з’єднання ніколи до нього не дійде, якщо транслятор провайдера не знає, куди його відправити.

Це не доводить, що CGNAT відповідальний; локальні проблеми можуть виглядати однаково. Сервіс може слухати тільки на localhost, або брандмауер хоста може його блокувати. Правило маршрутизатора може використовувати неправильний протокол TCP/UDP або застарілу цільову адресу, тоді як другий локальний маршрутизатор може додати іншу межу. Спочатку визначте межу, розрізніть CGNAT від звичайного та подвійного NAT, потім виберіть обхідний шлях для доступу, який вам потрібен.

Швидкі ключові терміни: що таке CGNAT і чому ISP його використовують

Цих термінів достатньо, щоб стежити, де саме зупиняється відсутнє з’єднання.

RFC 6888 визначає Carrier-Grade NAT (CGN)—також називається Large-Scale NAT (LSN)—як функцію на стороні провайдера, яка дозволяє кільком абонентам спільно використовувати IPv4 адресу. Абоненти не керують нею. “Carrier-grade” описує розміщення та масштаб, а не вищу якість.

Межа власності виглядає так:

YOU CONTROL                         ISP CONTROLS
device → home router / NAT → ISP CGNAT → shared public IPv4 → internet

Домашній маршрутизатор керує локальною мережею клієнта. CGN ISP відображає з’єднання абонентів на його спільну публічну адресу. Звичайний перегляд все ще працює, тому що пристрій починає розмову, і обидва рівні трансляції можуть відстежити відповідь.

Думайте про публічну IPv4 адресу як про вхід будівлі на вулицю, а про порт як про дзвінок. Ваш маршрутизатор — це внутрішня стійка реєстрації. CGNAT додає зовнішню стійку, спільну для багатьох клієнтів і керовану ISP. Порти допомагають цій зовнішній стійці відстежувати активні розмови; вони не дають кожному клієнту постійне володіння кожним дзвінком на спільній адресі.

ISP використовують цей дизайн, тому що глобально маршрутизований простір IPv4 обмежений, а перехід на IPv6 залишається незавершеним. Регіональні вільні пули фактично вичерпані, хоча існуючі адреси все ще можуть передаватися та повторно використовуватися. CGNAT зберігає сумісність IPv4 шляхом спільного використання дефіцитних адрес. IPv6 забезпечує більший довгостроковий простір адрес, але він недоступний наскрізь скрізь.

NAT vs Double NAT vs CGNAT

Вирішальні питання — не “Скільки боксів я бачу?” а “Де відбувається трансляція і хто її може змінити?”

📝 Примітка: CGNAT часто призводить до двох рівнів IPv4 NAT, коли присутній домашній маршрутизатор, але “CGNAT” називає функцію, керовану ISP, тоді як “подвійний NAT” описує лише топологію.

Це розрізнення у власності змінює те, що ви можете виправити. З двома локальними шлюзами ви можете використовувати режим bridge/AP або налаштувати обидва рівні. Транслятор провайдера знаходиться поза цими елементами управління, а деякі конструкції CGNAT взагалі не включають другого керованого користувачем транслятора.

Позначення консолі, такі як “відкритий”, “помірний” або “суворий” NAT, — це окремо. Вони підсумовують поведінку підключення для цієї платформи; вони не визначають, хто володіє трансляторами, і не доводять наявність CGNAT.

Чому переадресація портів не працює за CGNAT

Вихідний трафік працює, тому що кожен транслятор створює стан: тимчасовий запис, який пов’язує внутрішній потік із зовнішньою адресою та портом. Коли ваш пристрій ініціює запит, домашній маршрутизатор та ISP CGN кожен записують його, дозволяючи відповідним відповідям повернутися.

Нове вхідне з’єднання не має такого стану. Воно спочатку досягає спільної публічної IPv4 ISP, де CGN не має відображення для конкретного абонента:

OUTBOUND WORKS
device → home NAT [state created] → ISP CGN [state created] → internet
device ← home NAT [state match]   ← ISP CGN [state match]   ← reply

NEW INBOUND CONNECTION STOPS
outside user → shared public IPv4 → ISP CGN
                                      X — no subscriber mapping
                                      home router is never reached

Ось чому переадресація портів CGNAT не працює. Ваше правило домашнього маршрутизатора може бути дійсним, але воно належить до внутрішньої стійки реєстрації. Зміна списку відвідувачів цієї стійки не може повідомити спільну зовнішню стійку ISP, який абонент повинен отримати несподіваного відвідувача. Пакет ніколи не досягає вашого правила.

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

Як визначити, чи ви за CGNAT

Використовуйте докази в такому порядку:

1. Вимкніть VPN та проксі. Вимкніть все, що змінює публічну адресу, з якої виглядає вихід вашого трафіку.
2. Визначте шлюз, звернений до ISP. Використовуйте маршрутизатор або модем, безпосередньо підключені до провайдера, а не другий маршрутизатор далі всередині вашої мережі.
3. Порівняйте дві адреси. Запишіть WAN або адресу Internet IPv4 цього шлюзу, а потім одночасно використовуйте зовнішній сервіс для перегляду вашої публічної IPv4.

❗ Важливо: Невідповідність між WAN та публічними адресами доводує наявність межі трансляції вище за течією, але не автоматично означає, що це CGNAT. Робіть цей висновок лише на основі шлюзу, безпосередньо підключеного до ISP.

4. Інтерпретуйте результат. Використовуйте ці сигнали разом:
   • WAN адреса в 100.64.0.0/10—100.64.0.0 через 100.127.255.255—є сильним доказом CGNAT. RFC 6598 зарезервував цей не глобально маршрутизований Простір спільних адрес для використання провайдером; це не приватний простір RFC 1918.
   • Адреса в 10.0.0.0/8, 172.16.0.0/12 або 192.168.0.0/16 також показує не публічну WAN, але вона може належати іншому локальному маршрутизатору.
   • Різні WAN та публічні адреси вказують на трансляцію вище за течією. Збіг глобально маршрутизованих адрес робить звичайний IPv4 CGNAT набагато менш імовірним на цьому шляху.
5. Виключіть локальні причини. Перш ніж називати це CGNAT, перевірте, що:
   • Сервіс прослуховує свою LAN адресу, а не тільки localhost.
   • Брандмауер хоста дозволяє призначений порт та протокол.
   • Правило маршрутизатора спрямоване на поточну внутрішню адресу та правильний вибір TCP/UDP.
   • Другий локальний маршрутизатор не додає ще один рівень трансляції.
   • Тест проводиться з мобільних даних або іншої справді зовнішної мережі.
6. Підтвердьте у ISP. Traceroute може підтримати діагностику, коли спільні або приватні переходи з’являються за межами домашнього шлюзу, але приховані переходи роблять це неоднозначним. Запитайте у провайдера, чи використовує лінія CGNAT та чи доступна динамічна або статична публічна IPv4.

На що впливає CGNAT — і на що зазвичай не впливає

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

Прямий IPv4 хостинг та віддалений доступ тому потребують іншого доступного шляху. У приватній мережі це впливає на доступ до NAS, системи CCTV або внутрішньої панелі керування. Публічні веб-сайти, приймачі вебхуків та ігрові сервери стикаються з тією ж вимогою входу. Клієнт VPN зазвичай працює, тому що він підключається назовні. Домашній VPN-сервер відрізняється, оскільки віддалені користувачі розпочинають з’єднання, тому йому потрібен доступний вхід, сумісний IPv6 або кінцева точка на реле або публічному хості.

Однорангові ігри, голос та обмін файлами менш передбачувані. Деякі додатки знаходять прямий маршрут, а інші використовують реле через доступного посередника. Реле може зберегти з’єднання за рахунок доданої затримки. Коли обхід не вдається, додаток може повідомити про обмежувальний NAT або не підключитися. RFC 7021 документує ці критичні точки без припущення універсального збою.

Спільне використання адреси IPv4 може об’єднати непов’язаних абонентів в одну репутацію. Поведінка одного користувача може спричинити, що інші абоненти бачитимуть більше CAPTCHA або обмежень швидкості. Спільна або змінна адреса виходу для житлових користувачів також ускладнює бізнес-дозволи, які очікують стабільну кінцеву точку.

📝 Примітка: Блокування небажаного вхідного IPv4 за замовчуванням може зменшити випадкове розкриття, але CGNAT не є брандмауером і не замінює автентифікацію, оновлення, TLS або політику доступу.

CGNAT не зупиняє шкідливий вихідний трафік. Він не захищає додатки, розкриті через інший шлях, і не контролює, хто може увійти. Тунель, публічна IP або маршрут IPv6 все ще потребують навмисних заходів безпеки.

П’ять способів обійти CGNAT

П’ять варіантів вирішують різні проблеми доступу. Приватні mesh-мережі, керовані тунелі та VPS-релеї мають один корисний паттерн: приватна сторона спочатку підключається назовні.

private service → outbound mesh / tunnel link → reachable edge ← outside user

За аналогією будівлі ви або отримуєте придатний вхід на вулицю, або підтримуєте лінію до входу в іншому місці.

📝 Примітка: “Обхід” — це скорочення. Ці підходи не вимикають carrier NAT; вони отримують інший публічний край, використовують наскрізне IPv6 або встановлюють шлях, створений вихідним трафіком.

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

1. Попросіть у ISP публічний IPv4

Для загального вхідного IPv4 це зазвичай найпростіший варіант, коли ISP його пропонує. Динамічний публічний IPv4 працює з оновленим DNS. Виберіть статичний публічний IPv4 для стійких списків дозволів, записів або VPN-кінцевих точок. Перевірте доступність та вартість, і захистіть будь-який сервіс, який ви експонуєте безпосередньо.

2. Використовуйте нативний IPv6

Трафік IPv6 уникає IPv4 CGNAT. Прямий доступ вимагає глобального префіксу, слухача IPv6, відповідних правил брандмауера, правильного DNS де потрібно, та IPv6 на віддаленій стороні. Це не допомагає клієнтам, які використовують лише IPv4, або автоматично не експонує сервіс.

3. Побудуйте приватну Mesh-мережу

Mesh VPN, наприклад Tailscale, підходить для надійних користувачів та пристроїв, які можуть запускати автентифіковане клієнтське ПО. Вона намагається встановити прямі з’єднання, потім може повернутися до однорангового або DERP-релею з деякими витратами на продуктивність. Вона не призначена для анонімних відвідувачів або публічних вебхуків.

4. Публікуйте через керований вихідний тунель

Сервіс, такий як Cloudflare Tunnel, підключає походження назовні до краю провайдера. Це добре працює для веб-додатків, API, демонстрацій та контрольованого приватного доступу. Публічні HTTP-відвідувачі можуть не потребувати клієнта, тоді як приватні або не-веб-режими можуть вимагати ПО провайдера. Підтримка протоколу, ідентичність, обмеження та доступність краю залишаються залежностями провайдера.

5. Використовуйте VPS як публічний край — або перемістіть навантаження

VPS може релейовувати трафік через вихідний тунель з дому або безпосередньо розміщувати додаток, коли йому не потрібні дані або обладнання домашної LAN. Це пропонує стійку кінцеву точку та широкий контроль TCP/UDP. Ви несете відповідальність за безпеку, моніторинг, надійність тунелю, пропускну спроможність, обробку зловживань та додану затримку. Відповідно вибраний AlexHost VPS може виконувати цю роль, з урахуванням його публічної адресації та політики мережі.

Яка опція підходить для вашого випадку?

Виберіть архітектуру, задавши чотири запитання по порядку:

1. Доступ обмежений надійними людьми та пристроями, чи відкритий для громадськості?
2. Кожен пристрій, що підключається, може встановити та автентифікуватися через клієнтське програмне забезпечення?
3. Сервіс веб-базований, чи потребує довільної поведінки TCP/UDP?
4. Ви віддаєте перевагу керованій зручності чи контролю над публічним шлюзом?

Для надійного NAS, CCTV або доступу адміністратора, використовуйте mesh VPN, коли користувачі можуть встановити клієнтське програмне забезпечення. Для публічних веб-точок та вебхуків використовуйте керований тунель або публічний хостинг. Перемістіть навантаження, якщо воно не потребує домашної LAN.

Для публічного TCP/UDP, використовуйте публічний IPv4 від ISP, VPS edge або IPv6, коли всі клієнти його підтримують. Хостинг ігор залежить від назви: перевірте його модель сервера, підтримку traversal та протоколи. Загальний тунель не може гарантувати кращу мітку NAT консолі.

Публічна VPN точка потребує публічного IPv4, робочого IPv6 або хоста VPS. Для бізнес-входу або дозволів партнерів виберіть статичну адресу або контрольований шлюз замість спільного житлового виходу.

Поширені запитання та неправильні уявлення про CGNAT

Чи CGNAT те саме, що double NAT? Ні. CGNAT визначає багатокористувацький NAT, керований ISP. Double NAT означає лише те, що трафік проходить через два трансляторів.

Чи CGNAT завжди сповільнює інтернет? Ні. Продуктивність залежить більше від провайдера, програми та того, чи задіяна ретрансляція.

Чи може динамічний DNS виправити CGNAT? Ні. Він відстежує змінюючуюся адресу, але не може створити вихідне відображення. Він допомагає, коли у вас є досяжна динамічна публічна адреса.

Чи звичайний VPN обходить CGNAT? Зазвичай ні. Це працює лише тоді, коли служба VPN надає вхідну переадресацію, приватне накладення або іншу досяжну точку входу.

Чи може IPv6 вирішити проблему? Так, коли обидва кінці мають IPv6 і брандмауер та DNS дозволяють це. Це не допомагає клієнтам, які використовують лише IPv4.

Чи 100.64.0.0/10 приватний простір? Це спеціального призначення, не глобально маршрутизований Shared Address Space. Він відрізняється від приватних діапазонів RFC 1918, які використовуються в звичайних локальних мережах.

Чи CGNAT є функцією безпеки? Ні. Його вхідна поведінка не є політикою безпеки. Вам все ще потрібні правила брандмауера, аутентифікація, виправлення, шифрування та обережна експозиція.

Підсумок: виправте відсутній публічний край, а не просто маршрутизатор

Відкритий NAS або ігровий сервер можуть мати правильне локальне правило і все одно вичерпати час очікування, оскільки з’єднання зупиняється на межі ISP. Більше змін маршрутизатора не виправлять шлях, який маршрутизатор ніколи не отримує. Почніть з аудиторії: використовуйте mesh для надійного приватного доступу, тоді як публічний доступ потребує публічного IPv4, працюючого IPv6, керованого тунелю або контрольованого хоста. Спочатку перевірте параметри ISP, а потім розглядайте AlexHost VPS лише коли розміщена робоча навантаження або реле відповідає дизайну.