W ustawieniach routera widzisz adres z zakresu 100.64.x.x albo 10.x, a próba przekierowania portu kończy się niczym. Prawdopodobnie nie masz publicznego adresu IPv4, tylko dzielisz go z innymi klientami dostawcy. To CGNAT, carrier-grade NAT, czyli tłumaczenie adresów po stronie operatora. Mechanizm jest prosty, ale jego skutki bywają zaskakujące.
Dwa NAT-y zamiast jednego
W domowej sieci NAT wykonuje router: urządzenia dostają adresy prywatne, a router zamienia je na jeden adres publiczny, przypisując każdemu połączeniu osobny port. CGNAT robi to samo, tylko o poziom wyżej. Abonent otrzymuje adres prywatny lub adres ze specjalnego zakresu współdzielonego, a urządzenie operatora zamienia go na publiczny adres i port, z którego korzysta wielu klientów jednocześnie.
Do tego celu IANA zarezerwowała w 2012 roku zakres 100.64.0.0/10, opisany w RFC 6598. To nie jest prywatny zakres z RFC 1918, bo adresy te są używane w sieci dostawcy, a nie w sieci domowej, ale zasada jest podobna: na zewnątrz nie są widoczne. Dokument zastrzega, że pakietów z tego zakresu nie należy trasować w publicznym internecie. [1]
Wymagania dla takich urządzeń zebrano w RFC 6888 z 2013 roku, określanym jako BCP 127. Dokument opisuje między innymi sposób przydzielania portów, limity na abonenta i obowiązek prowadzenia logów. Bez logów nie da się ustalić, który klient korzystał z danego adresu i portu w danym momencie, a to jest potrzebne choćby przy zgłoszeniach nadużyć. [2]
Osobna rodzina rozwiązań to Dual-Stack Lite, opisany w RFC 6333 z 2011 roku. Tam ruch IPv4 jest tunelowany w IPv6 do urządzenia operatora, gdzie następuje tłumaczenie adresów. Efekt dla użytkownika jest podobny: publiczny adres IPv4 nie trafia do domu. [3]
Dlaczego dostawcy to robią
Powód jest jeden: brak adresów IPv4. RIPE NCC, rejestr odpowiedzialny za Europę, wyczerpał swój ostatni wolny blok 25 listopada 2019 roku. [5] Wcześniej, w 2012 roku, rozdano ostatnie większe pule, a od tamtej pory nowe organizacje mogły liczyć na niewielkie fragmenty z listy oczekujących. Adresy można też kupować na rynku wtórnym, ale to koszt i dodatkowa biurokracja.
CGNAT pozwala odłożyć decyzję o zakupie adresów i obsłużyć więcej klientów bez zmiany infrastruktury. Jest przy tym tańszy niż rozbudowa puli, choć nie rozwiązuje problemu, tylko przesuwa go w czasie. RIPE NCC w swoim komunikacie z 2019 roku pisał wprost, że ani rynek transferu, ani CGNAT nie rozwiązują braku adresów.
Co przestaje działać
Najbardziej odczuwalny skutek to brak możliwości połączenia z zewnątrz do urządzenia w domu. Kamera IP, serwer plików, komputer z grą, własny VPN czy panel sterowania nie przyjmą połączenia, bo nie mają unikalnego adresu publicznego. Przekierowanie portu na routerze nic nie da, jeśli drugi NAT stoi u dostawcy i nie ma reguły, która przepuści ruch do konkretnego abonenta.
Drugi skutek to współdzielony adres i jego reputacja. Jeśli jedna osoba za tym samym adresem publicznym wyśle spam albo trafi na listę blokad, mogą ucierpieć inni. [4] W praktyce częściej widać to jako natrętne captche, blokady dostępu do niektórych usług czy problemy z logowaniem. Odwołanie się od takiej blokady jest trudniejsze, bo dotyczy adresu, a nie konta.
Trzeci skutek to limity portów. Jeden adres publiczny ma około 65 tysięcy portów na protokół, a gdy dzieli go wielu abonentów, operator przydziela każdemu ograniczony zakres. Przy intensywnym korzystaniu z aplikacji otwierających wiele połączeń, na przykład w grach peer-to-peer albo przy synchronizacji plików, limity mogą stać się odczuwalne. RFC 6888 wprost dopuszcza konfigurowalne limity na abonenta.
Czwarty skutek dotyczy prywatności i retencji. Operator widzi mapowanie adresu i portu na abonenta, więc musi je przechowywać, żeby odpowiedzieć na uprawnione zapytania. To nie znaczy, że ktoś czyta treść połączeń szyfrowanych, ale metadane są bogatsze niż w sieci bez CGNAT.
Co nadal działa
Połączenia wychodzące działają normalnie: przeglądanie stron, poczta, streaming, komunikatory i gry, które nie wymagają bezpośredniego nasłuchiwania. Wiele aplikacji radzi sobie z podwójnym NAT dzięki mechanizmom przechodzenia przez NAT, na przykład STUN i TURN, które pomagają ustalić trasę mimo braku publicznego adresu.
Nie pomoże natomiast UPnP w routerze, jeśli urządzenie operatora nie honoruje tych żądań. Router może otworzyć port u siebie, ale pakiet i tak zatrzyma się na NAT operatora. Diagnoza bywa myląca, bo lokalnie wszystko wygląda poprawnie.
Prawdziwym wyjściem jest IPv6. Jeśli dostawca przydziela publiczny prefiks, urządzenia mogą mieć globalne adresy i przestać potrzebować przekierowań. W praktyce dostawcy często dają prefiks /56 lub /48 i delegują go do routera. Warto sprawdzić, czy adres IPv6 jest publiczny, a nie tylko lokalny, i czy firewall przepuszcza ruch do wybranego urządzenia.
Jak sprawdzić, czy jesteś za CGNAT
Najprostszy test to porównanie dwóch adresów. Odczytaj adres WAN w panelu routera i porównaj go z adresem, który widzi zewnętrzny serwis po wykonaniu zapytania z twojej sieci. Jeśli się różnią, po drodze jest dodatkowe tłumaczenie adresów.
Drugi test to zakres. Adresy 100.64.0.0/10, 10.0.0.0/8, 172.16.0.0/12 i 192.168.0.0/16 nie są publiczne. Jeśli adres WAN należy do jednego z nich, router nie ma publicznego adresu. Warto przy tym pamiętać, że niektórzy dostawcy nadal dają publiczny adres, ale blokują przychodzące połączenia na poziomie firewalla, więc sam adres nie rozstrzyga wszystkiego.
Trzeci test to trasa. Wykonanie traceroute do zewnętrznego serwera pokazuje pierwsze przeskoki. Jeśli po routerze widać kolejny adres z prywatnego zakresu, to znak, że operator wykonuje tłumaczenie. To poszlaka, nie dowód, bo trasa może być filtrowana.
Co można z tym zrobić
Najpierw rozmowa z dostawcą. Część operatorów udostępnia publiczny adres IPv4 za dopłatą albo w ramach oferty dla firm. Inni oferują IPv6, które rozwiązuje problem taniej i czyściej. Warto zapytać o oba warianty, zamiast od razu szukać obejść.
Obejściem jest tunel lub VPN z publicznym adresem po stronie serwera. Ruch z domu wychodzi na zewnątrz, a powrotny trafia do serwera i tunelem do urządzenia. To działa, ale przenosi zaufanie na operatora tunelu i dodaje opóźnienie. Do podglądu kamery czy dostępu do plików to często wystarcza, do usług publicznych bywa zbyt kosztowne.
Ostatnia uwaga: CGNAT nie jest awarią ani błędem konfiguracji. To świadoma decyzja dostawcy wynikająca z braku adresów. Dopóki IPv4 jest deficytowy, będzie się pojawiał częściej, także w sieciach światłowodowych, nie tylko w mobilnych.
Źródła
- Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., Azinger, M., IANA-Reserved IPv4 Prefix for Shared Address Space, RFC 6598 (BCP 153), kwiecień 2012, rfc-editor.org/rfc/rfc6598.
- Perreault, S. (red.), Yamagata, I., Miyakawa, S., Nakagawa, A., Ashida, H., Common Requirements for Carrier-Grade NATs (CGNs), RFC 6888 (BCP 127), kwiecień 2013, rfc-editor.org/rfc/rfc6888.
- Durand, A., Droms, R., Woodyatt, J., Lee, Y., Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion, RFC 6333, sierpień 2011, rfc-editor.org/rfc/rfc6333.
- Ford, M., Boucadair, M., Durand, A., Levis, P., Roberts, P., Issues with IP Address Sharing, RFC 6269, czerwiec 2011, rfc-editor.org/rfc/rfc6269.
- RIPE NCC, The RIPE NCC has run out of IPv4 Addresses, 25 listopada 2019, ripe.net.
