Какво е CGNAT? Защо Port Forwarding не работи и как да го заобиколите

Когато правилното пренасочване на портове все още не работи

Вашият NAS се отваря нормално у дома. Услугата работи, а правилото за пренасочване на портове сочи към правилния локален адрес. След това превключвате телефона си на мобилни данни, опитвате отново и получавате timeout. Същият модел може да засегне домашен игрален сървър, VPN сървър, CCTV поток или самостоятелно хостирано приложение.

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

Това не доказва, че CGNAT е отговорен; локалните проблеми могат да изглеждат идентични. Услугата може да слуша само на localhost, или хост firewall може да я блокира. Правило на маршрутизатора може да използва неправилния 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 срещу Double NAT срещу CGNAT

Решаващите въпроси не са “Колко кутии виждам?” а “Където се случва превода и кой може да го промени?”

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

Това разграничение на собствеността променя какво можете да поправите. С два локални шлюза, може да използвате bridge/AP режим или да конфигурирате и двата слоя. Преводач на доставчик се намира извън тези контроли, и някои CGNAT дизайни изобщо не включват втори управляван от клиента преводач.

Етикетите на конзолата като “отворен”, “умерен” или “строг” NAT са отделни. Те обобщават поведението на свързаност за тази платформа; те не идентифицират кой притежава преводачите или доказват, че CGNAT съществува.

Защо Port Forwarding Не Работи Зад CGNAT

Изходящият трафик работи, защото всеки преводач създава състояние: временен запис, който свързва вътрешен поток с външен адрес и порт. Когато вашето устройство стартира заявка, домашният маршрутизатор и ISP CGN всеки го записват, позволявайки съответните отговори да се върнат.

Ново входящо свързване няма такова състояние. То достига до ISP-ския споделен публичен IPv4 първо, където 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 система или вътрешна таблица с управление. Публичните уебсайтове, приемници на webhook и игрови сървъри се сблъскват със същото изискване за входящ трафик. VPN клиент обикновено работи, защото се свързва навън. Домашен VPN сървър е различен, защото отдалечени потребители инициират връзката, така че има нужда от достъпен входящ трафик, съвместим IPv6 или крайна точка на релей или публичен хост.

Peer-to-peer игрите, гласът и споделянето на файлове са по-малко предсказуеми. Някои приложения намират преки маршрути, докато други използват релей чрез достъпен посредник. Релеят може да запази свързаността за сметка на добавена латентност. Когато преминаването не успее, приложението може да докладва рестриктивен NAT или да не успее да се свърже. RFC 7021 документира тези критични точки без да предполага универсален отказ.

Споделянето на IPv4 адрес може да обедини несвързани абонати в една репутация. Поведението на един потребител може да причини други абонати да видят повече CAPTCHA или ограничения на честотата. Споделеният адрес може също да попадне на черни списъци, да активира ограничения на едновременното влизане или да произведе груба геолокация. Споделен или променящ се жилищен изход допълнително усложнява бизнес разрешителни списъци, които очакват стабилна крайна точка.

📝 Забележка: Блокирането на нежелан входящ IPv4 по подразбиране може да намали случайното разкриване, но CGNAT не е защитна стена и не замества удостоверяване, актуализации, TLS или политика на достъп.

CGNAT не спира злонамерен изходящ трафик. Не осигурява приложения, разкрити чрез друг път, и не контролира кой може да влезе. Тунел, публичен IP или IPv6 маршрут все още изискват преднамерени контроли на сигурността.

Пет начина за работа с CGNAT

Петте опции решават различни проблеми с достъпа. Частни мрежи, управлявани тунели и VPS релета споделят един полезен модел: частната страна се свързва първо.

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

В аналогията на сградата, вие или получавате използваем входен адрес на улица, или поддържате линия към входен адрес другаде.

📝 Забележка: “Заобикаляне” е съкращение. Тези подходи не деактивират NAT на оператора; те получават друг публичен край, използват end-to-end IPv6 или установяват път, създаден чрез изходящо свързване.

Начнете с таблицата, след това използвайте детайлите по-долу за компромисите, които имат значение за вашата конфигурация.

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

За общ входящ IPv4, това обикновено е най-простата опция, когато ISP я предлага. Динамичен публичен IPv4 работи с актуализирана DNS. Изберете статичен публичен IPv4 за стабилни списъци с разрешения, записи или VPN краища. Проверете наличността и цената и защитете всяка услуга, която експозирате директно.

2. Използвайте нативен IPv6

IPv6 трафикът избягва IPv4 CGNAT. Преките достъп изисква глобален префикс, IPv6 слушател, подходящи правила на защитната стена, правилна DNS, където е необходимо, и IPv6 на отдалечената страна. Това не помага на IPv4-само клиентите или не експозира услуга автоматично.

3. Изградете частна мрежа

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, когато потребителите могат да инсталират клиентски софтуер. За публични уеб крайни точки и webhooks, използвайте управляван тунел или публично хостване. Преместете работното натоварване, ако не се нуждае от домашната LAN.

За публичен TCP/UDP, използвайте публичен IPv4 от ISP, VPS edge или IPv6, когато всички клиенти го поддържат. Хостването на игри е специфично за всяка игра: проверете нейния модел на сървър, поддръжката на traversal и протоколите. Генеричен тунел не може да гарантира по-добър етикет на конзолния NAT.

Публична VPN крайна точка се нуждае от публичен IPv4, работещ IPv6 или VPS хост. За бизнес входящ трафик или списъци за разрешаване на партньори, изберете статичен адрес или контролиран шлюз вместо споделен жилищен изход.

Често задавани въпроси и неправилни представи за CGNAT

CGNAT е ли същото като double NAT? Не. CGNAT идентифицира ISP-управляван, многоабонатен NAT. Double NAT означава само, че трафикът преминава през два преводача.

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

Може ли динамичен DNS да реши CGNAT? Не. Той проследява променящ се адрес, но не може да създаде upstream mapping. Помага, когато вече имате достъпен динамичен публичен адрес.

Обикновен VPN ли заобиколя CGNAT? Обикновено не. Работи само когато VPN услугата предоставя inbound forwarding, частна overlay или друга достъпна входна точка.

Може ли IPv6 да го реши? Да, когато и двата края имат IPv6 и firewall-ът и DNS позволяват това. Не помага на IPv4-only клиентите.

Е ли 100.64.0.0/10 частно пространство? То е специално-предназначено, неглобално маршрутизируемо Shared Address Space. Различно е от RFC 1918 частните диапазони, използвани в обикновени локални мрежи.

CGNAT е ли функция за сигурност? Не. Неговото inbound поведение не е политика за сигурност. Все още имате нужда от firewall правила, удостоверяване, пачове, криптиране и внимателна експозиция.

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

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