Przekierowanie portu w routerze jest skonfigurowane poprawnie, urządzenie odpowiada w sieci lokalnej, a mimo to połączenie z internetu kończy się błędem. Przykładowo reguła TCP 8443 → 192.168.1.50:443 kieruje ruch do domowego serwera WWW, ale próba połączenia przez sieć komórkową kończy się przekroczeniem czasu oczekiwania. Problem nie musi leżeć w konfiguracji routera. Coraz częściej przyczyną jest CGNAT (Carrier-Grade NAT), czyli mechanizm współdzielenia publicznych adresów IPv4 przez wielu abonentów operatora. W takiej sieci standardowe przekierowanie portów nie wystarczy, ponieważ połączenie przychodzące zostaje zatrzymane, zanim dotrze do domowego routera. Są jednak sposoby na uzyskanie zdalnego dostępu bez zmiany dostawcy internetu.
Jak działa CGNAT i czym różni się od NAT w routerze
Zwykły NAT (Network Address Translation) pozwala kilku urządzeniom korzystać z jednego publicznego adresu IPv4. Komputer może mieć adres 192.168.1.10, telefon 192.168.1.20, a serwer 192.168.1.50. Router zapisuje informacje o połączeniach wychodzących i tłumaczy prywatne adresy oraz porty na adres i porty używane po stronie internetu. Dzięki temu odpowiedzi trafiają do właściwych urządzeń.
Problem zaczyna się przy połączeniach inicjowanych z zewnątrz. Router nie wie, do którego urządzenia skierować nowy ruch, dopóki administrator nie zdefiniuje reguły port forwarding. Przykładowo przekierowanie zewnętrznego portu TCP 8443 na port 443 serwera 192.168.1.50 pozwala kierować żądania HTTPS do tego komputera, pod warunkiem że router jest osiągalny pod publicznym IPv4, usługa nasłuchuje, a zapory zezwalają na połączenie.
CGNAT dokłada kolejną warstwę translacji, tym razem w sieci operatora. Dostawca może przydzielić domowemu routerowi adres 100.86.12.4, a ruch do internetu przesyłać przez wspólny publiczny IPv4 używany przez wielu klientów. Operator rozróżnia ich połączenia między innymi za pomocą numerów portów i własnych tablic translacji.
W praktyce oznacza to trzy rzeczy:
- Połączenia wychodzące, takie jak przeglądanie stron, oglądanie filmów czy pobieranie plików, zazwyczaj działają normalnie.
- Nowe połączenie przychodzące z internetu nie ma automatycznie przypisanej drogi do konkretnego abonenta.
- Przekierowanie ustawione wyłącznie na własnym routerze nie zmienia konfiguracji CGNAT u dostawcy.
Dobrym przykładem jest własny serwer gry. Administrator otwiera wymagany port UDP w routerze TP-Link lub ASUS, dodaje wyjątek w zaporze komputera i uruchamia serwer. Gracze z tej samej sieci LAN mogą się połączyć, ale użytkownicy spoza domu już nie. Jeśli ruch przychodzący nie przechodzi przez CGNAT operatora, zmiana numeru portu czy ponowne uruchomienie routera nie rozwiąże problemu.
Dostawcy stosują CGNAT, ponieważ liczba dostępnych publicznych adresów IPv4 jest ograniczona. Do obsługi współdzielonej przestrzeni adresowej przeznaczono blok 100.64.0.0/10, obejmujący adresy od 100.64.0.0 do 100.127.255.255. Został on zdefiniowany w RFC 6598.
Nie należy jednak utożsamiać każdego podwójnego NAT-u z CGNAT. Jeżeli własny router działa za drugim routerem w mieszkaniu, dodatkową translację można często usunąć samodzielnie. W przypadku urządzenia operatora nie zawsze mamy taką możliwość. Niektórzy dostawcy oferują mapowanie portów także w swojej sieci, ale wymaga to obsługi odpowiedniego mechanizmu po ich stronie. Standardowa reguła UPnP na domowym routerze tego nie załatwi.
Jak sprawdzić, czy operator stosuje CGNAT
Najbardziej użyteczny test polega na porównaniu adresu IPv4 interfejsu WAN routera z publicznym adresem IPv4 widocznym dla serwerów w internecie. Trzeba jednak prawidłowo zinterpretować wynik. Sama różnica adresów nie dowodzi jeszcze, że operator stosuje CGNAT.
Diagnostykę najlepiej przeprowadzić w następującej kolejności:
- Sprawdź działanie usługi w LAN. Połącz się z serwerem z innego urządzenia w domu, używając jego lokalnego adresu i odpowiedniego portu. Upewnij się, że adres urządzenia jest aktualny, a aplikacja nie nasłuchuje wyłącznie na 127.0.0.1. Dla serwera korzystającego z DHCP najlepiej skonfigurować rezerwację adresu w routerze.
- Odczytaj adres WAN IPv4. Zaloguj się do routera i znajdź sekcję Internet, WAN lub Status. Na komputerze z Windows polecenie
ipconfigpokaże między innymi adres bramy domyślnej, który pomoże znaleźć router, ale nie zastąpi odczytu jego adresu WAN. - Sprawdź publiczny IPv4. Na urządzeniu korzystającym z tego samego łącza otwórz serwis pokazujący publiczny adres IPv4. Jeśli korzystasz z VPN lub serwera proxy, wyłącz je na czas porównania, ponieważ mogą zmienić obserwowany adres.
- Porównaj oba adresy i sprawdź, gdzie znajduje się translacja. Jeżeli router otrzymał adres z zakresu 100.64.0.0/10, jest to silny sygnał wykorzystania przestrzeni przeznaczonej dla CGNAT. Jeżeli widzi adres prywatny, trzeba jeszcze ustalić, czy pochodzi on od własnego routera nadrzędnego, czy od operatora.
Adresy prywatne zdefiniowane w RFC 1918 obejmują:
10.0.0.0 – 10.255.255.255172.16.0.0 – 172.31.255.255192.168.0.0 – 192.168.255.255
Załóżmy, że modem operatora ma adres LAN 192.168.1.1, a własny router otrzymał na porcie WAN adres 192.168.1.2. To typowy scenariusz podwójnego NAT-u w lokalnej instalacji. Jeśli modem ma publiczny IPv4, rozwiązaniem może być przełączenie go w tryb bridge albo skonfigurowanie przekierowania na obu routerach. Bridge nie zawsze jest dostępny i wymaga sprawdzenia zgodności z usługą operatora.
Jeśli jednak sam modem również nie posiada publicznego IPv4, usunięcie jednej lokalnej warstwy NAT nie wystarczy. Wtedy trzeba zweryfikować konfigurację i warunki usługi u dostawcy.
Zgodność publicznego IPv4 z adresem WAN również nie oznacza automatycznie otwartego portu. Przyczyną problemu może być zapora systemowa, blokada ruchu przychodzącego u operatora, błędny protokół TCP/UDP albo aplikacja, która w ogóle nie nasłuchuje na wybranym porcie.
Do dodatkowego sprawdzenia połączenia TCP na Windows można użyć PowerShella:
Test-NetConnection -ComputerName ADRES_PUBLICZNY -Port 8443
Zamiast ADRES_PUBLICZNY należy wpisać rzeczywisty adres IPv4. Test wykonuje się z komputera podłączonego do innej sieci, gdy docelowa usługa jest uruchomiona. Wynik TcpTestSucceeded: True potwierdza możliwość zestawienia połączenia TCP. Wynik negatywny nie wskazuje samodzielnie przyczyny awarii. Polecenie nie testuje też portów UDP.
Można również spróbować połączenia z telefonu przez LTE lub 5G po wyłączeniu Wi-Fi. Testowanie własnego publicznego adresu z sieci domowej bywa mylące, ponieważ zależy od obsługi NAT loopback (hairpin NAT) w routerze.
Dopiero po tych sprawdzeniach warto kontaktować się z operatorem. Konkretne pytanie powinno brzmieć: czy moja usługa korzysta z CGNAT lub innej współdzielonej translacji IPv4 i czy mogę otrzymać publiczny adres IPv4 umożliwiający połączenia przychodzące? To znacznie bardziej precyzyjne niż zgłaszanie samego niedziałającego przekierowania portów.
Publiczny adres IP, IPv6, tunel VPN i inne możliwe rozwiązania
Wybór metody zależy przede wszystkim od tego, kto ma łączyć się z urządzeniem i jakiego protokołu potrzebuje. Prywatny dostęp właściciela do NAS-a to inne zadanie niż serwer gry obsługujący nieznanych użytkowników.
1. Publiczny adres IPv4 od operatora – najlepszy wybór dla klasycznego przekierowania portów
Najprostsza droga to zamówienie publicznego IPv4, o ile operator udostępnia taką usługę w danej taryfie. Adres nie musi być stały. Dynamiczny publiczny IPv4 również pozwala na połączenia przychodzące, jeśli dostawca ich nie blokuje.
Przykładem polskiego rynku jest oferta publicznego IP w wybranych taryfach mobilnych Play. Opłaty wynoszą 6,15 zł brutto miesięcznie za dynamiczny IPv4 oraz 18,45 zł brutto za stały IPv4. Po aktywacji usługi operator wymaga ustawienia APN ipnet. Możliwość skorzystania z niej zależy od taryfy.
Adres dynamiczny wystarcza do domowego serwera, jeśli zmiana numeru IP nie stanowi problemu. Można wtedy skonfigurować DDNS (Dynamic DNS), który aktualizuje nazwę domenową po zmianie adresu publicznego. Stały IPv4 ma większy sens, gdy zewnętrzne systemy wymagają wpisania adresu na listę dozwolonych albo infrastruktura zależy od niezmiennego punktu dostępu.
DDNS nie omija CGNAT. Aktualizuje jedynie rekord DNS. Nie tworzy drogi dla pakietów, które operator blokuje lub których nie kieruje do abonenta.
Publiczny adres jest praktyczny w przypadku serwera gry czy usługi wymagającej bezpośredniego dostępu z internetu. Trzeba jednak zabezpieczyć urządzenie, ograniczyć otwierane porty i aktualizować oprogramowanie. Nie należy bezpośrednio udostępniać internetu panelom administracyjnym routerów i NAS-ów ani usłudze RDP. Do zdalnego zarządzania lepszym punktem wejścia jest VPN.
2. IPv6 – dostęp bez klasycznego przekierowania NAT
Jeśli dostawca udostępnia globalnie routowalne adresy IPv6, urządzenie w sieci domowej może mieć własny adres osiągalny z internetu. Nie potrzebuje wówczas przekierowania NAT znanego z IPv4.
Przykładowo serwer WireGuard działający na komputerze z globalnym IPv6 może przyjmować połączenia na porcie UDP 51820. Należy dopuścić ten ruch w zaporze routera IPv6 oraz w zaporze samego komputera. To reguła filtrowania ruchu, a nie translacja adresu.
Rozwiązanie ma kilka warunków:
- Urządzenie docelowe musi mieć globalny adres IPv6, a nie tylko adres lokalny
fe80::czy prywatnyfd00::. - Sieć, z której następuje połączenie, również musi obsługiwać IPv6.
- Zapora powinna przepuszczać wyłącznie wymagany ruch do konkretnego urządzenia.
- Jeśli adres IPv6 lub prefiks od operatora się zmienia, trzeba aktualizować rekord AAAA w DNS albo zapewnić inny sposób odnajdywania serwera.
Istotna jest też konfiguracja ICMPv6. Blokowanie całego tego protokołu może zakłócić działanie IPv6, w tym mechanizmy wykrywania problemów z rozmiarem pakietów.
IPv6 sprawdza się szczególnie wtedy, gdy obie strony mają jego pełną obsługę. Jeśli klient korzysta wyłącznie z IPv4, samo posiadanie globalnego IPv6 w domu nie zapewni mu dostępu.
3. Tailscale i sieć overlay – wygodny dostęp do własnych urządzeń
Dla osoby, która chce połączyć się z domowym komputerem, NAS-em albo systemem monitoringu, często rozsądniejsze jest utworzenie prywatnej sieci overlay zamiast udostępniania usługi publicznie.
Tailscale wykorzystuje szyfrowane połączenia oparte na WireGuard oraz techniki przechodzenia przez NAT. Jeśli bezpośrednie połączenie nie jest możliwe, komunikacja może przebiegać przez serwery pośredniczące. Dzięki temu nie trzeba samodzielnie otwierać portu w routerze.
W najprostszym wariancie instaluje się Tailscale na komputerze domowym i telefonie, a następnie dodaje oba urządzenia do tej samej prywatnej sieci. Po zestawieniu połączenia można korzystać z usług komputera przez jego adres w sieci Tailscale.
Co zrobić z kamerą IP lub drukarką, które nie obsługują Tailscale? Można uruchomić subnet router na stale działającym urządzeniu, np. Raspberry Pi. Dla sieci domowej 192.168.1.0/24, po włączeniu przekazywania pakietów IP w Linuksie, trasę można ogłosić poleceniem:
sudo tailscale set --advertise-routes=192.168.1.0/24
Następnie trzeba zatwierdzić trasę w panelu administracyjnym Tailscale i upewnić się, że urządzenie zdalne z niej korzysta. Wtedy możliwy jest dostęp na przykład do kamery pod adresem 192.168.1.50 bez instalowania klienta VPN na samej kamerze. Dostęp do podsieci należy dodatkowo ograniczyć odpowiednimi regułami uprawnień.
Plan Tailscale Personal kosztuje 0 zł i obejmuje do sześciu użytkowników w zastosowaniach prywatnych, niekomercyjnych.
Największa wada ujawnia się przy przesyłaniu dużej ilości danych. Połączenie przez serwer pośredniczący może mieć większe opóźnienie i niższą przepustowość niż połączenie bezpośrednie. Dodatkowo urządzenie pełniące rolę bramy do sieci domowej musi pozostawać włączone. Do okazjonalnego zarządzania serwerem to zwykle niewielki problem, ale przy wielu strumieniach wideo różnica może być odczuwalna.
4. Cloudflare Tunnel albo własny VPS – gdy usługa ma być osiągalna spoza prywatnej sieci
Jeśli trzeba udostępnić aplikację WWW bez publicznego IPv4, można użyć Cloudflare Tunnel. Program cloudflared ustanawia połączenie wychodzące do infrastruktury Cloudflare, a żądania użytkowników są przekazywane tunelem do lokalnej aplikacji.
Przykładowo panel własnej aplikacji internetowej działający na porcie 8080 można opublikować pod domeną i zabezpieczyć mechanizmem Cloudflare Access. Użytkownik otwiera adres HTTPS, a lokalny router nie wymaga przekierowania portu. Publiczna publikacja bez odpowiedniej polityki dostępu oznacza jednak, że aplikacja będzie widoczna dla nieuprawnionych użytkowników.
Cloudflare Tunnel nie jest uniwersalnym zamiennikiem dowolnego publicznego portu TCP lub UDP. Standardowy dostęp do aplikacji HTTP różni się od udostępniania niestandardowych protokołów. Inne tryby wymagają dodatkowego klienta, odpowiedniej konfiguracji sieci lub odrębnych usług.
Gdy potrzebna jest większa kontrola, można wynająć VPS z publicznym IPv4 i zestawić tunel WireGuard pomiędzy serwerem VPS a urządzeniem w domu. Połączenie inicjuje strona domowa, dlatego CGNAT nie musi przyjmować nowego połączenia z internetu.
Na VPS konfiguruje się odpowiednie przekazywanie ruchu lub reverse proxy. Dla WireGuard za NAT przydatny bywa parametr PersistentKeepalive = 25, który powoduje wysyłanie pakietów podtrzymujących co 25 sekund, aby utrzymać odpowiednie mapowanie NAT.
Takie rozwiązanie może obsłużyć również usługi wymagające specyficznych portów, o ile prawidłowo skonfigurowano routing, translację, zapory i reguły dostawcy VPS. Nie jest to jednak wariant bezobsługowy. Dochodzą opłaty za serwer, jego zabezpieczenie, aktualizacje i diagnozowanie problemów z trasowaniem. Przepustowość połączenia do domowego urządzenia nadal ogranicza między innymi upload domowego łącza.
Trzeba też odróżnić taki tunel od zwykłej usługi VPN do przeglądania internetu. Komercyjny VPN obsługujący wyłącznie połączenia wychodzące nie zapewnia automatycznie możliwości otwierania portów przychodzących. Dostawca musiałby udostępniać taką funkcję.
FAQ – najczęstsze pytania o CGNAT
Czy CGNAT można wyłączyć w ustawieniach routera?
Nie. CGNAT działa po stronie operatora, więc zmiana ustawień domowego NAT-u go nie wyłączy. Należy zapytać dostawcę o publiczny IPv4, mapowanie portów albo skorzystać z odpowiedniego tunelu.
Czy DDNS rozwiązuje problem przekierowania portów przy CGNAT?
Nie. DDNS przypisuje nazwę domenową do zmieniającego się adresu IP. Nie otwiera portów ani nie usuwa dodatkowej translacji w sieci dostawcy.
Czy do przekierowania portów potrzebny jest stały publiczny IP?
Nie. Dynamiczny publiczny IPv4 wystarcza, jeśli połączenia przychodzące są dozwolone. DDNS pomaga odnaleźć serwer po zmianie adresu.
Czy IPv6 pozwala ominąć ograniczenia CGNAT?
Tak, dla połączeń IPv6, jeżeli urządzenie ma globalny adres, sieć klienta obsługuje IPv6, a zapory dopuszczają wymagany ruch. Nie oznacza to jednak automatycznego udostępnienia urządzenia klientom korzystającym wyłącznie z IPv4.
Co sprawdzić jako pierwsze, gdy przekierowanie portu nie działa?
Najpierw potwierdź działanie usługi w LAN, potem odczytaj WAN IPv4 routera i porównaj go z publicznym IPv4 widocznym w internecie. Jeśli WAN należy do zakresu 100.64.0.0/10, w pierwszej kolejności sprawdź u operatora możliwość uzyskania publicznego adresu. Jeśli adres WAN pochodzi z prywatnej sieci drugiego domowego routera, zweryfikuj jego konfigurację. Nie zmieniaj kolejnych reguł przekierowania, dopóki nie ustalisz, gdzie zatrzymuje się ruch.
