Publiczna adresacja IPv6 w chmurze: koniec z NAT, ale nie z zaporą

Blog WebDisk · kategoria: Chmura obliczeniowa · czas czytania: ~8 minut

W skrócie:- W Europie pula wolnych adresów IPv4 wyczerpała się w 2019 roku – publiczny adres IPv4 stał się zasobem deficytowym, kupowanym na rynku wtórnym i coraz częściej rozliczanym osobno.- IPv6 przywraca pierwotny model internetu: każda maszyna wirtualna może mieć własny publiczny adres i komunikować się bezpośrednio, bez translacji adresów (NAT).- Publiczny adres to nie otwarte drzwi – o tym, co widać z internetu, decyduje zapora sieciowa; rozsądnym standardem na dziś jest dual-stack, czyli IPv4 i IPv6 równolegle. >Nie pracujesz z terminalem? Możesz pominąć sekcję z poleceniami – reszta artykułu czyta się bez niej.

Każdego roku do internetu podłączają się miliardy nowych urządzeń: telefony, czujniki, kamery, a w chmurach – maszyny wirtualne i kontenery, nierzadko o żywotności liczonej w minutach. Tymczasem protokół IPv4, na którym internet działa od lat 80., oferuje niecałe 4,3 miliarda adresów. To za mało od dawna – i nie jest to odległa prognoza, lecz stan faktyczny: w 2019 roku RIPE NCC, rejestr przydzielający adresy w Europie, rozdysponował ostatnie wolne bloki ze swojej podstawowej puli.

Odpowiedź techniczna istnieje od ponad dwóch dekad i nazywa się IPv6. Nie jest to „IPv4 z większą liczbą adresów”, lecz powrót do pierwotnej idei internetu, w której każde urządzenie ma własny, unikalny adres i komunikuje się z innymi bezpośrednio – bez pośredników tłumaczących adresy w locie.

W tym artykule wyjaśniamy, skąd wziął się deficyt adresów i dlaczego podnosi koszty, co w praktyce daje publiczna adresacja IPv6 w chmurze, dlaczego publiczny adres nie zwalnia z konfigurowania zapory – i jak w kilka minut sprawdzić, czy Twoja maszyna naprawdę korzysta z IPv6. Sekcje koncepcyjne przeczyta każdy, kto decyduje o architekturze IT w firmie; sekcja praktyczna jest dla administratorów.

Dlaczego adresów IPv4 brakuje i ile to kosztuje?

Adres IPv4 to liczba 32-bitowa, więc wszystkich możliwych adresów jest około 4,3 miliarda – mniej niż ludzi na Ziemi, nie mówiąc o urządzeniach. Internet nie zatrzymał się dzięki protezie o nazwie NAT (Network Address Translation – translacja adresów sieciowych): jeden publiczny adres jest współdzielony przez wiele urządzeń, a router tłumaczy ruch w obie strony. Operatorzy poszli o krok dalej i stosują CGNAT – NAT na skalę całych osiedli, w którym ten sam publiczny adres dzielą setki klientów.

NAT działa, ale ma swoją cenę. Usługa schowana za translacją nie jest osiągalna z zewnątrz, dopóki nie skonfigurujemy przekierowań portów; połączenia bezpośrednie (telefonia internetowa, wideokonferencje, gry, sieci P2P) wymagają obejść; diagnostyka „kto właściwie się z nami łączy” komplikuje się, gdy za jednym adresem kryją się setki urządzeń.

Deficyt widać też w kosztach. Wolnych adresów IPv4 w rejestrach praktycznie nie ma, więc handluje się nimi na rynku wtórnym, a część dużych dostawców chmurowych rozlicza publiczny adres IPv4 jako osobną pozycję na rachunku. Pisaliśmy już na blogu o tym, z czego składa się cena chmury publicznej – publiczna adresacja to jeden z tych składników, których nie widać w tabelce ze specyfikacją, dopóki nie zaczną kosztować.

IPv6: nie „więcej tego samego”, lecz inny model sieci

Adres IPv6 ma 128 bitów. Liczba możliwych adresów jest tak duża (39 cyfr), że przestaje być intuicyjna, więc praktyczniejsza jest inna miara: standardową pojedynczą siecią w IPv6 jest blok /64, który sam w sobie zawiera ponad 18 trylionów adresów – pulę ponad cztery miliardy razy większą niż cały internet IPv4. Ta rozrzutność jest celowa: tak duża podsieć umożliwia bezstanową autokonfigurację (SLAAC), w której maszyna sama wyprowadza swój adres z prefiksu ogłaszanego przez router – bez serwera DHCP i bez ręcznego przydzielania adresów.

Najważniejsza zmiana jest jednak architektoniczna. Skoro adresów wystarcza dla każdego urządzenia, NAT przestaje być potrzebny: maszyna wirtualna, kontener czy czujnik może mieć własny, globalnie unikalny adres i komunikować się z dowolnym innym urządzeniem bezpośrednio. Znikają przekierowania portów, znika żonglowanie jednym publicznym adresem między usługami, znika cała klasa problemów „to nie działa przez podwójny NAT”. Topologia sieci robi się prostsza do zaprojektowania i – co równie ważne – do zrozumienia po roku, gdy trzeba ją zmienić.

Co daje publiczna adresacja IPv6 w chmurze?

W środowisku chmurowym różnica jest szczególnie odczuwalna, bo to tam liczba adresowanych bytów rośnie najszybciej: każda maszyna wirtualna, każdy kontener i każda usługa może potrzebować osiągalności z zewnątrz.

Z publiczną adresacją IPv6:

usługę wystawiasz bezpośrednio – bez rezerwowania kolejnego adresu IPv4 i bez mapowania portów; adres usługi jest jej adresem, a nie „portem 8443 na wspólnym adresie”;
architektura jest czytelniejsza – ruch nie przechodzi przez warstwę translacji, więc logi i diagnostyka pokazują rzeczywiste adresy obu końców komunikacji;
skalowanie nie wyczerpuje puli – dziesiąta, setna i tysięczna maszyna dostają adresy tak samo łatwo jak pierwsza.

W WebDisk Cloud – chmurze publicznej zbudowanej na platformie Apache CloudStack – publiczna adresacja IPv4 i IPv6 jest częścią oferty sieciowej, obok sieci VPC, NAT/SNAT, zapory, przekierowań portów i load balancerów. O tym, które maszyny i usługi są osiągalne z internetu, decydują reguły zapory ustawiane przez klienta, a nie ograniczenia puli adresowej. Szczegóły znajdziesz na stronie chmury publicznej WebDisk, a jeśli przenosisz istniejące środowisko – zajrzyj też do przewodnika po migracji z VMware do WebDisk Cloud.

Publiczny adres ≠ otwarte drzwi: zapora jest obowiązkowa

Najczęstsza obawa przed IPv6 brzmi: „skoro każda maszyna ma publiczny adres, to każda jest wystawiona na atak”. Ta obawa myli dwie rzeczy: adresowalność i osiągalność.

NAT nigdy nie był projektowany jako mechanizm bezpieczeństwa – jego efektem ubocznym było jedynie to, że maszyny bez przekierowań portów były trudno osiągalne z zewnątrz. W świecie IPv6 tę samą (i lepszą) kontrolę daje zapora sieciowa: domyślnie blokujemy ruch przychodzący i otwieramy wyłącznie to, co świadomie wystawiamy. Różnica polega na tym, że decyzja jest jawna i audytowalna, a nie wynika z przypadkowej właściwości translacji adresów.

W chmurze reguły warto utrzymywać na dwóch poziomach: zapory na poziomie platformy (reguły sieci definiowane w panelu chmury) oraz zapory w samym systemie operacyjnym maszyny. Dwie warstwy to nie nadgorliwość – to ochrona przed błędem w jednej z nich.

Dwie pułapki zasługują na osobne zdania. Po pierwsze, usługi potrafią nasłuchiwać na IPv6, mimo że konfigurowano je „tylko po IPv4” – wiele serwerów wiąże się domyślnie z adresem ::, obejmującym oba protokoły; warto to sprawdzić (pokażemy jak). Po drugie, nie należy liczyć na to, że „w /64 nikt nas nie znajdzie” – przeskanowanie 18 trylionów adresów jest wprawdzie niepraktyczne, ale adresy i tak wychodzą na jaw: przez DNS, logi, nagłówki, certyfikaty. Ukrycie nie zastępuje zapory ani aktualizacji. A skoro maszyna jest publicznie osiągalna, tym ważniejsza jest wiedza o tym, co się na niej dzieje – o samodzielnym monitorowaniu stanu VM pisaliśmy w artykule o Watchdogu.

Czym jest dual-stack i dlaczego wciąż potrzebujesz IPv4?

Choć udział IPv6 rośnie od lat, część internetu wciąż komunikuje się wyłącznie po IPv4. Dlatego standardem przejściowym – „przejściowym” już od dekady i zapewne jeszcze na lata – jest dual-stack: maszyna ma jednocześnie adres IPv4 i IPv6, a system operacyjny wybiera protokół dla każdego połączenia.

Dla usługi wystawionej w internecie oznacza to w praktyce: publikujemy w DNS zarówno rekord A (adres IPv4), jak i AAAA (adres IPv6). Nowoczesne klienty stosują mechanizm Happy Eyeballs – próbują IPv6 i szybko wycofują się do IPv4, jeśli tamta ścieżka nie odpowiada. To dobra wiadomość z jednym zastrzeżeniem: zepsuty IPv6 bywa gorszy niż jego brak. Jeśli opublikujesz rekord AAAA, a ruch IPv6 blokuje zapora albo trasa nie działa, część klientów odczuje opóźnienia. Wniosek: po włączeniu IPv6 testujemy i monitorujemy usługę na obu protokołach, nie tylko na tym, którym akurat łączy się nasz własny komputer.

Jak sprawdzić, czy Twoja maszyna korzysta z IPv6?

Poniższe polecenia działają na typowej maszynie z Linuksem i niczego nie zmieniają w konfiguracji – tylko odczytują stan.

# 1. Czy maszyna ma globalny adres IPv6?
# (szukamy zakresu "global"; sam fe80::... to adres lokalny łącza — to za mało)
ip -6 addr show scope global

# 2. Czy jest trasa domyślna dla IPv6?
ip -6 route show default

# 3. Czy ruch faktycznie wychodzi w świat po IPv6?
ping -6 -c 3 2001:4860:4860::8888 # publiczny resolver DNS Google
curl -6 https://ifconfig.co # wypisze Twój publiczny adres IPv6

# 4. Co nasłuchuje na IPv6 — czyli co po otwarciu zapory zobaczy internet
ss -6tulnp

# 5. Czy zapora w systemie obejmuje IPv6?
sudo nft list ruleset # tabele typu "inet" obejmują IPv4 i IPv6
sudo ip6tables -L -n # starsze systemy oparte na iptables

Jeśli punkt 1 lub 2 nic nie zwraca, adresacji IPv6 szukaj najpierw w konfiguracji sieci w panelu chmury – maszyna nie wyczaruje adresu, którego sieć jej nie ogłasza. Jeśli polecenia z punktu 3 działają, a usługa mimo to nie odpowiada po IPv6 z zewnątrz, niemal zawsze winna jest zapora (na jednym z dwóch poziomów) albo brak rekordu AAAA w DNS.

Czego IPv6 nie załatwi?

Żeby obraz był pełny, wypiszmy też, czego publiczna adresacja IPv6 nie daje:

Nie przyspieszy automatycznie aplikacji. Ścieżka bez NAT bywa prostsza, ale realna wydajność zależy od tras między operatorami – po IPv6 bywa szybciej i bywa wolniej.
Nie podniesie bezpieczeństwa sama z siebie. Zapora, aktualizacje i monitoring są dokładnie tak samo potrzebne jak przy IPv4.
Nie pozwoli dziś wyłączyć IPv4. Dopóki część klientów i usług żyje wyłącznie w IPv4, dual-stack pozostaje koniecznością.
Wymaga przeglądu narzędzi. Logi, listy dozwolonych adresów, mechanizmy banowania, pola bazodanowe na adresy IP (tekstowy zapis IPv6 ma do 45 znaków), geolokalizacja i monitoring muszą rozumieć nowy format – to zwykle drobne, ale liczne poprawki.

Częste pytania

Czy IPv6 zastąpi IPv4? Docelowo tak, ale horyzont liczony jest w latach, nie miesiącach. Dlatego praktyczne pytanie nie brzmi „IPv4 czy IPv6”, tylko „czy moje środowisko obsługuje oba”.

Czy publiczny adres na każdej maszynie to nie ryzyko? Ryzykiem jest brak zapory, nie adres. Zasada jest ta sama co zawsze: domyślnie blokuj ruch przychodzący, otwieraj świadomie i punktowo, utrzymuj reguły na poziomie platformy i systemu operacyjnego.

Czy IPv6 jest szybszy od IPv4? Sam protokół nie daje takiej gwarancji. Brak translacji upraszcza ścieżkę pakietów, ale o opóźnieniach decydują głównie trasy między operatorami. Ewentualny zysk traktuj jako miłą niespodziankę, nie argument biznesowy.

Dlaczego publiczny adres IPv4 kosztuje dodatkowo? Pula wolnych adresów IPv4 w europejskim rejestrze RIPE NCC wyczerpała się w 2019 roku, więc adresy pozyskuje się na rynku wtórnym. Dlatego część dostawców chmurowych rozlicza publiczny adres IPv4 jako osobną pozycję na rachunku. IPv6 tego problemu nie ma – adresów wystarcza dla każdej maszyny.

Moja aplikacja zapisuje adresy IP użytkowników. Muszę coś zmienić? Prawdopodobnie tak: sprawdź długość pól (tekstowy IPv6 to do 45 znaków), walidację formatu i wszystkie miejsca, w których adres jest porównywany lub filtrowany. Pamiętaj też, że adres IP – niezależnie od wersji – pozostaje informacją, którą przetwarzasz zgodnie z zasadami ochrony danych.

Od czego zacząć w istniejącym środowisku? Od inwentaryzacji: które usługi mają być osiągalne z internetu, a które tylko wewnętrznie. Potem dual-stack na usługach brzegowych, testy z zewnątrz na obu protokołach, na końcu rekordy AAAA w DNS. Rekord DNS celowo jest ostatni – od momentu publikacji klienci naprawdę zaczną używać tej ścieżki.

Podsumowanie

Deficyt adresów IPv4 jest trwały i coraz częściej po prostu kosztuje. IPv6 rozwiązuje go u źródła: przywraca model, w którym każda maszyna może mieć własny publiczny adres, a o dostępności usług decydują jawne reguły zapory, nie akrobatyka z translacją adresów. Rozsądna droga na dziś to dual-stack – wdrażany świadomie, z testami obu ścieżek. A jeśli przy okazji zastanawiasz się, gdzie takie środowisko osadzić, o atutach lokalnego dostawcy piszemy w artykule o polskiej chmurze obliczeniowej.

Jeśli planujesz środowisko z publiczną adresacją IPv6, sprawdź ofertę chmury publicznej WebDisk albo napisz do nas – pomożemy zaplanować adresację i reguły zapory.