Начните бесплатный 3-дневный пробный период
Зарегистрируйтесь и попробуйте все премиум-функции бесплатно.
*Только для новых пользователей. Один пробный период на пользователя.


CGNAT — это преобразование адресов у интернет-провайдера, позволяющее нескольким абонентам использовать общие публичные IPv4-адреса. Оно может мешать обычному пробросу портов принимать новые интернет-соединения, поскольку домашний роутер не управляет вышестоящим отображением провайдера.[1][2]
Ключевые выводы
- Домашнее правило управляет роутером, а не NAT оператора.
- WAN в
100.64.0.0/10является полезным признаком, но не самостоятельным доказательством.[1]- Двойной NAT дома, VPN-выход и входящий firewall могут давать похожие симптомы.
- Публичный IPv4, сквозной IPv6 и контролируемое реле решают разные условия доступности.
Обычный роутер преобразует частные адреса домашних устройств в свой WAN-адрес. При CGNAT провайдер преобразует соединение ещё раз в публичный IPv4, используемый несколькими абонентами. У двух преобразований собственное состояние и разные администраторы.
Например, ноутбук может иметь 192.168.1.20, а WAN роутера — 100.64.12.34. Удалённый сервис увидит другой публичный адрес провайдера. Это поясняющие примеры, а не измерения или значения, которые предлагается копировать в настройки.
На схеме исходящее соединение создаёт состояние через оба слоя. Соответствующие ему ответы возвращаются устройству; новый входящий запрос без подходящего отображения нельзя просто отправить выбранному домашнему серверу. Поэтому веб-страницы могут открываться, а собственный сервер оставаться недоступным.
RFC 6598 резервирует 100.64.0.0/10 для Shared Address Space отдельно от частного пространства RFC 1918. Диапазон заканчивается на 100.127.255.255: не каждый адрес 100.x.x.x входит в него. Такое пространство не является обычным глобально достижимым публичным адресом.[1]
Не путайте адрес ноутбука с интернет-интерфейсом роутера. Частный LAN нормален и почти ничего не говорит о верхней сети провайдера. Категории IP-адресов объясняют, почему частный, общий, публичный и статический описывают разные свойства.
Основы VPN дают отдельную модель туннеля. NAT преобразует адреса и порты; VPN переносит трафик по другому пути. Ни одно название само по себе не устанавливает возможность внешнего клиента начать соединение с домашним устройством.
Правило роутера действует на подходящий трафик, который уже дошёл до его WAN. Пакет к общему публичному адресу сначала приходит на оборудование провайдера. Без применимого верхнего отображения он может вообще не попасть к вашему роутеру, независимо от правильности локального правила.
Это граница управления. Вы контролируете домашний роутер, firewall устройства и слушающий сервис, но не произвольное отображение у провайдера. Повторение правила либо выбор другого локального порта не создают разрешения на чужом оборудовании.
Браузер или игровой клиент начинает исходящее соединение изнутри. NAT сохраняет сведения, позволяющие доставлять ответы удалённого узла. Для собственного сервера внешний клиент начинает новое соединение, которому нужны достижимый адрес и разрешённый входящий путь.
Некоторые приложения согласуют соединение или используют реле вместо прямого входящего доступа. Их работа не доказывает доступность всех портов. Неудачное приглашение в игру также не доказывает CGNAT: причиной могут быть игровой сервер, firewall либо дополнительный NAT.
RFC 6888 содержит требования к поведению CGN и управлению отображениями абонентом. Провайдер может предлагать поддерживаемый механизм отображения или другой продукт, но стандарт не обещает доступность настройки каждому абоненту. Уточните реализацию оператора вместо утверждения, что любые CGN всегда неизменяемы.[2]
UPnP и ручной проброс могут менять только домашний слой. DMZ host не устраняет верхний NAT и способен расширить экспозицию устройства, если позднее появится публичная доступность. Отключение firewall поэтому не заменяет поиск отсутствующего отображения.
Когда игре действительно нужен проброс помогает решить, оправдано ли узкое правило. Сначала подтвердите, что пакет может дойти до роутера, затем используйте документированные протоколы и порты игры. Не открывайте большой диапазон ради предположения.
Сравните настоящий WAN IPv4 роутера с интернет-видимым IPv4 на том же соединении и в том же семействе адресов. Прочитайте статус роутера и проверьте текущий выходной адрес без необязательного VPN или прокси. Если управляемый туннель нельзя отключить, запишите ограничение и не принимайте его выход за адрес провайдера.
Мобильная точка доступа, второй роутер или модем в режиме маршрутизатора могут добавить преобразование. Нарисуйте физические устройства, которыми управляете, прежде чем приписывать различие оператору. Для первой проверки достаточно чтения статуса; не стирайте настройки и не меняйте режим моста только ради признака.
| Признак | Чего не доказывает | Следующее подтверждение |
|---|---|---|
WAN в 100.64.0.0/10 | Какой узел и администратор используют диапазон | Спросить оператора о CGN и входящих вариантах |
| WAN из RFC 1918 | Что NAT принадлежит провайдеру, а не второму домашнему роутеру | Проверить верхний модем и топологию |
| WAN отличается от видимого IPv4 | Что это CGN, а не VPN, прокси или другой NAT | Повторить без необязательного туннеля на том же IPv4-пути |
| WAN совпадает с видимым IPv4 | Что сервис слушает и оператор разрешает входящие | Проверить привязку, правило и оба firewall |
| IPv6 работает, IPv4-хостинг нет | Что IPv6-клиент проходит firewall сервиса | Подтвердить глобальный адрес, работу службы и разрешённый внешний тест |
| Traceroute содержит частные адреса | Точную границу NAT и политику отображений | Использовать как контекст и получить ответ оператора |
Сравнение адресов не заменяет проверку порта. Тестер не обнаружит сервис, если тот остановлен, слушает только на loopback или использует другой протокол. TCP и UDP проверяются отдельно, а отсутствие ответа UDP особенно легко ошибочно принять за закрытый путь.
Доступ к собственному публичному адресу из дома может зависеть от поддержки loopback роутера. Поэтому локальный результат не обязательно совпадает с проверкой настоящего внешнего клиента. Используйте разрешённое внешнее соединение только для оборудования, которым вправе управлять.
Сохраните WAN, видимый адрес, дату, тип доступа и верхние устройства приватно. Не публикуйте страницу администрирования с идентификаторами аккаунта или паролями роутера. Для заявки провайдеру достаточно короткого описания топологии, без раскрытия чувствительных сведений на форуме.
Проблема часто проявляется при приёме нового входящего соединения: собственный игровой сервер, peer-сессия или удалённый домашний сервис. Просмотр страниц и видео может работать через состояние исходящих запросов. Разные приложения по-разному обходятся с этой границей соединения.
Strict NAT является меткой конкретного приложения, а не готовым диагнозом провайдера. При подключении к чужому серверу прямой входящий доступ может не требоваться. Для собственного хостинга сначала узнайте модель приложения, наличие реле или управляемого сервера, а затем рассматривайте другой интернет-продукт.
Открытый порт не обязан снижать ping, устранять помехи Wi-Fi или увеличивать пропускную способность. Достижимый сервис может быть медленным, а быстрое соединение — не принимать входящие. Диагностика NAT на ПК отделяет ошибки платформы от общего объяснения адресов.
На границе VPN AethoVPN пересылает исходящий трафик через зашифрованное соединение: путь в интернет меняется, но это не обещание публичного входящего адреса или настраиваемого порта. Разбор VPN port forwarding объясняет, почему входящая поддержка должна быть явно заявленной функцией, а не предположением о туннеле.
Если провайдер подтвердил CGNAT, но приложение успешно работает через реле, менять настройки может быть незачем. Выбирайте решение задачи, а не Open NAT ради самой метки. Проверяйте также состояние серверов приложения и разрешения аккаунта: общий адрес не объясняет любую ошибку.
Выберите минимальный вариант, который даёт требуемую доступность. Ни один не отменяет аутентификацию сервиса, обновления и firewall. Публичный адрес означает возможность маршрутизации, а не безопасность публикации домашнего устройства.
| Вариант | Условие | Ограничение или риск |
|---|---|---|
| Публичный IPv4 или отказ от CGN | Провайдер предоставляет достижимый адрес и разрешает входящие | Домашние правила сохраняются; динамический адрес меняется |
| Отображение провайдера | Документированная услуга оператора | Порт, срок и протокол могут ограничиваться |
| Сквозной IPv6 | Поддержка обоих узлов и сервиса | Требуется явное разрешение входящего firewall |
| Контролируемое реле или overlay | Разрешённые исходящие соединения обоих концов | Важны доверие, аутентификация, доступ и доступность реле |
| Удалённый сервер | Приложение может работать на подходящем хосте | Отдельные расходы, управление и экспозиция |
Спросите, достижим ли адрес извне и разрешён ли входящий трафик. Статика удобна для постоянного адреса сервиса, но динамический публичный адрес с подходящим обнаружением тоже может поддерживать входящие. Статический частный или общий адрес не снимает верхнюю границу NAT.
Не покупайте обновление только из-за слова «статический». Опишите сервис, протокол, необходимые порты и предполагаемое использование. После изменения подтвердите фактический WAN-путь, а не полагайтесь лишь на название услуги в продаже.
IPv6 может избежать IPv4 CGN, если оба узла имеют рабочую связь и сервис слушает IPv6. Глобальный адрес не обходит firewall; клиент только с IPv4 не сможет прямо его использовать. Откройте лишь нужный сервис, сохраняйте аутентификацию и шифрование, отзывайте временный доступ.
Контролируемое реле принимает исходящее соединение домашнего устройства и переносит разрешённый удалённый доступ. Проверьте оператора, кто может присоединяться, хранение учётных данных и отзыв доступа. Лучше дать право на конкретный сервис, чем публиковать всю домашнюю сеть.
Если оператор не предлагает подходящего пути, а приложение не поддерживает реле, прекратите эксперименты с роутером и выберите другое размещение. Сохраните запись изменений и удалите пробные правила проброса после завершения диагностики.
CGNAT описывает адресное разделение провайдера, а двойной NAT — несколько слоёв преобразования. Два домашних роутера могут создать двойной NAT без доказательства CGN у оператора.
RFC 6598 резервирует только 100.64.0.0/10, до 100.127.255.255. Даже попадание в диапазон требует топологии и подтверждения провайдера для окончательного вывода.[1]
Одно домашнее правило не создаёт отображения провайдера. Оно может пригодиться вместе с поддерживаемой оператором входящей услугой, существование которой нужно сначала подтвердить.[2]
Оно убирает один признак верхнего преобразования, но не доказывает работу службы или разрешение firewall. Проверьте сервис, протокол, правило роутера и разрешённый внешний доступ отдельно.
Обычный исходящий туннель не предоставляет право на публичное отображение порта. Нужна явно поддерживаемая входящая услуга, и безопасность конечного устройства по-прежнему важна.
Это не устраняет NAT провайдера и может увеличить экспозицию. Сначала найдите верхнюю границу, затем разрешайте только документированный сервис на установленном пути.
Рабочий сквозной IPv6-путь может избежать преобразования IPv4 CGN. Оба узла и сервис должны поддерживать IPv6, а входящий firewall — разрешать нужное соединение.
В этой диагностике речь прежде всего о разделении адресов и доступности. Для скорости нужны отдельные сведения о нагрузке, Wi-Fi, маршруте и приложении; NAT-метка не устанавливает причину.
Отказ от ответственности: Адреса и схема являются примерами, а не измерениями вашего подключения. Подтвердите политику оператора и защитите опубликованный сервис; это общая техническая информация.
Источники:
Sources checked 5 октября 2026 г.
Рекомендуемые статьи:
Зарегистрируйтесь и попробуйте все премиум-функции бесплатно.
*Только для новых пользователей. Один пробный период на пользователя.





