CGNAT (Carrier-Grade NAT, czasem określany jako Large Scale NAT) to mechanizm, w którym wielu klientów operatora internetowego współdzieli jeden publiczny adres IP. Zamiast dostać własny unikalny adres publiczny, otrzymujesz adres prywatny z puli operatora, a ruch na świat jest tłumaczony przez duży, centralny NAT w sieci dostawcy.
Dla zwykłego przeglądania stron, Netflixa czy YouTube’a CGNAT jest praktycznie niewidoczny. Problem pojawia się wtedy, gdy chcesz wystawić coś na zewnątrz: serwer gry, serwer WWW, FTP, własny VPN, kamerę IP, Home Assistant czy zdalny pulpit. CGNAT oznacza, że nie możesz bezpośrednio przekierować portów na swoim routerze do sieci Internet, bo router nie ma własnego publicznego IP – stoi za dodatkową warstwą translacji w sieci operatora.
Świadomość, czy Twój dostawca stosuje CGNAT, jest dzisiaj kluczowa. Decyduje o tym, czy zrobisz prosty port forwarding, czy będziesz musiał korzystać z obejść typu tunelowanie, VPN, serwisy pośredniczące lub dopłata do publicznego adresu IP. Dobrze też wiedzieć, jakie są realne ograniczenia portów w CGNAT – bo problemem nie jest tylko „brak przekierowania portu 80”, ale cała filozofia działania połączeń przychodzących i wychodzących.
CGNAT a klasyczny NAT domowy – zasadnicza różnica
W każdej typowej sieci domowej masz już NAT w routerze. Twój router dostaje od operatora jeden adres publiczny (np. 83.x.x.x), a w domu używasz adresów prywatnych (192.168.x.x, 10.x.x.x). Router tłumaczy ruch urządzeń domowych na jedno publiczne IP. Masz jednak kontrolę nad przekierowaniem portów: możesz wejść w panel routera i ustawić np. przekierowanie portu 22 na swój serwer SSH.
Przy CGNAT pojawia się druga warstwa NAT. Twój router już nie dostaje adresu publicznego, tylko prywatny z puli operatora, np. 100.64.x.x czy 10.x.x.x. Publiczny adres IP siedzi głęboko w sieci operatora na ich routerze brzegowym. Twój router robi NAT z 192.168.x.x na 100.64.x.x, a operator robi NAT z 100.64.x.x na 83.x.x.x. W tym układzie Twoje przekierowanie portów działa tylko do pierwszego NAT-u, a do Internetu i tak się nie przebije, bo NAT operatora go nie przepuści.
To właśnie tę różnicę trzeba wychwycić, gdy zastanawiasz się, czy dostawca stosuje CGNAT. Sam fakt, że masz „jakieś” prywatne IP w LAN, nic nie mówi – zawsze będziesz miał prywatne IP w LAN. Interesuje nas adres na interfejsie WAN routera oraz porównanie go z tym, co widzi Internet.
Dlaczego operatorzy tak chętnie wprowadzają CGNAT
Powód jest jeden, bardzo prozaiczny – brak wolnych adresów IPv4. Chociaż IPv6 istnieje od lat, to IPv4 nadal jest powszechnie używane, a przydział publicznych adresów jest ograniczony i drogi. Operatorzy, szczególnie mobilni i mniejsi ISP, stosują CGNAT, aby:
obsłużyć tysiące klientów za pomocą niewielkiej puli publicznych IP,
prościej zarządzać ruchem wychodzącym (mniej publicznych adresów do monitorowania),
Z perspektywy operatora CGNAT ma same zalety, dopóki klient nie potrzebuje stałego, publicznego IP z możliwością przekierowania portów. Wtedy zaczynają się rozmowy typu: „dopłata do publicznego IP”, „biznesowy plan z publicznym adresem”, „IPv4 tylko z CGNAT, IPv6 natywne”. Zrozumienie tego mechanizmu pozwala lepiej rozmawiać z BOK i od razu pytać o to, co realnie potrzebujesz.
Jak rozpoznać CGNAT po adresach IP krok po kroku
Sprawdzenie adresu IP na WAN routera
Pierwszy krok do wykrycia CGNAT to sprawdzenie, jaki adres IP dostaje Twój router na interfejsie WAN. W panelu zarządzania routerem szukaj informacji typu:
WAN IP, Internet IP, Address, IPv4 Address,
Network → Internet → Status,
Status → WAN.
Zwróć uwagę na liczby. Jeśli Twój router na WAN ma adres z jednego z poniższych zakresów, to to nie jest publiczny IP:
100.64.0.0 – 100.127.255.255 (tzw. Shared Address Space typowy właśnie dla CGNAT).
Jeśli widzisz tu jeden z tych zakresów, router nie ma publicznego IP. To jednak jeszcze nie oznacza automatycznie CGNAT – w niektórych konfiguracjach modem/ONT operatora robi NAT, a Twój router jest „za nim” w trybie zwykłego klienta. Dlatego trzeba zrobić drugi test – porównać ten adres z tym, co widzi Internet.
Porównanie IP z zewnątrz: co widzi Internet
Drugi krok to sprawdzenie, jaki adres IP widzą serwisy zewnętrzne. Można to zrobić w kilka sekund, korzystając z prostych narzędzi:
wejdź na stronę typu: https://ifconfig.me, https://api.ipify.org, https://whatismyipaddress.com,
lub użyj konsoli: curl ifconfig.me, curl https://api.ipify.org.
Adres, który zobaczysz, to publiczny adres widziany przez świat. Teraz porównaj go z adresem z interfejsu WAN routera:
Jeśli WAN routera = adres zewnętrzny – masz publiczny IP na routerze, CGNAT raczej nie występuje (przy klasycznych łączach domowych).
Jeśli WAN routera ≠ adres zewnętrzny i WAN jest z puli prywatnej lub 100.64.0.0/10 – istnieje druga warstwa NAT. To może być CGNAT lub NAT w modemie/urządzeniu operatora.
W praktyce, jeśli korzystasz z internetu mobilnego (LTE/5G) albo z radiówki, gdy WAN routera to 10.x.x.x lub 100.64.x.x, niemal na pewno masz CGNAT. Przy łączach kablowych/światłowodowych trzeba jeszcze sprawdzić, czy modem nie da się przełączyć w tryb bridge, ale z punktu widzenia portów efekt jest podobny: nie masz pełnej kontroli nad publicznym IP.
Rola przestrzeni 100.64.0.0/10 – charakterystyczny ślad CGNAT
Zakres 100.64.0.0 – 100.127.255.255 został oficjalnie zarezerwowany jako Shared Address Space właśnie do wykorzystania przez operatorów przy CGNAT. Jeśli WAN routera ma adres z tej puli, to sygnał bardzo wyraźny: jesteś w CGNAT lub w zbliżonej architekturze.
Wiele sieci mobilnych stosuje właśnie ten zakres dla interfejsów wewnętrznych. Dzięki temu łatwo odróżnić „zwykły” NAT w modemie (często 192.168.x.x) od prawdziwego CGNAT w sieci szkieletowej. Jeśli Twój operator wystawia te adresy w WAN routera lub w aplikacji do zarządzania kartą SIM, zakładanie przekierowania portów w domowym routerze nie rozwiąże problemu.
Źródło: Pexels | Autor: Pascal 📷
Testy praktyczne: jak samodzielnie upewnić się, że to CGNAT
Prosty test portów z zewnątrz
Teoretyczna analiza adresów to jedno, ale dobrze wykonać praktyczny test portów. Pozwala on potwierdzić, czy ruch przychodzący rzeczywiście ginie w sieci operatora. Procedura jest prosta:
Na komputerze w sieci domowej uruchom prosty serwer na konkretnym porcie (np. 12345). Można użyć:
python3 -m http.server 12345 (serwer HTTP na porcie 12345),
nc -lvp 12345 (netcat nasłuchujący na porcie 12345).
W routerze ustaw port forwarding z portu zewnętrznego 12345 na IP tego komputera i port 12345.
Sprawdź z innej sieci (np. dane komórkowe w telefonie) przy użyciu:
przeglądarki: http://TWÓJ_PUBLICZNY_IP:12345,
aplikacji do skanowania portów,
nc TWÓJ_PUBLICZNY_IP 12345 lub telnet TWÓJ_PUBLICZNY_IP 12345.
Wyniki można zinterpretować tak:
Jeżeli port się otwiera, widzisz stronę / nawiązuje się połączenie – masz realny dostęp z Internetu. CGNAT raczej nie występuje (lub operator zrobił dla Ciebie wyjątek, co jest rzadkością).
Jeżeli port jest zamknięty / filtrowany pomimo poprawnej konfiguracji forwarding’u – ruch jest ucinany wcześniej, najczęściej w NAT operatora (CGNAT) lub firewallu wyżej w sieci.
Przy CGNAT nawet idealnie ustawiony port forwarding nie zadziała, ponieważ pakiety z Internetu nie docierają do Twojego routera. NAT operatora nie wie, do którego z setek klientów korzystających z tego samego IP przekazać ruch na dany port. Z jego perspektywy to ryzyko, więc domyślnie blokuje takie połączenia przychodzące.
Śledzenie trasy (traceroute) i analiza pierwszych hopów
Drugim praktycznym narzędziem jest traceroute. Daje pogląd, jak wygląda początek trasy Twojego ruchu w sieci dostawcy. W zależności od systemu:
Windows: tracert 8.8.8.8,
Linux/macOS: traceroute 8.8.8.8.
Zwróć uwagę na pierwsze 2–3 hop-y. Typowo:
pierwszy hop – Twój router (np. 192.168.1.1),
drugi hop – pierwszy router operatora,
kolejne – dalsza infrastruktura operatora / tranzyt.
Jeśli drugi lub trzeci hop ma adres z zakresu 100.64.x.x lub 10.x.x.x, a Twój WAN jest w podobnej puli, to pojawia się mocny sygnał istnienia wewnętrznej sieci operatora z translacją adresów. To nie jest ostateczny dowód CGNAT, ale w połączeniu z brakiem publicznego IP na WAN i brakiem działania port-forwardingu wskazuje jednoznacznie na CGNAT.
Weryfikacja przy pomocy logów routera i narzędzi diagnostycznych
Wiele nowoczesnych routerów posiada zakładki diagnostyczne: Diagnostics, System Log, Security Log, Connections. Można z nich wyczytać, czy jakikolwiek ruch przychodzący z Internetu dociera do routera na port, który próbujesz wystawić.
Przykładowe kroki:
Włącz w routerze logowanie zdarzeń firewall/NAT.
Spróbuj nawiązać połączenie z zewnątrz na przekierowany port.
Sprawdź, czy w logach pojawia się wpis typu „INBOUND CONNECTION from X.X.X.X:YYYY to WAN_IP:12345”.
Jeżeli port jest skanowany z zewnątrz, a w logach brak jakiegokolwiek śladu, oznacza to, że pakiety są odrzucane zanim dotrą do routera – czyli na firewallu/NAT operatora. Przy braku CGNAT-u, nawet jeśli firewall routera odrzuci połączenie, powinien odnotować próbę połączenia.
Jak CGNAT wpływa na porty i połączenia przychodzące
Dlaczego pod CGNAT nie da się normalnie przekierować portów
W klasycznym scenariuszu z publicznym IP Twój router otrzymuje pakiety przychodzące na adres publiczny i konkretny port, np. 83.x.x.x:25565 dla serwera Minecraft. Na podstawie konfiguracji NAT wie, że ma przekazać je do 192.168.1.100:25565, więc połączenie działa. Router jest właścicielem tego publicznego IP – ma pełną kontrolę nad portami.
W architekturze CGNAT publiczny adres IP jest przypisany do routera operatora, a nie do Twojego. Przykładowo:
Twój router: 100.72.10.5 (WAN),
Router operatora: 83.21.55.10 (publiczny),
Twój serwer w LAN: 192.168.1.50.
Przykładowa ścieżka pakietu pod CGNAT
Dla ruchu przychodzącego wygląda to następująco:
Klient w Internecie łączy się z adresem publicznym operatora: 83.21.55.10:25565.
Router operatora ma własne reguły NAT i śledzi tylko połączenia wychodzące od klientów. Nie zna powiązania „83.21.55.10:25565 → 100.72.10.5:25565”, bo Ty tego nie ustawiasz – nie masz dostępu do jego konfiguracji.
Pakiet przychodzący 83.21.55.10:25565 jest traktowany jak „nieoczekiwany” i zwykle odrzucany na firewallu.
Twój router 100.72.10.5 nigdy tego pakietu nie zobaczy, więc lokalny forwarding do 192.168.1.50:25565 nie ma szans zadziałać.
Zadziałają natomiast połączenia wychodzące. Gdy serwer w LAN wyśle coś do Internetu, powstaje łańcuch:
192.168.1.50:55555 → 100.72.10.5:40000 (NAT w Twoim routerze),
Router operatora pamięta, że port 62000 na publicznym IP jest skojarzony z Twoją sesją. Odpowiedzi z Internetu wrócą więc tą samą trasą, ale tylko w ramach istniejącego połączenia wychodzącego. Nowe połączenia inicjowane z zewnątrz są blokowane.
Skutki CGNAT dla popularnych zastosowań
Blokada połączeń przychodzących najmocniej uderza w usługi, które wymagają „wejścia” z Internetu do Twojej sieci. W praktyce problemy pojawiają się przy:
hostowaniu serwerów gier (Minecraft, CS:GO, Valheim i inne) – znajomi nie połączą się bezpośrednio po IP i porcie,
dostępie zdalnym do NAS, mini-serwera w domu, Raspberry Pi,
zdalnym pulpicie (RDP, VNC) bez pośredników typu TeamViewer/AnyDesk,
kamerach IP wystawionych na świat bez chmury producenta,
VPN serwerach w domu (OpenVPN/WireGuard u Ciebie jako serwer),
serwerach www, mailowych, VoIP umieszczonych lokalnie.
W modelu CGNAT takie scenariusze działają tylko wtedy, gdy inicjator połączenia jest „od środka”, albo gdy użyjesz mechanizmów pośrednich (tuneli, chmur producenta, serwerów pośredniczących).
Co jeszcze może nie działać poprawnie pod CGNAT
Czasem problemy są mniej oczywiste i wychodzą dopiero w codziennym użytkowaniu:
P2P i gry z „matchmakingiem P2P” – część tytułów oczekuje, że gracze będą mogli łączyć się bezpośrednio. Bez portów bywasz zawsze hostem typu „NAT strict” i łączysz się tylko z określonymi partnerami lub przez serwery pośrednie.
VoIP i wideokonferencje – w czystym CGNAT potrafią przeskakiwać na tryb relay (cały ruch idzie przez serwery pośredniczące), co zwiększa opóźnienia.
Niektóre aplikacje P2P / sieci blockchain – węzeł, który nie może przyjmować połączeń, jest traktowany gorzej (mniejsza liczba peerów, wolniejsza synchronizacja).
Zwykłe przeglądanie stron, streaming wideo czy gry korzystające z serwerów dedykowanych zwykle będą działały bez istotnych różnic.
Jak żyć z CGNAT i jakie są obejścia
Poproszenie operatora o publiczny adres IP
Najbardziej bezpośrednie rozwiązanie to wyłączenie CGNAT dla Twojego łącza i przydzielenie indywidualnego publicznego adresu IP. W praktyce wygląda to różnie w zależności od dostawcy:
część operatorów stacjonarnych oferuje stały publiczny IP jako płatną usługę dodatkową,
niektórzy operatorzy mobilni umożliwiają przełączenie karty SIM w tryb z publicznym IP (czasem tylko w określonych taryfach),
są też firmy, które CGNAT stosują zawsze i nie przewidują żadnych wyjątków.
Rozmowa z BOK jest prostym testem: zapytaj, czy mogą przydzielić publiczny, routowalny adres IPv4 bez NAT-u po stronie operatora. Jeśli odpowiedź brzmi „nie da się”, trzeba szukać innych dróg.
Wykorzystanie IPv6 zamiast IPv4
Coraz więcej operatorów przydziela publiczne adresy IPv6 nawet wtedy, gdy IPv4 jest pod CGNAT. Dla portów to bardzo dobra wiadomość, bo:
IPv6 zwykle trafia bezpośrednio do Twojego routera lub nawet hosta,
nie ma translacji adresów na poziomie ISP (brak NAT w klasycznej formie),
otwarcie portów sprowadza się do odpowiedniego skonfigurowania firewall’a IPv6.
Praktyczny schemat:
Sprawdź w routerze, czy dostałeś prefix IPv6 (np. 2a00:xxx:yyy::/56).
Upewnij się, że urządzenia w LAN dostają swoje adresy IPv6 (SLAAC/DHCPv6).
Włącz w firewallu reguły zezwalające na ruch przychodzący do danego hosta i portu.
Łącz się z zewnątrz po adresie IPv6 lub nazwie domenowej z rekordem AAAA.
Ograniczeniem jest to, że nie wszyscy użytkownicy końcowi mają jeszcze IPv6 u siebie. Dla wielu zastosowań (np. własny serwer, VPN, dostęp dla administratora) jest to jednak w pełni wystarczające wyjście.
Tunelowanie przez zewnętrzny serwer (VPS)
Bardzo uniwersalne obejście CGNAT polega na tym, że inicjujesz połączenie z wnętrza swojej sieci do serwera z publicznym IP (np. VPS), a potem przychodzący ruch z Internetu jest przepychany tym tunelem do Ciebie. Kilka popularnych wariantów:
Reverse SSH – na serwerze VPS nasłuchuje port (np. 2222), a Twój komputer za CGNAT-em łączy się do VPS i zestawia tunel odwrotny,
VPN site-to-site – Twój router (lub Raspberry Pi) buduje stały tunel VPN (WireGuard/OpenVPN) do VPS i ruch z Internetu na portach VPS jest routowany przez tunel do sieci domowej,
narzędzia typu frp, wiretrustee, Tailscale, ZeroTier – dedykowane rozwiązania do tworzenia nakładkowych sieci, często prostsze w konfiguracji niż „czysty” VPN.
Schemat z VPS w praktyce:
Na VPS-ie konfigurujesz np. WireGuard i tworzysz interfejs wg0.
W domu router lub mały Linux łączy się jako klient WireGuard do VPS-a.
Na VPS-ie robisz port forwarding z publicznego IP (np. 203.0.113.10:25565) na adres tunelu Twojego urządzenia (np. 10.0.0.2:25565).
Serwer gry/HTTP działa w domu, ale z punktu widzenia znajomych jest dostępny pod IP VPS-a.
Zaletą takiego podejścia jest pełna kontrola nad portami na VPS-ie oraz niezależność od polityki CGNAT operatora. Minusem – dodatkowy koszt i odrobinę większe opóźnienia.
Rozwiązania chmurowe i pośrednicy producentów
Część usług „sama” radzi sobie z CGNAT, bo używa chmury jako „środka spotkania” dla obu stron. Typowe przykłady to:
kamery IP i rejestratory NVR z dostępem przez aplikację producenta,
oprogramowanie zdalnego pulpitu typu AnyDesk, RustDesk, Parsec,
niektóre gry i launchery, które tunelują ruch przez swoje serwery.
Technicznie oznacza to zwykle stałe połączenie wychodzące z Twojego urządzenia do serwera pośredniczącego. Druga strona też łączy się wychodząco, a serwer „spina” te dwa strumienie. Porty na Twoim IP nie muszą być otwarte, więc CGNAT nie stanowi przeszkody – kosztem zależności od chmury.
Źródło: Pexels | Autor: Pascal 📷
Jak zaplanować sieć domową pod CGNAT
Dobór routera i oprogramowania
Jeśli wiesz, że Twój operator stosuje CGNAT, router warto traktować jako punkt koncentracji tuneli, a nie tylko urządzenie do Wi-Fi. Przydają się funkcje:
obsługa klienta VPN (WireGuard/OpenVPN) z możliwością routowania całych podsieci,
możliwość zestawiania tuneli typu GRE, IPIP, WireGuard site-to-site,
dostęp do reguł routingu i firewall’a na tyle elastyczny, by można było przekierować ruch z tunelu do LAN.
W praktyce najwygodniej działa sprzęt z OpenWrt, alternatywnym firmware producenta (np. Asuswrt-Merlin) lub mały komputer typu x86/ARM z Linuxem pełniącym rolę routera. Proste „plastikowe” routery od operatora zwykle kończą się na podstawowym NAT i Wi-Fi.
Zmiana strategii wystawiania usług
Zamiast próbować „na siłę” otwierać porty na łączu z CGNAT, rozsądniej bywa przeprojektować sposób udostępniania usług. Praktyczne podejścia:
Serwery krytyczne umieścić w chmurze/VPS, a w domu trzymać tylko dane/backupy.
VPN jako punkt wejścia – zamiast wystawiać NAS, RDP i inne usługi bezpośrednio, wystawiasz tylko VPN na VPS-ie i po zalogowaniu się do VPN wszystko wygląda jak w sieci lokalnej.
Proxy odwrotne (reverse proxy) – na VPS-ie Nginx/Traefik przyjmuje ruch HTTPS, a później przekazuje przez tunel do serwera HTTP w domu.
Tak zorganizowana architektura jest zwykle nie tylko odporna na CGNAT, ale też bezpieczniejsza niż losowo otwierane porty w świat.
Monitorowanie stabilności połączeń pod CGNAT
Przy dużej liczbie użytkowników dzielących jedno publiczne IP operatora mogą pojawić się zjawiska nietypowe z punktu widzenia domowego użytkownika, np.:
limit liczby jednoczesnych sesji TCP/UDP na klienta,
agresywne wygaszanie „bezczynnych” połączeń,
różne ścieżki routingu w zależności od obciążenia węzłów CGNAT.
Jeśli korzystasz z tuneli VPN przez CGNAT, opłaca się obserwować:
czas życia połączeń (czy VPN nie zrywa się cyklicznie po kilkudziesięciu minutach bez ruchu),
statystyki pakietów i opóźnień (np. przy pomocy mtr, ping),
logi serwera VPN na VPS-ie – czy nie pojawiają się regularne przerwy.
Niekiedy pomaga utrzymywanie niewielkiego, stałego ruchu przez tunel (keepalive), aby NAT operatora nie „zapomniał” o istniejącym wpisie.
Na co zwracać uwagę wybierając dostawcę pod kątem portów
Pytania do zadania przed podpisaniem umowy
Jeżeli otwieranie portów jest dla Ciebie kluczowe, lepiej sprawdzić warunki zanim zwiążesz się umową. Podczas rozmowy z handlowcem czy BOK konkretnie zapytaj:
czy adres IPv4 jest publiczny i unikatowy, czy użytkownicy są za NAT operatora,
czy da się wykupić opcję publicznego/stałego IP, w jakiej cenie i w jakiej technologii (mobilna/stacjonarna),
czy blokowane są jakieś porty na poziomie sieci (np. 80, 443, 25, 21, 22),
czy oferują IPv6 i jaki prefix przydzielają klientowi.
Odpowiedzi w stylu „adres jest dynamiczny, ale publiczny – można robić przekierowania portów” zwykle oznaczają brak CGNAT (lub przynajmniej możliwość jego obejścia). Natomiast hasła typu „nie gwarantujemy dostępu z Internetu” są sygnałem ostrzegawczym.
Ocena istniejącego łącza po objawach
Jeśli usługę już masz, a podejrzewasz CGNAT, spojrzenie na kilka prostych elementów szybko rozjaśnia sytuację:
adres WAN w routerze – czy to jedna z puli prywatnych lub 100.64.0.0/10,
różnica między adresem WAN a adresem widocznym na stronach typu ifconfig.me,
brak reakcji routera na próby połączeń przychodzących (brak wpisów w logach),
problemy z hostowaniem gier, serwerów, VPN mimo poprawnej konfiguracji port forwarding.
Po potwierdzeniu CGNAT łatwiej zdecydować, czy zmieniasz operatora, czy budujesz rozwiązanie oparte o tunel do VPS lub IPv6.
Bezpieczeństwo a otwieranie portów przy CGNAT
CGNAT bywa postrzegany jako „przypadkowa ochrona”, bo połączenia przychodzące z Internetu po prostu do Ciebie nie dochodzą. Gdy zaczynasz go obchodzić (publiczny IPv4, tunel do VPS, IPv6), ekspozycja usług gwałtownie rośnie i trzeba być znacznie bardziej świadomym konfiguracji.
Kilka praktycznych zasad, jeśli zaczynasz samodzielnie udostępniać porty:
nie wystawiaj surowych usług administracyjnych (SSH, RDP, panele routerów) bezpośrednio na świat – lepiej zamknąć je w VPN,
zawsze wymuszaj szyfrowanie (HTTPS, TLS) – szczególnie jeśli ruch idzie przez VPS lub sieć publiczną,
ograniczaj adresy źródłowe, jeśli to możliwe (np. tylko własne biuro lub znane IP znajomych),
regularnie aktualizuj oprogramowanie wystawione na zewnątrz – serwer gry, NAS, panel www, firmware routera,
loguj i przeglądaj logi – masowe próby logowania i skanowania portów zaczną być codziennością.
Jedna zmiana u operatora (wykupienie publicznego IP) często wymusza przejście całej domowej infrastruktury na poziom ochrony zbliżony do małej firmy. Kto to zaniedba, bardzo szybko ogląda w logach próby logowania z całego świata.
Porty, które zwykle sprawiają kłopoty
Nie wszyscy dostawcy blokują to samo, ale pewne schematy powtarzają się na wielu łączach z CGNAT i bez niego. Przy diagnozie problemów z portami dobrze zacząć od sprawdzenia:
SMTP (25/tcp) – często blokowany wychodząco, by ograniczyć spam z sieci domowych,
HTTP/HTTPS (80/443/tcp) – czasem filtrowane lub przekierowywane w ofertach mobilnych,
porty „egzotyczne” używane przez gry/P2P – mogą być cięte priorytetowo przy dużym obciążeniu CGNAT.
Jeśli jakiś port ewidentnie „nie chce” działać, a inne działają poprawnie, opłaca się przetestować usługę na zupełnie innym numerze (np. HTTP na 8080, serwer gry na 25565 → 50000) i porównać zachowanie. Często już to pokazuje, czy winny jest firewall operatora czy Twoja konfiguracja.
Źródło: Pexels | Autor: Brett Sayles
Typowe scenariusze użytkownika i możliwe wyjścia z sytuacji
Hostowanie serwera gry dla znajomych
Przy serwerach gier problem z CGNAT wychodzi zwykle na jaw jako pierwszy: port forwarding w routerze ustawiony, firewall wyłączony, a znajomi i tak nie mogą się podłączyć. W takim przypadku opcje są w praktyce trzy:
serwer na VPS – instalujesz grę na serwerze z publicznym IP i łączysz się do niego tak samo jak znajomi,
tunel z domu do VPS – w domu działa serwer gry, ale port publiczny jest na VPS-ie (WireGuard + przekierowanie portów),
dedykowana usługa hostingowa – dla popularnych tytułów często wychodzi najwygodniej.
Jeśli zależy Ci na minimalnym opóźnieniu, serwer w domu z tunelem do bliskiego geograficznie VPS-a bywa zaskakująco skuteczny. Z kolei przy łączach mobilnych z wysokim jitterem stabilniejszy okazuje się całkowicie zewnętrzny serwer gry.
Przy dyskach sieciowych i self-hostowanych chmurach (Nextcloud, ownCloud, Syncthing) wygodnym wariantem jest:
postawić VPN na VPS-ie,
przyłączyć do niego NAS/domowy serwer i swoje urządzenia klienckie (laptop, telefon),
korzystać z NAS-a tak, jakby był w lokalnej sieci – bez publicznie otwartych portów do panelu i SMB/FTP.
W takiej konfiguracji ruch do wrażliwych usług nie wychodzi „na świat” w formie niezaszyfrowanej, a CGNAT staje się praktycznie niewidoczny. Zmienia się jedynie punkt wejścia – najpierw logujesz się do VPN, dopiero potem do NAS-a.
Zdalna administracja komputerem w domu
Jeżeli sporadycznie potrzebujesz „dostać się do pulpitu” w domu, rozwiązania pośredniczące (AnyDesk, RustDesk, Chrome Remote Desktop) zwykle w zupełności wystarczają. Porty są wtedy kwestią serwerów producenta.
Gdy wymagana jest pełna kontrola i brak zależności od chmury, sensowne są dwa modele:
pełny VPN – po połączeniu z VPN po prostu używasz RDP/VNC/SSH tak jak w lokalnej sieci,
reverse SSH – komputer domowy zestawia stałe połączenie SSH do VPS-a, a Ty łączysz się do własnego tunelu odwrotnego.
Drugi wariant jest szczególnie przydatny, jeśli nie chcesz lub nie możesz modyfikować konfiguracji routera (np. gdy masz tylko modem operatora LTE).
Zaawansowane techniki diagnozowania przy CGNAT
Testy portów z kilku lokalizacji
Jedno „sprawdzenie portu” w sieci znajomego nie zawsze mówi całą prawdę. Operator może stosować filtrację zależną od trasy czy kategorii ruchu. Solidniejszy test wygląda tak:
uruchamiasz na swoim hoście nasłuch na danym porcie (np. nc -l -p 50000 albo prosty serwer HTTP),
sprawdzasz port z co najmniej dwóch niezależnych lokalizacji (np. Internet stacjonarny + mobilny, serwer VPS w innej sieci),
obserwujesz logi i ruch w firewallu – czy jakiekolwiek pakiety docierają.
Brak śladów ruchu w logach routera przy poprawnej konfiguracji zwykle wskazuje na CGNAT lub filtrację wcześniej w sieci operatora. Jeśli zaś ruch widać, ale połączenie jest zrzucane – problem jest najpewniej w Twoim firewallu lub usłudze.
Analiza trasy i punktów NAT
Sam traceroute nie pokaże bezpośrednio NAT, ale pozwala ogólnie zorientować się, czy adres przypisany do Twojego routera w ogóle wychodzi w świat. Przydatne są trzy porównania:
traceroute 8.8.8.8 / tracert 8.8.8.8 z Twojej sieci,
traceroute do adresu, który pokazuje strona typu ifconfig.me,
traceroute z zewnętrznego serwera (np. VPS, Looking Glass) do tego samego publicznego IP.
Jeżeli na trasie z zewnątrz ostatnim hopem jest router operatora, a nigdy nie docierasz do swojego urządzenia, to znak, że ruch zatrzymuje się na obrzeżu CGNAT. W połączeniu z prywatnym adresem WAN w routerze stanowi to praktycznie stuprocentowe potwierdzenie sytuacji.
Monitoring zmian adresu publicznego
W sieciach z CGNAT publiczne IP potrafi zmieniać się częściej i w mniej przewidywalnych momentach niż przy klasycznym dynamicznym IP. Jeśli budujesz na tym tunele lub reguły bezpieczeństwa, przydaje się:
Dynamic DNS – niektóre narzędzia tunelujące same aktualizują rekordy DNS,
skrypty monitorujące – prosty cron, który co kilka minut sprawdza adres z zewnątrz i raportuje zmianę (np. mail/SMS/webhook),
konfiguracja po stronie VPS oparta raczej o klucze (WireGuard) niż twarde przypisanie do jednego IP.
Dzięki temu awaryjna zmiana adresu po stronie operatora nie unieruchamia automatycznie wszystkich usług.
Przyszłość: IPv4 pod CGNAT, IPv6 i zmieniające się podejście do portów
Jak CGNAT wpływa na ewolucję usług
Im więcej sieci przechodzi na CGNAT, tym mniej powszechny jest model „klient łączy się bezpośrednio na port serwera w domu”. Zamiast tego rośnie udział:
połączeń inicjowanych zawsze od środka do chmury (IoT, kamery, zdalny pulpit),
nakładkowych sieci VPN między urządzeniami (mesh VPN, SD-WAN),
architektur zero trust, w których porty nie są otwarte „na świat”, a dostęp wymaga autoryzacji aplikacyjnej.
Dla przeciętnego użytkownika oznacza to nieco mniej „klikania w routerze”, ale też większe uzależnienie od konkretnych usług chmurowych lub dostawców VPN. Dla osób chcących mieć wszystko „u siebie” – konieczność lepszego opanowania tuneli, DNS i zabezpieczeń.
Znaczenie IPv6 dla dostępu do portów
Przy powszechniejszym wdrożeniu IPv6 sytuacja z portami staje się prostsza technicznie, choć bardziej wymagająca organizacyjnie. Każde urządzenie może mieć swój globalny adres, co eliminuje problem przekierowań, ale też zabiera „tarczę” NAT.
Na poziomie praktyki można oczekiwać, że:
CGNAT dla IPv4 pozostanie jako „warstwa kompatybilności”,
otwieranie portów będzie się odbywało głównie przez reguły firewall’a IPv6,
role routerów domowych przesuną się z „pudełka od NAT-a” w kierunku pełnoprawnych zapór sieciowych.
Dobrze skonfigurowany firewall IPv6 jest wtedy kluczem: jedna pomyłka w regułach może odsłonić cały serwer do Internetu. Z drugiej strony rezygnujesz z kombinacji typu „double NAT + CGNAT”, które dziś potrafią skutecznie utrudnić nawet najprostszy port forwarding.
Najczęściej zadawane pytania (FAQ)
Jak sprawdzić, czy mój dostawca internetu korzysta z CGNAT?
Aby sprawdzić, czy jesteś za CGNAT, wykonaj dwa kroki: najpierw odczytaj adres IP na interfejsie WAN swojego routera (w panelu: Status → WAN, Internet IP, IPv4 Address itp.), a potem porównaj go z adresem widzianym z zewnątrz na stronie typu ifconfig.me lub whatismyipaddress.com.
Jeśli adres na WAN routera jest prywatny (10.x.x.x, 172.16–31.x.x, 192.168.x.x) lub z zakresu 100.64.0.0/10 i różni się od adresu widzianego przez Internet, oznacza to, że między Twoim routerem a Internetem istnieje dodatkowa warstwa NAT – bardzo często właśnie CGNAT.
Po czym poznać po samym adresie IP, że to CGNAT?
Najbardziej charakterystyczny dla CGNAT jest zakres 100.64.0.0 – 100.127.255.255 (tzw. Shared Address Space). Jeśli Twój router na interfejsie WAN ma IP zaczynające się np. od 100.72.x.x, 100.93.x.x itp., to niemal na pewno jesteś za CGNAT.
Silną poszlaką jest też sytuacja, gdy korzystasz z internetu mobilnego (LTE/5G) lub radiówki i na WAN otrzymujesz adres z puli 10.x.x.x. W połączeniu z innym, publicznym adresem widzianym w serwisach typu ifconfig.me oznacza to dodatkową translację adresów u operatora.
Jaka jest różnica między CGNAT a zwykłym NAT-em w routerze domowym?
Przy zwykłym NAT w domu Twój router ma własny publiczny adres IP od operatora, a tylko urządzenia w LAN (192.168.x.x, 10.x.x.x) są „ukryte” za NAT-em. Masz pełną kontrolę nad przekierowaniem portów – możesz wystawić serwer gry, www czy SSH, konfigurując port forwarding w routerze.
Przy CGNAT Twój router sam dostaje adres prywatny od operatora (np. 100.64.x.x lub 10.x.x.x), a publiczny IP znajduje się dopiero na urządzeniach w sieci operatora. To oznacza podwójny NAT: domowy + operatorski i brak możliwości samodzielnego wystawienia usług bezpośrednio do Internetu.
Czy przy CGNAT mogę przekierować porty i wystawić serwer w domu?
Standardowe przekierowanie portów na routerze nie zadziała w pełni, gdy jesteś za CGNAT. Przekierowanie dotrze tylko do pierwszego NAT-u (Twojego routera), ale nie „przebije się” przez drugą warstwę NAT po stronie operatora, więc świat zewnętrzny i tak nie połączy się z Twoim serwerem.
Aby wystawić usługi przy CGNAT, musisz zastosować inne rozwiązania, np. wykupić publiczny adres IP u operatora, użyć tunelowania (VPN do serwera z publicznym IP, np. VPS), skorzystać z serwisów pośredniczących (np. chmura dla kamer, zdalny dostęp producenta) lub przejść na IPv6, jeśli zarówno Ty, jak i klienci je obsługują.
Dlaczego operator stosuje CGNAT i czy mogę to wyłączyć?
Operatorzy wdrażają CGNAT głównie z powodu niedoboru adresów IPv4 – pozwala to obsłużyć tysiące klientów przy użyciu stosunkowo małej puli publicznych IP. Dodatkowym efektem jest domyślne „ukrycie” sieci domowej przed bezpośrednim dostępem z Internetu, co z ich perspektywy bywa sprzedawane jako „większe bezpieczeństwo”.
Użytkownik końcowy zazwyczaj nie może sam wyłączyć CGNAT. Często jednak można wykupić opcję publicznego adresu IPv4 (statycznego lub dynamicznego), przełączyć modem w tryb bridge lub skorzystać z planu „biznesowego” z publicznym IP – to wymaga kontaktu z BOK operatora i zwykle jest dodatkowo płatne.
Jak praktycznie przetestować, czy porty są blokowane przez CGNAT?
Uruchom w sieci domowej prosty serwer nasłuchujący na wybranym porcie (np. python3 -m http.server 12345 lub nc -lvp 12345), a następnie w routerze skonfiguruj przekierowanie portu z zewnątrz (np. 12345) na IP tego komputera. Potem spróbuj połączyć się z zewnątrz (np. z telefonu na danych komórkowych) na adres: TWÓJ_PUBLICZNY_IP:12345.
Jeśli mimo poprawnej konfiguracji port pozostaje zamknięty lub filtrowany, a do tego Twój WAN ma adres prywatny lub z zakresu 100.64.0.0/10, to bardzo silny sygnał, że ruch przychodzący „ginie” na CGNAT po stronie operatora i nie masz pełnego dostępu z Internetu.
Co warto zapamiętać
CGNAT oznacza współdzielenie jednego publicznego adresu IP przez wielu klientów, przez co Twój router dostaje jedynie adres prywatny z sieci operatora, a nie własny, unikalny publiczny adres.
Dla zwykłego korzystania z Internetu (przeglądanie www, Netflix, YouTube) CGNAT jest niewidoczny, ale uniemożliwia proste wystawianie własnych usług na zewnątrz (serwer gry, WWW, VPN, kamery IP, Home Assistant itp.).
Kluczowa różnica między domowym NAT a CGNAT polega na drugiej warstwie translacji – Twoje przekierowania portów działają tylko do routera domowego, ale nie przechodzą przez NAT operatora do Internetu.
Rozpoznanie CGNAT wymaga sprawdzenia adresu IP na interfejsie WAN routera oraz porównania go z adresem widzianym z zewnątrz; rozbieżność i prywatny/100.64.x.x na WAN wskazują na dodatkowy NAT.
Adresy WAN z zakresów 10.x.x.x, 172.16–31.x.x, 192.168.x.x lub 100.64.0.0–100.127.255.255 nie są publiczne, co oznacza brak bezpośredniej kontroli nad publicznym IP i potencjalnie obecność CGNAT.
Operatorzy stosują CGNAT głównie z powodu braku wolnych adresów IPv4 – pozwala im obsłużyć wielu klientów mniejszą pulą IP i uprościć zarządzanie, kosztem elastyczności po stronie użytkownika.
Świadomość użycia CGNAT jest ważna, bo determinuje, czy wystarczy zwykły port forwarding, czy konieczne będzie tunelowanie, VPN, usługi pośredniczące lub dopłata do dedykowanego publicznego adresu IP.
