Что такое CGNAT? Почему Port Forwarding не работает и как это обойти

Когда правильное перенаправление портов все равно не работает

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

Быстрый ответ: правило может быть правильным, но находиться за другой границей. При Carrier-Grade NAT (CGNAT) ISP делит публичные IPv4-адреса и принимает первое входящее решение выше по течению. Вы контролируете правило на домашнем маршрутизаторе, но новое интернет-соединение никогда не достигнет его, если транслятор провайдера не знает, куда его отправить.

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

Quick Keywords: What CGNAT Is and Why ISPs Use It

These terms are enough to follow where that missing connection stops.

RFC 6888 defines a Carrier-Grade NAT (CGN)—also called Large-Scale NAT (LSN)—as a provider-side function that lets multiple subscribers share an IPv4 address. Subscribers do not manage it. “Carrier-grade” describes placement and scale, not higher quality.

The ownership boundary looks like this:

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

The home router controls the customer’s local network. The ISP’s CGN maps subscriber connections to its shared public address. Normal browsing still works because a device starts the conversation and both translation layers can track the reply.

Think of the public IPv4 address as a building’s street entrance and a port as a buzzer. Your router is the inner reception desk. CGNAT adds an outer desk shared by many customers and operated by the ISP. Ports help that outer desk track active conversations; they do not give each customer permanent ownership of every buzzer on the shared address.

ISPs use this design because globally routable IPv4 space is constrained and the IPv6 transition remains incomplete. Regional free pools are effectively exhausted, although existing addresses can still be transferred and reused. CGNAT preserves IPv4 compatibility by sharing scarce addresses. IPv6 provides the larger long-term address space, but it is not available end to end everywhere.

NAT vs Double NAT vs CGNAT

Решающие вопросы — не “Сколько устройств я вижу?”, а “Где происходит трансляция и кто её может изменить?”

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

Это различие в собственности меняет то, что вы можете исправить. При наличии двух локальных шлюзов вы можете использовать режим моста/AP или настроить оба уровня. Транслятор провайдера находится вне этих элементов управления, и некоторые конструкции CGNAT вообще не включают второй управляемый клиентом транслятор.

Метки консоли, такие как “открытый”, “умеренный” или “строгий” NAT, — это отдельное понятие. Они суммируют поведение подключения для этой платформы; они не определяют, кто владеет трансляторами, и не доказывают наличие CGNAT.

Почему Port Forwarding не работает за 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 port forwarding не работает. Ваше правило домашнего маршрутизатора может быть действительным, но оно принадлежит внутренней стойке приема. Изменение списка посетителей этой стойки не может сказать общей внешней стойке 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 зарезервировал этот не глобально маршрутизируемый Shared Address Space для использования провайдерами; это не приватное пространство 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

По аналогии со зданием вы либо получаете пригодный уличный вход, либо поддерживаете линию к входу в другом месте.

📝 Примечание: «Обход» — это сокращение. Эти подходы не отключают 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 может ретранслировать трафик через исходящий туннель из дома или размещать приложение напрямую, когда оно не нуждается в данных или оборудовании домашней сети. Это предлагает стабильную конечную точку и широкий контроль TCP/UDP. Вы становитесь ответственны за безопасность, мониторинг, надёжность туннеля, пропускную способность, обработку злоупотреблений и добавленную задержку. Надлежащим образом выбранный VPS от AlexHost может заполнить эту роль, в соответствии с его публичной адресацией и политикой сети.

Какой вариант подходит для вашего случая?

Выберите архитектуру, задав четыре вопроса по порядку:

1. Доступ ограничен доверенными людьми и устройствами или открыт для всех?
2. Может ли каждое подключаемое устройство установить и пройти аутентификацию через клиентское программное обеспечение?
3. Это веб-сервис или требуется произвольное поведение TCP/UDP?
4. Вы предпочитаете управляемое удобство или контроль над публичным шлюзом?

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

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

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

Часто задаваемые вопросы и неправильные представления о CGNAT

CGNAT — это то же самое, что двойной NAT? Нет. CGNAT обозначает многопользовательский NAT, управляемый ISP. Двойной NAT означает только, что трафик проходит через два транслятора.

CGNAT всегда замедляет интернет? Нет. Производительность зависит больше от провайдера, приложения и от того, задействовано ли реле.

Может ли динамический DNS решить проблему CGNAT? Нет. Он отслеживает изменяющийся адрес, но не может создать восходящее сопоставление. Он помогает, когда у вас уже есть доступный динамический публичный адрес.

Обычный VPN обходит CGNAT? Обычно нет. Это работает только, когда служба VPN предоставляет входящую переадресацию, приватный оверлей или другую доступную точку входа.

Может ли IPv6 это решить? Да, когда обе стороны имеют IPv6 и брандмауэр и DNS это разрешают. Это не помогает клиентам, использующим только IPv4.

Является ли 100.64.0.0/10 приватным пространством? Это специального назначения, не глобально маршрутизируемое пространство общих адресов. Оно отличается от диапазонов приватных адресов RFC 1918, используемых в обычных локальных сетях.

CGNAT — это функция безопасности? Нет. Его входящее поведение не является политикой безопасности. Вам по-прежнему нужны правила брандмауэра, аутентификация, исправления, шифрование и осторожное раскрытие.

Итог: исправьте отсутствующий публичный край, а не просто маршрутизатор

Открытый NAS или игровой сервер могут иметь правильное локальное правило и все равно истечь время ожидания, потому что соединение прерывается на границе ISP. Дополнительные изменения маршрутизатора не исправят путь, который маршрутизатор никогда не получает. Начните с аудитории: используйте mesh для доверенного приватного доступа, в то время как публичный доступ требует публичного IPv4, работающего IPv6, управляемого туннеля или контролируемого хоста. Сначала проверьте параметры ISP, затем рассмотрите AlexHost VPS только когда размещенная рабочая нагрузка или релей соответствует дизайну.