CGNAT чи публічна IP: як перевірити й налаштувати доступ
Коротка відповідь: порівняйте WAN IPv4 домашнього роутера з IPv4, яку в той самий момент бачить зовнішній сайт. WAN у 100.64.0.0/10 та інша зовнішня адреса — сильна ознака CGNAT. WAN з 10/8, 172.16/12 або 192.168/16 показує upstream NAT, але це може бути ваш модем чи другий роутер. Правило port forwarding працює лише на тій NAT-межі, якою ви керуєте. Для приватного доступу часто доречний вихідний VPN/overlay; для публічного сервісу потрібні підтверджена досяжна адреса або reverse tunnel. IPv6 є окремим шляхом, який вимагає firewall і зовнішнього тесту.
Три адреси, які не можна плутати
Локальна адреса ноутбука або NAS діє всередині домашньої LAN. WAN-адресу отримує крайній домашній шлюз від пристрою чи мережі вище. Зовнішню IPv4 фіксує сервер в Інтернеті, коли приймає ваш запит. Щоб відрізнити локальну й зовнішню IP-адресу, запишіть усі три значення окремими рядками й не публікуйте повні адреси у форумі або скриншоті.
Переглядайте WAN тільки через локальну адмінпанель. Інструкція допоможе відкрити локальні налаштування роутера без увімкнення керування з Інтернету. Поле може називатися Internet, WAN, IPv4 status або connection address; шукайте саме адресу інтернет-інтерфейсу, а не gateway, DNS, LAN чи MAC.
Порівняння треба робити одночасно. Динамічна IPv4 може змінитися після reconnect, а браузер із корпоративним VPN або proxy покаже адресу виходу тунелю. Для чистого контролю вимкніть такий клієнтський тунель, оновіть сторінку визначення адреси й одразу перечитайте WAN. Якщо зовнішній сервіс повертає лише IPv6, оберіть явну перевірку IPv4 або зафіксуйте, що IPv4 не перевірена.
100.64/10 — shared, а не RFC 1918 private
RFC 1918 визначає три приватні IPv4-блоки: 10.0.0.0–10.255.255.255, 172.16.0.0–172.31.255.255 та 192.168.0.0–192.168.255.255. Якщо така адреса стоїть на WAN, перед вашим роутером є ще один адресний домен. У квартирі це часто ISP-модем у router mode; у гуртожитку або будинку — спільний gateway; інколи — операторська приватна мережа.
RFC 6598 окремо резервує 100.64.0.0–100.127.255.255 як Shared Address Space для операторських мереж. Його не слід називати четвертим приватним діапазоном RFC 1918. Коли домашній WAN належить 100.64/10, а зовнішній сервер бачить іншу IPv4, трансляція вище очевидна й типовим власником цієї межі є ISP. Домашня кнопка «відкрити порт» не створює mapping на операторському вузлі.
Адреса 192.0.2.x, яку іноді показують у прикладах, зарезервована для документації й не є реальною абонентською адресою. Так само 127.0.0.1 означає loopback, а 169.254/16 — link-local у разі відсутності звичайної конфігурації. Не робіть висновок «є public IP» за будь-яким значенням поза RFC 1918: спочатку класифікуйте його за актуальним реєстром і звірте зовні.
Double NAT удома та CGNAT можуть співіснувати
Уявіть ONT з адресою LAN 192.168.1.1 і власний роутер, WAN якого 192.168.1.20, а LAN — 192.168.50.0/24. Це локальний double NAT: обидві коробки доступні вам або оператору за договором, і для вхідного IPv4 потрібні узгоджені правила на обох. Чистіше залишити один router/NAT, а другий перевести у документований AP або bridge/pass-through режим, якщо послуга й модель це підтримують.
Якщо WAN першої керованої коробки вже 100.72.4.8, за нею може бути ще й CGN. Усунення домашнього double NAT спростить топологію, але не прибере операторську трансляцію. DMZ на першій домашній коробці лише пересилає невідповідний inbound до другої; вона не просвердлює mapping через CGN і не є захисною стратегією.
Контрольний тест без хибних позитивів
- Підтвердьте локальний сервіс. Відкрийте його з іншого пристрою в LAN за локальною адресою. Якщо він не слухає потрібний TCP/UDP-порт удома, CGNAT ще не є причиною.
- Запишіть топологію. Від цільового пристрою пройдіть кабелем або Wi-Fi до роутера, далі до ONT/модема. Біля кожної коробки позначте LAN, WAN і хто видає DHCP.
- Звірте WAN та зовнішню IPv4. Робіть це в одну сесію без стороннього VPN. Запишіть лише клас або замасковане значення.
- Створіть мінімальне правило. Вкажіть правильний внутрішній IP, транспорт і порт. Закріпіть адресу сервера DHCP reservation, щоб mapping не поїхав після перезавантаження.
- Тестуйте справді зовні. Вимкніть Wi-Fi на телефоні й використайте мобільну мережу. Сервіс має слухати під час перевірки; сканер не може відкрити вимкнений процес.
- Поверніть захист. Видаліть тимчасове правило, якщо воно не потрібне, і не залишайте exposed admin panel.
Перевірка з домашнього Wi-Fi за зовнішнім ім’ям може залежати від NAT hairpinning. Успіх іноді забезпечує vendor cloud relay, а не direct inbound; провал іноді спричиняє відсутність hairpin при справному доступі зовні. Саме тому камера перевіряється з mobile data, а в застосунку окремо з’ясовують тип з’єднання. Перед купівлею корисно перевірити мережеві вимоги IP-камери, включно з локальним записом і залежністю від акаунта.
Для TCP і UDP потрібні окремі результати. Вебсервер на TCP/443 нічого не доводить про UDP-порт гри, а статус NAT у консолі стискає кілька механізмів у одну маркетингову категорію. Фіксуйте transport, внутрішній endpoint, зовнішній порт, час тесту і джерельну мережу. Так журнал відрізнить CGN від помилки listener, firewall або адреси цільового хоста.
Селектор межі NAT та безпечної альтернативи
Модуль не сканує мережу й не надсилає введене. Він застосовує прозорі правила до семи спостережень. Варіант «не перевірено» навмисно веде до аудиту, а не до впевненої назви проблеми.
Де закінчується ваш контроль?
Виберіть альтернативу за завданням, а не за модним сервісом
Потрібне приватне адміністрування дому
Для доступу до панелі NAS, Home Assistant або робочого ПК не обов’язково публікувати їх у всьому Інтернеті. Overlay-рішення встановлює вихідні сесії від вузлів і створює приватну адресну площину з ключами та ACL. Щоб розібратися, як працює VPN-тунель, відокремте шифрування каналу від маршруту: self-hosted VPN-server за CGN сам потребує зовнішньо досяжного endpoint, тоді як mesh із relay може пережити недоступний direct path.
Компроміси overlay: залежність від control plane або relay, облікового запису, політики ключів і підтримки платформ. Перевірте, чи можна вимкнути relay, хто бачить metadata, як відкликається втрачений пристрій і чи є exit node взагалі потрібним. Не маршрутизуйте всю LAN, якщо достатньо одного сервера; принцип мінімальних привілеїв простіше перевірити.
Потрібен публічний сайт або webhook
Найпростіша традиційна схема — публічна IPv4 на вашому gateway, коректний mapping, firewall і захищений listener. Але availability, ціна, dynamic/static статус і блокування портів залежать від тарифу. Перед рішенням варто уточнити умови інтернет-провайдера: запитайте не «білу IP», а чи отримає CPE глобально маршрутизовану IPv4, чи вона виділена вам у сесії, чи дозволений inbound і чи змінюється адреса.
Reverse tunnel ініціює вихідне з’єднання з вашого origin до публічного посередника. Це обходить потребу в inbound mapping на CGN, але переносить довіру й частину доступності до tunnel provider або вашого VPS. Обмежте опублікований hostname, увімкніть TLS та сильну автентифікацію, оновлюйте origin і не вважайте приховану локальну адресу захистом.
Камера працює у застосунку, хоча порт закритий
Багато споживчих систем самі створюють вихідне з’єднання до vendor cloud і зводять клієнта через direct NAT traversal або relay. Це пояснює віддалене відео за CGNAT, але не доводить, що камера доступна напряму. Уточніть, чи запис зберігається локально, що станеться без хмари, як захищено акаунт і чи можна відкликати сесію.
Не відкривайте web-admin камери заради «економії на relay». Оновіть firmware, задайте унікальний пароль, увімкніть MFA у vendor account, якщо є, та ізолюйте недовірені домашні пристрої у придатному сегменті. Guest network іноді блокує доступ до локального recorder, тому політику перевіряють за потрібним потоком, а не лише за наявністю Інтернету.
Гра показує Strict NAT
Спершу визначте платформу, transport і чи використовує гра dedicated server або peer-to-peer. UPnP може створити mapping на домашньому gateway, а PCP — попросити mapping на сумісному upstream, проте жоден механізм не гарантує дозволу оператора. Не вмикайте DMZ для консолі як перший крок. Перевірте local double NAT, актуальність firmware і офіційні порти саме гри.
Навіть публічна IPv4 не обіцяє маркетингову категорію «Open», бо її визначають фільтрація, mapping behavior та тест платформи. Якщо relay забезпечує стабільну сесію, різниця може проявлятися лише в latency або можливості host migration. Збирайте фактичний симптом: хто не може приєднатися, у якому напрямку, за яким transport і чи повторюється з іншої мережі.
IPv6: прямі адреси без автоматично відкритих дверей
Глобальна IPv6 на сервері може дати end-to-end маршрут без IPv4 CGN. Перевірте не лише адресу роутера, а глобальну адресу цільового вузла, prefix delegation, default route і доступність IPv6 у зовнішнього клієнта. fc00::/7 є Unique Local, а fe80::/10 — link-local; жодна з них не свідчить про глобальну досяжність.
На IPv6 домашній firewall зазвичай блокує unsolicited inbound, навіть коли NAT немає. Створюйте вузьке правило до конкретного host, protocol і port. Якщо prefix динамічний, DNS automation має оновлювати AAAA без публікації зайвих адрес. Проведіть тест із мобільного оператора або іншої мережі з реальним IPv6; IPv4-only клієнт не підключиться без окремого перехідного сервісу.
Dual stack означає два незалежні шляхи. Справний IPv6 не виправляє IPv4-клієнта за CGN, а public IPv4 не гарантує IPv6. У журналі записуйте адресу, family, transport і hostname для кожної спроби. Інакше браузер може тихо вибрати інший протокол, і діагноз буде побудований на неправильній дорозі.
Public IP — це можливість маршруту, а не захист
CGN зменшує випадковий unsolicited inbound до абонентської IPv4, але не замінює firewall, оновлення, автентифікацію чи резервні копії. Шкідлива програма всередині може сама створити вихідний канал, а викрадений cloud account відкриє vendor relay без жодного port forwarding. Так само public IP не означає, що всі порти відкриті: stateful firewall має лишатися активним.
Публікуйте не адмінпанель роутера, а мінімально необхідний сервіс через VPN, application gateway або reverse proxy з TLS і MFA. Видаляйте default credentials, обмежуйте source network, ведіть журнал спроб і тестуйте відновлення. Для IoT корисне відокремлення від робочих пристроїв; однак segmentation не лікує вразливий зовнішній endpoint.
Зовнішній тест проводьте з контрольованого мобільного підключення, а не через випадкову точку доступу. Пояснення про те, чому не варто перевіряти адмінпанель через випадковий публічний Wi-Fi, стосується довіри до локального сегмента й ризику підміни. Навіть із HTTPS не вводьте router credentials на чужому пристрої.
Що написати підтримці ISP
Надішліть короткий відтворюваний запит: тариф і тип підключення; клас WAN без повної адреси; факт розбіжності із зовнішньою IPv4; потрібний protocol/port; наявність локального listener; бажання отримати public dynamic IPv4, static IPv4 або native IPv6. Запитайте про inbound filtering, зміну адреси, строки, оплату та сумісність із поточним CPE.
Не просіть «вимкнути NAT» без опису топології: оператор може запропонувати bridge для ONT, public address у PPPoE-сесії, окремий тариф або сказати, що опції немає. Зафіксуйте відповідь і дату, бо умови змінюються. Якщо підтримка дає public IPv4, повторіть одночасне порівняння й лише потім відновіть мінімальне port mapping.
Як читати результат онлайн-перевірки порту
Слово closed не називає одну конкретну причину. Відповідь могла дійти до host firewall і бути відхилена, mapping міг вести на іншу LAN-адресу, процес міг не слухати, а оператор — фільтрувати або взагалі не мати mapping для абонента. Timeout теж неоднозначний: деякі firewall мовчки відкидають пакет. Тому зберігайте разом зовнішній результат, локальний socket status, transport і правило NAT.
Тестовий webserver краще запускати на тимчасовому непривілейованому порту та на окремому пристрої без цінних даних. Спочатку доведіть LAN-доступ із другого клієнта, потім створіть одну вузьку трансляцію і проведіть одну зовнішню спробу. Не вимикайте firewall повністю й не призначайте DMZ «для чистоти експерименту»: так ви змінюєте одразу кілька змінних і відкриваєте зайві служби.
Після позитивного тесту перевірте, що відповідь надійшла саме від очікуваного застосунку. Збіг номера порту не гарантує правильний endpoint, особливо після зміни DHCP lease. Перегляньте журнал сервісу, джерельну адресу контрольного клієнта і TLS-сертифікат або host key. Потім замініть тимчасовий порт на проєктну конфігурацію й повторіть перевірку.
Для UDP звичайний «port checker» часто безсилий: протокол не має TCP handshake, а застосунок може відповідати лише на валідний payload. Використовуйте офіційний connection test програми або контрольний клієнт, який формує правильний запит. Відсутність відповіді на випадкову UDP-датаграму не доводить блокування, а одна успішна ігрова сесія через relay не доводить direct peer path.
Підсумок перевірки
Правильний порядок — listener у LAN, карта шлюзів, одночасні WAN/external IPv4, класифікація діапазону, тест з іншої мережі й тільки тоді вибір рішення. 100.64/10 із розбіжною зовнішньою адресою сильно вказує на CGN; RFC 1918 вимагає пошуку upstream; збіг global WAN та external переводить увагу на mapping і firewall.
Для приватного доступу віддавайте перевагу authenticated outbound overlay. Для справді публічного застосунку зіставте public-IP опцію, reverse tunnel та IPv6 за моделлю довіри й підтримкою клієнтів. Не плутайте DDNS із маршрутом: ім’я оновлює адресу, але не створює дозволений вхід через операторський NAT.