Spis treści

Wyobraź sobie dziwną sytuację. Otwierasz na telefonie serwis sprawdzający IP, a on pokazuje adres IPv4. Ale jeśli zajrzysz do ustawień interfejsu sieciowego tego samego urządzenia, zobaczysz długi adres IPv6. Jak to możliwe? Urządzenie żyje w świecie IPv6, a strona w swoich logach pewnie zapisuje cztery dziesiętne liczby oddzielone kropkami. Gdzie następuje podmiana?

To nie błąd ani magia. To starannie zaprojektowany system translacji, który operatorzy sieci wdrażają na całym świecie od ponad dziesięciu lat. A jeśli pracujesz z mobilnymi proxy, scrapingiem, wielokontami lub po prostu chcesz zrozumieć, co dzieje się z Twoim ruchem, zrozumienie tej mechaniki jest kluczowe.

W tym przewodniku przejdziemy całą ścieżkę pakietu od aplikacji na telefonie do docelowej strony. Przeanalizujemy 464XLAT po komponentach, zrozumiemy rolę NAT64 i DNS64, zobaczymy, gdzie dokładnie rodzi się wyjściowy adres IPv4, i nauczymy się samodzielnie diagnozować stos połączenia. To nie jest pobieżny przegląd. To głębokie zanurzenie dla tych, którzy chcą wiedzieć nie tylko co się dzieje, ale także jak i dlaczego.

Wprowadzenie: dlaczego telefon otrzymuje IPv6, a strona widzi IPv4

Zacznijmy od sedna paradoksu. Nowoczesny smartfon w sieci mobilnej dużego operatora prawie na pewno jest podłączony przez IPv6. Co więcej, często w ogóle nie ma rzeczywistego adresu IPv4 na interfejsie radiowym. Operator po prostu go nie przydziela. To świadoma decyzja podyktowana dotkliwym niedoborem przestrzeni adresowej.

Ale Internet nie jest jednorodny. Ogromna liczba stron, API i usług wciąż jest dostępna tylko przez IPv4. Nie mają rekordu AAAA w DNS, ich serwery nie słuchają na IPv6. Gdyby telefon umiał mówić wyłącznie w języku IPv6, nie byłby w stanie otworzyć połowy Internetu. Powstaje sprzeczność: urządzenie mówi w nowym języku, a rozmówca rozumie tylko stary.

Rozwiązanie tej sprzeczności jest głównym tematem naszej rozmowy. Technologia o nazwie 464XLAT wraz z mechanizmami NAT64 i DNS64 tworzy niewidzialny most. Urządzenie wysyła pakiety przez IPv6, a gdzieś w głębi sieci operatora te pakiety zamieniają się w IPv4 i wędrują do docelowego serwera już z prawdziwym adresem IPv4. Serwer odpowiada, a droga powrotna przechodzi tę samą transformację w odbiciu lustrzanym.

Dlatego właśnie docelowa strona widzi IPv4. Dlatego mobilne proxy zbudowane na prawdziwym telefonie lub modemie operatora oddaje na zewnątrz adres IPv4, chociaż wewnątrz urządzenia panuje IPv6. Podmiana nie następuje na telefonie ani na stronie. Następuje w pośrednim węźle sieci operatora, zwanym PLAT.

Czego się dowiesz, czytając do końca:

  • Jak działa niedobór adresów IPv4 i dlaczego zmusił operatorów do przejścia na IPv6
  • Czym są typy APN i czym różni się IPv4v6 od czystego IPv6
  • Jak krok po kroku działa 464XLAT, gdzie mieszka CLAT, a gdzie PLAT
  • Jak NAT64 i DNS64 udostępniają stronę bez rekordu AAAA
  • Skąd bierze się wyjściowy adres IPv4 mobilnego proxy
  • Jak happy eyeballs sprawia, że serwis sprawdzający pokazuje raz IPv4, raz IPv6
  • Praktyczne polecenia do diagnostyki stosu połączenia
  • Dlaczego podsieć /64 jest postrzegana jako jeden klient i co to oznacza dla kont

Umówmy się od razu o granicach. Mówimy wyłącznie o mechanice sieciowej. Nie dyskutujemy, co bardziej opłaca się kupować i który protokół jest lepszy z komercyjnego punktu widzenia. To przewodnik inżynieryjny, a nie przegląd rynkowy.

Podstawy: niedobór IPv4, przejście na IPv6 i typy APN

Aby zrozumieć całą konstrukcję, zacznijmy od fundamentów. A fundamentem jest katastrofalny brak adresów IPv4.

Dlaczego IPv4 się skończył

Protokół IPv4 używa 32-bitowych adresów. Daje to około 4,3 miliarda unikalnych kombinacji. W 1981 roku, kiedy protokół standaryzowano, wydawało się to astronomiczną liczbą. Kto mógł przewidzieć, że urządzeń będzie więcej niż ludzi na planecie?

Rzeczywistość okazała się brutalna. Smartfony, tablety, inteligentne zegarki, lodówki, kamery, samochody – wszystko wymaga adresu. Na początku lat 2010. regionalne rejestry internetowe zaczęły wyczerpywać wolne bloki. Dziś uzyskanie dużego bloku białych adresów IPv4 jest praktycznie niemożliwe, a na rynku wtórnym kosztują dziesiątki dolarów za sztukę.

Dla operatora komórkowego z dziesiątkami milionów abonentów to fundamentalny problem. Przydzielenie każdemu smartfonowi osobnego publicznego IPv4 jest fizycznie nierealne. Adresów po prostu brakuje.

Jak IPv6 rozwiązuje problem

Protokół IPv6 używa 128-bitowych adresów. Liczba możliwych kombinacji jest tak ogromna, że ludzki mózg odmawia jej pojęcia – to około 340 undecylionów adresów. Można by przydzielić po kilka adresów każdemu atomowi na powierzchni Ziemi i jeszcze by zostało.

Operator otrzymuje od rejestratora ogromny blok IPv6 i rozdaje abonentom z kolosalnym zapasem. Typową praktyką jest przydzielenie każdemu urządzeniu abonenckiemu całej podsieci /64. To, uwaga, 18 trylionów adresów na jeden telefon. Zapamiętaj ten fakt – odegra ważną rolę w sekcji o wielokontach.

Czym jest APN i po co są jego typy

APN oznacza Access Point Name, czyli nazwę punktu dostępowego. To profil konfiguracyjny, który informuje telefon, jak połączyć się z siecią pakietową operatora. Gdy smartfon nawiązuje transmisję danych, żąda od sieci utworzenia sesji z określonym typem protokołu.

Istnieją trzy główne typy kontekstu PDN lub PDP:

  • IPv4 – urządzeniu przydzielany jest tylko adres IPv4. Klasyczny, przestarzały schemat. Działa, ale wymaga adresów, których brakuje.
  • IPv6 – urządzeniu przydzielany jest tylko prefiks IPv6. Żadnego IPv4 na interfejsie. Maksymalna oszczędność dla operatora.
  • IPv4v6 – podwójny stos. Urządzenie żąda obu typów adresów jednocześnie w ramach jednej sesji.

Tu pojawia się niuans. Nawet jeśli telefon żąda IPv4v6, operator może oddać tylko część IPv6, a w części IPv4 odmówić lub przydzielić prywatny adres przez mechanizm translacji. Wielu dużych operatorów jest skonfigurowanych tak, że abonent domyślnie otrzymuje czysty IPv6, a zgodność z Internetem IPv4 zapewnia już opisana technologia 464XLAT.

Analogie, która pomaga. Wyobraź sobie, że cały świat przeszedł na nowy język komunikacji, ale wiele starych instytucji przyjmuje dokumenty tylko w starym. Państwo nie może wydać każdemu obywatelowi osobnego starego paszportu – brakuje ich. Dlatego wydaje wszystkim nowe dokumenty, a przy wejściu do starych instytucji stawia tłumacza. Ten tłumacz to właśnie 464XLAT.

Głębokie zanurzenie: 464XLAT po komponentach

Teraz jesteśmy gotowi, by rozprawić się z samą technologią. Nazwa 464XLAT czyta się jako four-six-four translation. Cyfry oddają sedno: pakiet zaczyna życie jako IPv4 w aplikacji, podróżuje przez sieć jako IPv6, a następnie znów staje się IPv4 na wyjściu. XLAT to skrót od translation, translacja.

Podstawą jest standard translacji adresów między protokołami, opisany w specyfikacjach IETF. Ale 464XLAT dodaje do niego architekturę dwóch komponentów działających w parze.

CLAT – translator na urządzeniu

CLAT oznacza Customer-side translator, czyli translator po stronie klienta. Mieszka bezpośrednio na Twoim smartfonie, wbudowany w system operacyjny. W Androidzie tę funkcję pełni specjalny demon, w innych systemach – analogiczne moduły.

Zadanie CLAT jest jedno, ale ważne. Gdy aplikacja na telefonie chce wysłać pakiet przez IPv4 – na przykład gdy używa gniazda IPv4 lub odwołuje się bezpośrednio do adresu IP – CLAT przechwytuje ten pakiet IPv4 i zawija go w IPv6. Technicznie wykonuje translację nagłówków według algorytmu translacji bezstanowej, przekształcając adresy źródłowy i docelowy IPv4 na odpowiadające im adresy IPv6 przy użyciu znanego wcześniej prefiksu.

CLAT tworzy na urządzeniu wirtualny interfejs sieciowy, któremu przypisany jest prywatny adres IPv4. Aplikacje widzą ten adres i myślą, że żyją w normalnym środowisku IPv4. Nawet nie podejrzewają, że pod maską wszystko dawno przeniosło się na IPv6.

PLAT – translator w sieci operatora

PLAT oznacza Provider-side translator, translator po stronie dostawcy. To potężny węzeł gdzieś w rdzeniu sieci operatora, realizujący funkcję NAT64. To tutaj następuje ostateczna przemiana.

PLAT odbiera pakiety IPv6, które przyszły od urządzenia, i wyodrębnia z nich informacje o oryginalnym przeznaczeniu IPv4. Następnie wykonuje translację stanową: zamienia pakiet IPv6 z powrotem na pakiet IPv4, podstawia jako adres źródłowy jeden z publicznych adresów IPv4 operatora ze swojej puli i wysyła pakiet do zwykłego Internetu IPv4.

Kluczowe słowo to stateful, czyli z zachowaniem stanu. PLAT prowadzi tablicę odpowiedników, aby pakiety zwrotne od serwera poprawnie wróciły do tego urządzenia, które zainicjowało połączenie. To w zasadzie ta sama zasada, co w klasycznym NAT, tyle że między różnymi protokołami.

Dlaczego dwa translatory

Nasuwa się pytanie: po co CLAT na urządzeniu, skoro PLAT i tak wszystko przetłumaczy? Odpowiedź tkwi w aplikacjach, które nie obsługują IPv6.

Wiele aplikacji zostało napisanych z twardym użyciem IPv4. Żądają gniazda IPv4, pracują z literałami adresów IPv4, niektóre protokoły, jak stare implementacje, przesyłają adresy IP w ładunku. Gdyby na urządzeniu był tylko czysty IPv6, takie aplikacje po prostu by się zepsuły. CLAT daje im iluzję pełnoprawnego środowiska IPv4, pozostając niewidocznym.

Zatem para działa tak: CLAT rozwiązuje problem zgodności na urządzeniu, PLAT rozwiązuje problem zgodności w Internecie. Razem tworzą bezszwowy most.

NAT64 i DNS64: jak strona bez rekordu AAAA ożywa

Rozprawiliśmy się z translacją pakietów. Ale jest jeszcze jeden fundamentalny problem – jak urządzenie w ogóle dowiaduje się, dokąd wysłać pakiet IPv6, jeśli docelowa strona istnieje tylko w świecie IPv4 i nie ma żadnego rekordu IPv6?

Tu na scenę wchodzi duet NAT64 i DNS64. Działają one w ścisłym powiązaniu i nie sposób zrozumieć jednego bez drugiego.

Problem braku rekordu AAAA

W systemie nazw domen adresy różnych protokołów przechowywane są w różnych typach rekordów. Adres IPv4 przechowywany jest w rekordzie typu A. Adres IPv6 przechowywany jest w rekordzie typu AAAA, wymawianym jako quad-A.

Gdy urządzenie czysto IPv6 chce otworzyć stronę, pyta DNS o rekord AAAA. Ale jeśli strona nie ma infrastruktury IPv6, to i rekordu AAAA nie ma. Jest tylko rekord A z adresem IPv4. Urządzenie otrzymuje pustą odpowiedź i teoretycznie powinno powiedzieć: strona niedostępna. Ale tak się nie dzieje dzięki DNS64.

Jak działa DNS64

DNS64 to specjalny resolver DNS operatora z supermocą. Gdy urządzenie pyta o rekord AAAA dla domeny, a prawdziwy rekord AAAA nie istnieje, DNS64 nie poddaje się. Robi następujące rzeczy:

  1. Pyta autorytatywny serwer o zwykły rekord A i otrzymuje adres IPv4 strony
  2. Bierze ten adres IPv4 i syntetyzuje z niego sztuczny rekord AAAA
  3. Do syntezy osadza 32 bity adresu IPv4 w specjalnym prefiksie IPv6
  4. Zwraca ten syntetyzowany rekord AAAA urządzeniu jak gdyby nigdy nic

Urządzenie otrzymuje prawidłowy adres IPv6 i radośnie wysyła na niego pakiety. Nie wie i nie musi wiedzieć, że ten adres jest sztuczny.

Syntetyzowany prefiks 64:ff9b::/96

Oto jeden z najbardziej rozpoznawalnych artefaktów całego systemu. Do syntezy adresów używany jest specjalnie zarezerwowany prefiks 64:ff9b::/96. Nazywa się Well-Known Prefix, czyli powszechnie znany prefiks, i jest standaryzowany właśnie do translacji NAT64.

Mechanika jest prosta i elegancka. Prefiks zajmuje pierwsze 96 bitów adresu. Pozostałe 32 bity to dokładnie rozmiar adresu IPv4. DNS64 po prostu dopisuje adres IPv4 strony na końcu prefiksu.

Na przykład, jeśli strona ma adres IPv4 wyrażony czterema liczbami, syntetyzowany adres IPv6 będzie wyglądał jak prefiks 64:ff9b, po którym w ostatnich 32 bitach zakodowane są te cztery liczby. Gdy taki pakiet dotrze do PLAT, węzeł widzi znajomy prefiks, rozumie, że to translacja NAT64, wyodrębnia ostatnie 32 bity i otrzymuje prawdziwy adres IPv4 przeznaczenia. Następnie wysyła zwykły pakiet IPv4.

Niektórzy operatorzy zamiast powszechnie znanego prefiksu używają własnego prefiksu sieciowego ze swojej przestrzeni adresowej. Logika ta sama, zmienia się tylko konkretna wartość pierwszych bitów.

Jak para działa razem

Złóżmy puzzla. DNS64 odpowiada za to, by urządzenie otrzymało adres IPv6 na potrzeby wyjścia do Internetu IPv4. NAT64 w osobie PLAT odpowiada za to, by pakiet pod tym adresem faktycznie dotarł do serwera IPv4. Jeden bez drugiego jest bezużyteczny: DNS64 tworzy adres, który potrafi obsłużyć tylko NAT64, a NAT64 obsługuje tylko te adresy, które zsyntetyzował DNS64.

A co dzieje się ze stronami, które mają prawdziwy rekord AAAA? Tu wszystko jest prostsze. DNS64 widzi prawdziwy rekord AAAA i po prostu go zwraca bez żadnej syntezy. Urządzenie łączy się ze stroną bezpośrednio przez IPv6, omijając całą maszynerię translacyjną. To optymalna ścieżka end-to-end.

Ścieżka pakietu od aplikacji do strony przy 464XLAT: schemat słowny

Nadszedł czas, by złożyć całą mechanikę w jeden schemat krok po kroku. Prześledźmy jeden pakiet od momentu narodzin w aplikacji do dotarcia na docelowy serwer IPv4 i z powrotem. To ta sama trasa, którą pokonuje ruch mobilnego proxy.

Droga w przód: od telefonu do strony

  1. Krok 1. Aplikacja chce się połączyć. Aplikacja na telefonie postanawia otworzyć stronę, która ma tylko IPv4. Zwraca się do DNS po adres.
  2. Krok 2. DNS64 syntetyzuje adres. Resolver operatora nie znajduje prawdziwego rekordu AAAA, bierze rekord A, osadza adres IPv4 w prefiksie 64:ff9b::/96 i zwraca syntetyzowany rekord AAAA.
  3. Krok 3. Aplikacja wysyła pakiet. Są dwie opcje. Jeśli aplikacja działa przez IPv6, od razu wysyła pakiet IPv6 na syntetyzowany adres. Jeśli aplikacja jest twardo przywiązana do IPv4, wysyła pakiet IPv4 na wirtualny interfejs CLAT.
  4. Krok 4. CLAT transluje IPv4 na IPv6. W przypadku aplikacji IPv4 demon CLAT przechwytuje pakiet i zgodnie z regułami translacji bezstanowej zamienia go na pakiet IPv6, używając tego samego prefiksu NAT64.
  5. Krok 5. Pakiet leci przez sieć radiową. Teraz to czysty pakiet IPv6. Przechodzi przez stację bazową i rdzeń sieci mobilnej operatora. Wewnątrz całej części radiowej żyje tylko IPv6.
  6. Krok 6. Pakiet dociera do PLAT. W rdzeniu sieci stoi węzeł PLAT z funkcją NAT64. Widzi pakiet z przeznaczeniem zaczynającym się od prefiksu NAT64.
  7. Krok 7. PLAT transluje IPv6 na IPv4. Węzeł wyodrębnia ostatnie 32 bity adresu docelowego – to prawdziwy IPv4 strony. Następnie podstawia jako źródło publiczny IPv4 ze swojej puli, zapisuje odpowiednik w tablicy stanów.
  8. Krok 8. Pakiet trafia do Internetu. Teraz to zwykły pakiet IPv4. Podróżuje po globalnej sieci do docelowego serwera.
  9. Krok 9. Strona widzi IPv4. Serwer otrzymuje połączenie z publicznego adresu IPv4 operatora. W logach zapisuje właśnie ten IPv4. Oto moment prawdy: strona nigdy się nie dowie, że pakiet pierwotnie narodził się w środowisku IPv6.

Droga powrotna: od strony do telefonu

  1. Krok 10. Serwer odpowiada. Strona wysyła pakiet zwrotny IPv4 na ten publiczny adres, który zobaczyła.
  2. Krok 11. PLAT znajduje odpowiednik. Węzeł NAT64 zagląda do swojej tablicy stanów, określa, które urządzenie należy do połączenia, i odtwarza adres IPv6.
  3. Krok 12. Odwrotna translacja na IPv6. PLAT zamienia odpowiedź IPv4 na pakiet IPv6 i wysyła go przez rdzeń sieci z powrotem do telefonu.
  4. Krok 13. CLAT zwraca IPv4 aplikacji. Jeśli początkowo aplikacja działała przez IPv4, CLAT na urządzeniu transluje odpowiedź IPv6 z powrotem na IPv4 i przekazuje ją aplikacji przez wirtualny interfejs.
  5. Krok 14. Aplikacja otrzymuje odpowiedź. Dla aplikacji wszystko wygląda jak normalna wymiana IPv4. Koło się zamyka.

Zatrzymaj się na chwilę i doceni grację tej konstrukcji. Pakiet czterokrotnie zmienił tożsamość protokołu, przeszedł przez dwa translatory, a punkty końcowe – aplikacja i strona – nawet o tym nie wiedzą. Każde widzi tylko swój znajomy świat IPv4.

Co to wszystko oznacza dla proxy: gdzie rodzi się adres wyjściowy

Teraz zastosujmy całą teorię do praktyki mobilnych proxy. To najważniejsza sekcja dla tych, którzy pracują z ruchem.

Gdzie rodzi się adres wyjściowy

Mobilne proxy to w zasadzie punkt wejścia do sieci przez rzeczywiste urządzenie mobilne lub modem podłączony do operatora. Gdy kierujesz ruch przez takie proxy, wychodzi on do Internetu tak samo, jak wyszedłby ruch z telefonu.

A my już wiemy, co dzieje się z tym ruchem. Przechodzi przez 464XLAT, dociera do PLAT, a tam przypisywany jest mu publiczny adres IPv4 z puli operatora. To właśnie ten adres PLAT staje się adresem wyjściowym Twojego proxy. Rodzi się on nie na urządzeniu, nie na modemie, ale w węźle NAT64 w rdzeniu sieci operatora.

Dlatego właśnie wyjście mobilne ma zwykle IPv4. Samo urządzenie żyje w IPv6, ale punkt, z którego ruch wychodzi do globalnego Internetu w kierunku stron IPv4, to PLAT, oddający IPv4.

Co ostatecznie widzi docelowa strona

Docelowa strona widzi publiczny adres IPv4 operatora. To adres węzła CGN lub NAT64, za którym może kryć się wielu abonentów. Strona nie widzi ani wewnętrznego adresu IPv6 urządzenia, ani wirtualnego IPv4 interfejsu CLAT. Tylko zewnętrzny IPv4 PLAT.

To kluczowa kwestia. Mobilne proxy są cenione za to, że ich adresy IPv4 wyglądają jak adresy żywych abonentów – bo technicznie tak właśnie jest. Wielu rzeczywistych użytkowników dzieli ten sam publiczny IPv4 przez jeden PLAT. Z punktu widzenia docelowej strony taki adres jest nieodróżnialny od zwykłego klienta mobilnego.

Kiedy strona może zobaczyć IPv6

Ale nie zawsze adres wyjściowy będzie IPv4. Jeśli docelowa strona ma prawdziwy rekord AAAA i pełną infrastrukturę IPv6, urządzenie połączy się z nią bezpośrednio przez IPv6, omijając PLAT. W takim przypadku strona zobaczy adres IPv6 z podsieci przydzielonej abonentowi przez operatora.

Dlatego właśnie to samo mobilne proxy może oddawać różnym stronom różne typy adresów. Stronie bez IPv6 – publiczny IPv4 przez NAT64. Stronie z IPv6 – prawdziwy IPv6 bezpośrednio. To nie usterka, a normalne zachowanie systemu podwójnego stosu.

Lista kontrolna zrozumienia adresu wyjściowego

  • Urządzenie w sieci IPv6 – tak, prawie zawsze u dużych operatorów
  • Adres wyjściowy do strony IPv4 – publiczny IPv4 węzła PLAT operatora
  • Adres wyjściowy do strony IPv6 – prawdziwy IPv6 z podsieci abonenta
  • Gdzie następuje translacja – w PLAT w rdzeniu sieci, nie na urządzeniu
  • Co widzi strona IPv4 – wspólny adres IPv4 operatora, dzielony przez abonentów

Podwójny stos i happy eyeballs: dlaczego sprawdzanie pokazuje raz IPv4, raz IPv6

Z pewnością spotkałeś się z tym, że serwis sprawdzający IP przy ponownych żądaniach pokazuje różne adresy – raz IPv4, raz IPv6. To zastanawiające. Wyjaśnijmy, dlaczego tak się dzieje.

Czym jest podwójny stos

Podwójny stos oznacza, że urządzenie jednocześnie dysponuje adresem IPv4 i adresem IPv6 i może używać obu protokołów. W środowisku mobilnym często jest to realizowane przez APN IPv4v6 lub przez kombinację natywnego IPv6 plus CLAT, który daje lokalny IPv4.

Gdy klient ma wybór między dwoma protokołami, pojawia się pytanie: którego użyć do konkretnego połączenia? Dawniej rozwiązywano to topornie i prowadziło do opóźnień. Jeśli ścieżka IPv6 była uszkodzona, przeglądarka długo czekała na timeout, zanim przeszła na IPv4. Użytkownicy cierpieli z powodu wolnego ładowania.

Algorytm happy eyeballs

Aby rozwiązać ten problem, wymyślono algorytm happy eyeballs, co można przetłumaczyć jako szczęśliwe oczy. Jego sedno nie polega na zgadywaniu z góry, który protokół jest lepszy, ale na urządzeniu wyścigu.

Oto jak działa w ogólnym zarysie:

  1. Klient pyta o domenę zarówno o rekord A, jak i AAAA jednocześnie
  2. Po otrzymaniu adresów obu protokołów zaczyna nawiązywać połączenia prawie równolegle
  3. Próba IPv6 zwykle startuje jako pierwsza z niewielkim wyprzedzeniem kilkudziesięciu lub kilkuset milisekund
  4. Jeśli połączenie IPv6 nawiązuje się szybko, jest używane
  5. Jeśli IPv6 zwalnia lub nie odpowiada, klient niemal natychmiast przełącza się na IPv4
  6. Zwycięzca wyścigu jest używany do transmisji danych, przegrane połączenie jest zamykane

Algorytm preferuje IPv6, gdy działa dobrze, ale nie pozwala mu spowalniać pracy, jeśli coś pójdzie nie tak. Stąd nazwa – oczy pozostają szczęśliwe, ponieważ nie ma opóźnień.

Dlaczego sprawdzanie pokazuje różne adresy

Teraz widać, skąd bierze się niestałość. Gdy otwierasz serwis sprawdzający IP, dzieje się następująco:

  • Jeśli serwis ma zarówno rekord A, jak i AAAA, uruchamia się happy eyeballs
  • W zależności od tego, które połączenie wygrało wyścig w danym momencie, zobaczysz albo IPv4, albo IPv6
  • Stan sieci, obciążenie, pamięć podręczna połączeń – wszystko to wpływa na wynik wyścigu
  • Przy następnym żądaniu wyścig może zakończyć się inaczej i adres się zmieni

To nie błąd proxy ani niestabilność połączenia. To oczekiwane zachowanie podwójnego stosu sterowanego przez happy eyeballs. Jeśli potrzebujesz przewidywalnego wyniku, musisz wymusić wersję protokołu – o tym w następnej sekcji.

Praktyczna wskazówka

Wielu błędnie uważa, że mobilne proxy jest niestabilne, widząc skaczące adresy w serwisie sprawdzającym. W rzeczywistości to zdrowe zachowanie nowoczesnej sieci. Jeśli chcesz widzieć tylko wyjście IPv4, korzystaj z serwisów bez rekordu AAAA lub wymuś IPv4 na poziomie klienta. Wtedy obraz się ustabilizuje.

Praktyka: jak sprawdzić, jaki stos ma połączenie

Teoria bez praktyki jest martwa. Uzbrójmy się w konkretne polecenia, aby na własne oczy zobaczyć, co dzieje się z Twoim połączeniem. Wszystkie narzędzia są standardowe i dostępne w większości systemów.

Sprawdzamy adresy interfejsu

Pierwszą rzeczą, którą należy zrobić, jest sprawdzenie, jakie adresy są przypisane do interfejsów sieciowych. Dla IPv6 użyj polecenia:

  • ip -6 addr – pokazuje wszystkie adresy IPv6 na wszystkich interfejsach
  • ip -4 addr – analogicznie dla IPv4
  • ip addr – pokazuje wszystko naraz

Zwróć uwagę na typy adresów. Globalne adresy IPv6 zazwyczaj zaczynają się od 2000::/3. Lokalne adresy łącza zaczynają się od fe80 i nie są rutowane na zewnątrz. Jeśli widzisz globalny IPv6, urządzenie ma pełną łączność IPv6. Jeśli widzisz również prywatny IPv4 na osobnym interfejsie, to najprawdopodobniej interfejs CLAT.

Sprawdzamy osiągalność przez ping

Aby sprawdzić, czy konkretny protokół działa, pomocne jest ping:

  • ping6 adres lub ping -6 adres – sprawdzenie łączności przez IPv6
  • ping -4 adres – sprawdzenie łączności przez IPv4

Jeśli ping przez IPv6 do globalnego węzła przechodzi, oznacza to, że masz działającą łączność IPv6. Jeśli przechodzi tylko IPv4, to IPv6 albo nie jest skonfigurowany, albo nie działa.

Wymuszamy protokół w curl

Najpotężniejszym narzędziem diagnostycznym dla ruchu webowego jest curl z kluczami wymuszającymi wybór protokołu:

  • curl -4 adres – wymusza użycie tylko IPv4
  • curl -6 adres – wymusza użycie tylko IPv6
  • curl -v adres – tryb szczegółowy, pokazuje, pod jaki adres faktycznie się połączono

Łącząc klucze, możesz dokładnie dowiedzieć się, jaki adres widzi zdalna strona. Wyślij żądanie z kluczem -4 do serwisu zwracającego Twój IP, a zobaczysz czyste wyjście IPv4. Wyślij z -6 – zobaczysz IPv6, jeśli jest dostępny. W ten sposób oddzielasz wpływ happy eyeballs i widzisz rzeczywisty obraz dla każdego protokołu.

Sprawdzenie na punkcie końcowym tylko IPv6

Szczególnie cenną techniką jest zwrócenie się do serwisu dostępnego wyłącznie przez IPv6, bez żadnego rekordu A. Jeśli takie połączenie zostanie nawiązane, masz gwarantowaną natywną łączność IPv6, a nie tylko translację. Jeśli połączenie nie przechodzi nawet przy wymuszeniu -6, oznacza to, że nie ma rzeczywistego wyjścia IPv6 i cała Twoja aktywność IPv6 kręci się wokół prefiksu NAT64.

Praktyczny scenariusz sprawdzania:

  1. Wykonaj curl -6 na punkcie końcowym tylko IPv6 – sprawdzasz natywną łączność IPv6
  2. Wykonaj curl -4 na serwisie do określania IP – widzisz wyjściowy IPv4 przez PLAT
  3. Porównaj adresy – jeśli wyjście IPv6 pochodzi z podsieci abonenta, a IPv4 z puli operatora, oznacza to, że działa pełny podwójny stos z 464XLAT

Jak określić obecność prefiksu NAT64

Aby dowiedzieć się, czy Twoja sieć używa NAT64, możesz spojrzeć na syntetyzowane adresy. Zapytaj o rekord AAAA dla domeny, która na pewno nie ma IPv6, i spójrz na odpowiedź. Jeśli zwróci adres zaczynający się od 64:ff9b – to wyraźny znak działania DNS64 i NAT64. Niektóre systemy mają wbudowane mechanizmy wykrywania prefiksu NAT64, które właśnie tak działają: pytają o znaną nazwę i patrzą na strukturę odpowiedzi.

Lista kontrolna diagnostyki stosu

  • ip -6 addr – czy jest globalny IPv6
  • ip -4 addr – czy jest IPv4 i czy nie jest prywatnym adresem CLAT
  • ping -6 do globalnego węzła – czy działa łączność IPv6
  • curl -4 na serwis IP – jaki IPv4 widzi strona
  • curl -6 na punkt końcowy tylko IPv6 – czy jest natywny IPv6
  • AAAA zapytanie dla domeny tylko IPv4 – czy widoczny jest prefiks 64:ff9b

Zgodność: dlaczego podsieć /64 jest postrzegana jako jeden klient

Przechodzimy do kwestii, która ma ogromne znaczenie praktyczne dla wszystkich pracujących z wieloma kontami. Chodzi o to, jak platformy traktują połączenia IPv6.

Dlaczego niektóre platformy gorzej traktują IPv6

Historycznie wiele dużych platform budowało swoje systemy antyfraudowe i reputacji adresów wokół IPv4. Zgromadzone bazy danych, scoringi reputacyjne, reguły ograniczania częstotliwości – wszystko było dopasowane do 32-bitowych adresów. IPv6 przyszedł później i nie wszystkie systemy adaptowały się równie dobrze.

Jest też przyczyna strukturalna. W IPv4 każdy adres to deficytowy zasób, za którym zwykle stoi jeden węzeł lub węzeł za NAT. W IPv6 adresów jest tak wiele, że jeden klient może z łatwością zmieniać swój adres tysiąc razy na godzinę w obrębie swojej podsieci. To łamie utartą logikę, gdzie adres = identyfikator klienta.

Dlatego platformy wypracowały szczególne podejście do IPv6 i zrozumienie go jest krytyczne.

Jak traktowana jest podsieć /64

Przypomnij sobie, co mówiliśmy w sekcji o podstawach: operator przydziela każdemu abonentowi całą podsieć /64. To gigantyczna liczba adresów na jedno urządzenie.

Inteligentne systemy reputacji to rozumieją. Zamiast oceniać każdy pojedynczy adres IPv6, agregują całą podsieć /64 i traktują ją jako jeden identyfikator. Logika jest prosta: skoro cała ta podsieć należy do jednego abonenta, to należy traktować ją jak jednego klienta.

Oznacza to, że zmiana adresu IPv6 w obrębie jednej /64 nie tworzy nowego identyfikatora dla takich platform. Możesz tasować ostatnie bity adresu do woli, ale z punktu widzenia platformy to wciąż ten sam klient, ponieważ prefiks /64 się nie zmienia.

Co to oznacza dla pracy z wieloma kontami

Z tego wynika ważny praktyczny wniosek. Jeśli próbujesz rozdzielić konta na różne adresy IPv6 w obrębie jednej podsieci /64, dla zaawansowanych platform będą one wyglądać jak jeden klient. Różne adresy nie dają separacji, jeśli wspólny prefiks jest taki sam.

Porównaj to z zachowaniem IPv4 przez NAT64. Publiczny IPv4 węzła PLAT jest dzielony przez wielu różnych abonentów operatora. Z punktu widzenia platformy za jednym IPv4 stoi dziesiątki prawdziwych ludzi. Daje to zupełnie inny obraz mieszania ruchu.

Kluczowe wnioski dla wielokont:

  • Zmiana ostatnich bitów IPv6 w obrębie jednej /64 nie zmienia identyfikatora dla inteligentnych platform
  • Znaczącą jednostką dla IPv6 jest prefiks /64, a nie pojedynczy adres
  • Separacja powinna odbywać się na poziomie różnych podsieci /64, a nie adresów w obrębie jednej
  • IPv4 przez NAT64 miesza Cię z innymi abonentami operatora, co daje inną dynamikę reputacyjną
  • Zawsze rozumiej, jaki protokół jest faktycznie używany do połączenia z konkretną platformą

Praktyczne zalecenie dotyczące kontroli protokołu

Biorąc to wszystko pod uwagę, warto kontrolować, jakim protokołem łączysz się z docelową platformą. Jeśli wiesz na pewno, że potrzebujesz wyjścia IPv4 przez operatora komórkowego, wymuś IPv4 na poziomie klienta. Wtedy masz gwarancję, że otrzymujesz dzielony publiczny adres PLAT, a nie przypisaną do Twojego urządzenia podsieć IPv6.

Typowe błędy przy pracy z IPv6 w sieciach mobilnych

Teraz zbierzmy w jednym miejscu najczęstsze błędne przekonania i pomyłki. Przestudiuj je uważnie – każda z nich może zepsuć pracę lub doprowadzić do błędnych wniosków.

Błąd pierwszy: myślenie, że adres IPv6 na telefonie oznacza wyjście IPv6

Wielu widzi globalny IPv6 na interfejsie i wyciąga wniosek, że cały ruch idzie przez IPv6. W rzeczywistości ruch do stron IPv4 i tak zamienia się w IPv4 na PLAT. IPv6 na urządzeniu to transport wewnątrz sieci operatora, a nie gwarancja wyjścia IPv6 do konkretnej strony.

Błąd drugi: mylenie adresu wyjściowego z adresem interfejsu

Adres na interfejsie sieciowym urządzenia a adres widziany przez stronę to dwie różne rzeczy. Między nimi stoją CLAT i PLAT z translacją i NAT. Nigdy nie oceniaj adresu wyjściowego na podstawie tego, co pokazuje ip addr. Zawsze sprawdzaj na rzeczywistym zewnętrznym serwisie.

Błąd trzeci: panikowanie z powodu skaczących adresów w sprawdzaniu

Już wyjaśniliśmy, że happy eyeballs powoduje, że podwójny stos pokazuje raz IPv4, raz IPv6. To normalne. Nie traktuj tego jako oznaki uszkodzenia proxy. Jeśli potrzebujesz stabilności, wymuszaj protokół.

Błąd czwarty: myślenie, że zmiana IPv6 w obrębie /64 daje nowy identyfikator

To jeden z najdroższych błędów w wielokontach. Inteligentne platformy agregują całą /64. Zmiana ostatnich bitów adresu jest bezsensowna z punktu widzenia separacji kont. Znaczącą jednostką jest prefiks.

Błąd piąty: ignorowanie typu APN

Typ APN – IPv4, IPv6 lub IPv4v6 – bezpośrednio określa, co stanie się z ruchem. Nie rozumiejąc, jaki typ jest używany, pracujesz po omacku. Zawsze ustalaj konfigurację sesji.

Błąd szósty: testowanie łączności tylko jednym protokołem

Sprawdzając tylko IPv4 lub tylko IPv6, otrzymujesz niepełny obraz. Prawdziwa diagnostyka wymaga sprawdzenia obu protokołów oddzielnie za pomocą kluczy -4 i -6, a także odwołania się do punktu końcowego tylko IPv6.

Błąd siódmy: mylenie prefiksu NAT64 z prawdziwą stroną IPv6

Syntetyzowany adres z prefiksem 64:ff9b wygląda jak IPv6, ale za nim stoi serwer IPv4. Jeśli łączysz się pod taki adres, tak naprawdę idziesz przez NAT64 do serwera IPv4, a nie komunikujesz się z prawdziwym węzłem IPv6. Nie wyciągaj wniosków o obecności natywnego IPv6 u strony na podstawie faktu syntetyzowanego adresu.

Błąd ósmy: mylenie CLAT z PLAT

CLAT mieszka na urządzeniu i wykonuje translację bezstanową dla aplikacji. PLAT mieszka w sieci operatora i wykonuje translację stanową z NAT. To różne komponenty o różnych zadaniach. Pomylenie ich utrudnia zrozumienie, gdzie tak naprawdę rodzi się adres wyjściowy.

Narzędzia i zasoby do pracy ze stosem protokołów

Zbierzmy arsenał narzędzi, które pomogą Ci diagnozować i rozumieć stos sieciowy w środowisku mobilnym. Wszystkie są standardowe i nie wymagają egzotyki.

Wiersz poleceń

  • ip addr i jego warianty ip -4 addr, ip -6 addr – podstawowe narzędzie do przeglądania adresów interfejsów
  • ping i ping6 – sprawdzanie łączności według konkretnego protokołu
  • curl z kluczami -4 i -6 – główne narzędzie diagnostyczne połączeń webowych i sprawdzania adresu wyjściowego
  • traceroute i traceroute6 – trasowanie trasy, pomaga zobaczyć, przez które węzły idzie ruch
  • dig i nslookup – zapytania do DNS w celu sprawdzenia rekordów A i AAAA, wykrywanie syntetyzowanych adresów
  • ip route – przeglądanie tablicy routingu dla obu protokołów

Serwisy internetowe do sprawdzania

  • Serwisy do określania zewnętrznego IP – pokazują, co widzi zdalna strona
  • Punkty końcowe testowe tylko IPv6 – sprawdzają obecność natywnej łączności IPv6
  • Serwisy pokazujące oddzielnie IPv4 i IPv6 – pomagają zobaczyć podwójny stos
  • Narzędzia do sprawdzania wsparcia IPv6 u domeny – pokazują obecność rekordu AAAA

Diagnostyka DNS

Zapytania do DNS pomagają zrozumieć, czy działa DNS64. Zapytaj o rekord AAAA dla domeny, która nie ma IPv6, i spójrz na strukturę odpowiedzi. Obecność prefiksu 64:ff9b zdradza działanie syntezy. To najprostszy sposób, aby upewnić się o obecności mechanizmu NAT64 w sieci.

Ramy systemowej diagnostyki stosu

Proponuję krok po kroku ramę, którą warto wykonać przy pierwszym kontakcie z dowolną siecią mobilną:

  1. Inwentaryzacja adresów. Wykonaj ip addr, określ obecność globalnego IPv6 i charakter IPv4
  2. Określenie CLAT. Znajdź wirtualny interfejs z prywatnym IPv4 – to oznaka 464XLAT
  3. Sprawdzenie NAT64. Zapytaj o AAAA dla domeny tylko IPv4, szukaj prefiksu 64:ff9b
  4. Test natywnego IPv6. curl -6 na punkcie końcowym tylko IPv6
  5. Określenie wyjściowego IPv4. curl -4 na serwisie do określania IP
  6. Określenie wyjściowego IPv6. curl -6 na serwisie obsługującym IPv6
  7. Analiza zachowania podwójnego stosu. Zwykłe żądanie bez wymuszania protokołu, obserwacja happy eyeballs

Po przejściu wszystkich siedmiu kroków otrzymasz wyczerpujący obraz: jaki typ łączności ma sieć, czy działa translacja, jakie adresy widzą różne typy stron i jak zachowuje się podwójny stos. To Twój standardowy audyt.

Przypadki i wyniki: analiza rzeczywistych scenariuszy

Abstrakcyjna mechanika lepiej przyswaja się na konkretnych przykładach. Przeanalizujmy kilka typowych scenariuszy spotykanych w praktyce.

Przypadek pierwszy: strona w logach widzi jeden IPv4 dla wielu klientów

Sytuacja. Analityk przegląda logi strony i zauważa, że z jednego adresu IPv4 przychodzi ogromna liczba różnych użytkowników o różnym zachowaniu. Pierwsza myśl – to proxy lub botnet.

Analiza. W rzeczywistości to klasyczny publiczny IPv4 węzła NAT64 lub CGN dużego operatora komórkowego. Za jednym takim adresem rzeczywiście stoi dziesiątki i setki prawdziwych abonentów. Ich ruch wychodzi przez jeden PLAT. To nie anomalia, a standardowa praca 464XLAT w warunkach niedoboru IPv4.

Wniosek. Ocena klientów mobilnych wyłącznie na podstawie adresu IPv4 jest nieskuteczna. Jeden adres nie równa się jednemu użytkownikowi w środowisku mobilnym. To właśnie ta cecha sprawia, że mobilne adresy IPv4 są tak charakterystyczne – wysoka gęstość prawdziwych użytkowników za jednym adresem.

Przypadek drugi: zmienna odpowiedź serwisu sprawdzającego

Sytuacja. Operator mobilnego proxy skarży się, że serwis sprawdzający IP pokazuje raz IPv4, raz IPv6, i wyciąga wniosek o niestabilności proxy.

Analiza. Serwis sprawdzający ma zarówno rekord A, jak i AAAA. Klient działa w podwójnym stosie. Każde żądanie uruchamia happy eyeballs i w zależności od wyniku wyścigu połączeń zwracany jest inny typ adresu. Proxy działa absolutnie stabilnie, zmienia się tylko protokół wybrany przez algorytm.

Rozwiązanie. Wymuszenie protokołu przez curl -4 lub odpowiednie ustawienia klienta. Po ustaleniu IPv4 adres stał się przewidywalny. Problem niestabilności okazał się pozorny.

Przypadek trzeci: konta się zlepiły mimo różnych IPv6

Sytuacja. Praca z wieloma kontami przez IPv6, każdemu kontu przypisano osobny adres IPv6. Mimo to platforma powiązała konta ze sobą.

Analiza. Wszystkie przypisane adresy znajdowały się w obrębie jednej podsieci /64 przydzielonej operatorowi na urządzenie. Zaawansowany system reputacji zagregował całą /64 i potraktował ją jako jeden identyfikator. Różne adresy w obrębie jednego prefiksu nie dały żadnej separacji.

Wniosek. Dla IPv6 znaczącą jednostką jest prefiks /64, a nie pojedynczy adres. Separacja wymaga różnych prefiksów. W tym przypadku rozsądniej było pracować przez wyjście IPv4 NAT64, gdzie ruch miesza się z innymi abonentami operatora.

Przypadek czwarty: aplikacja, która nie obsługuje IPv6

Sytuacja. Stara aplikacja odwołuje się bezpośrednio do literału adresu IPv4 i w czystej sieci IPv6 powinna się zepsuć. Ale działa.

Analiza. Na urządzeniu działa CLAT. Aplikacja wysyła pakiet IPv4 na wirtualny interfejs, CLAT transluje go na IPv6, dalej pakiet idzie przez PLAT do Internetu IPv4. Aplikacja żyje w iluzji pełnoprawnego IPv4 i nie podejrzewa translacji. To dokładnie to zadanie, dla którego CLAT istnieje.

Wniosek. 464XLAT zapewnia zgodność dla starszych aplikacji w sposób przezroczysty. Dlatego przejście operatorów na IPv6 nie zepsuło ekosystemu oprogramowania IPv4.

FAQ: często zadawane pytania

Dlaczego mój telefon pokazuje IPv6, a strona w logach zapisuje IPv4?

Ponieważ podmiana następuje w węźle PLAT w rdzeniu sieci operatora. Urządzenie wysyła ruch przez IPv6, ale przy wyjściu do strony IPv4 węzeł NAT64 transluje pakiet na IPv4 i podstawia publiczny adres operatora. Strona widzi właśnie ten wyjściowy IPv4, a nie wewnętrzny IPv6 urządzenia.

Czym jest prefiks 64:ff9b i skąd się bierze?

To standaryzowany, powszechnie znany prefiks do translacji NAT64. DNS64 używa go do syntetyzowania sztucznych adresów IPv6 z adresów IPv4 stron bez rekordu AAAA. Ostatnie 32 bity takiego adresu zawierają prawdziwy IPv4, który PLAT wyodrębnia podczas translacji.

Czym różni się CLAT od PLAT?

CLAT działa na urządzeniu i wykonuje translację bezstanową IPv4 na IPv6 dla aplikacji potrzebujących IPv4. PLAT działa w sieci operatora i wykonuje translację stanową IPv6 na IPv4 z NAT, podstawiając publiczny adres. CLAT rozwiązuje zgodność na urządzeniu, PLAT – zgodność z Internetem IPv4.

Dlaczego serwis sprawdzający IP pokazuje różne adresy przy odświeżaniu?

Z powodu algorytmu happy eyeballs w środowisku podwójnego stosu. Jeśli serwis sprawdzający jest dostępny zarówno przez IPv4, jak i IPv6, klient uruchamia wyścig połączeń i w różnych momentach wygrywa inny protokół. To normalne zachowanie, a nie usterka. Wymuszaj protokół kluczem dla stabilnego wyniku.

Jak sprawdzić, czy mam prawdziwe wyjście IPv6, a nie tylko NAT64?

Zwróć się do punktu końcowego dostępnego wyłącznie przez IPv6, poleceniem curl -6. Jeśli połączenie zostanie nawiązane, masz natywną łączność IPv6. Jeśli nie przechodzi nawet przy wymuszeniu -6, oznacza to, że nie ma rzeczywistego wyjścia IPv6, a cała aktywność IPv6 kręci się wokół syntetyzowanego prefiksu NAT64.

Dlaczego zmiana adresu IPv6 nie pomaga w rozdzieleniu kont?

Ponieważ operator przydziela urządzeniu całą podsieć /64, a zaawansowane platformy agregują całą tę podsieć jako jeden identyfikator. Zmiana ostatnich bitów adresu nie zmienia prefiksu, więc dla platformy to wciąż ten sam klient. Znaczącą jednostką jest właśnie /64, a nie pojedynczy adres.

Dlaczego mobilne proxy ma zwykle wyjściowy IPv4, a nie IPv6?

Ponieważ większość docelowych stron nie ma infrastruktury IPv6, a ruch do nich przechodzi przez NAT64. Węzeł PLAT transluje pakiety na IPv4 i przypisuje publiczny adres operatora. Ten adres staje się wyjściowy. Do stron z prawdziwym rekordem AAAA proxy może wychodzić również przez IPv6 bezpośrednio.

Jak wymusić na kliencie użycie określonej wersji protokołu?

Na poziomie curl używaj kluczy -4 dla IPv4 i -6 dla IPv6. Wiele aplikacji i bibliotek ma podobne ustawienia preferencji protokołu. Można też zarządzać przez systemowe ustawienia priorytetu polityki adresów. To wyłącza niedeterminizm happy eyeballs i daje przewidywalne wyjście.

Co widzi docelowa strona przy połączeniu przez sieć mobilną?

Jeśli strona ma tylko IPv4, widzi publiczny adres IPv4 węzła NAT64 operatora, dzielony przez wielu abonentów. Jeśli strona ma prawdziwy IPv6, widzi adres IPv6 z podsieci przydzielonej abonentowi. Wewnętrznych adresów urządzenia ani wirtualnego adresu CLAT strona nigdy nie widzi.

Czy typ APN ma wpływ na to, jaki adres zobaczy strona?

Pośrednio tak. Typ APN określa, które protokoły są dostępne dla urządzenia. Przy IPv4v6 lub czystym IPv6 z CLAT działa cała opisana mechanika translacyjna. Przy APN czysto IPv4 translacja nie jest potrzebna, ale taki wariant u dużych operatorów występuje rzadko z powodu niedoboru adresów.

Podsumowanie: najważniejsze o mechanice IPv6 w sieciach mobilnych

Przeszliśmy długą drogę. Zaczęliśmy od zagadki – telefon w IPv6, a strona widzi IPv4 – i całkowicie ją rozwiązaliśmy. Utrwalmy kluczowe wnioski.

Po pierwsze i najważniejsze. Niedobór adresów IPv4 zmusił operatorów do przejścia na IPv6. Urządzenia żyją w środowisku IPv6, często bez żadnego publicznego IPv4 na interfejsie radiowym. Zgodność ze starym Internetem IPv4 zapewnia technologia 464XLAT.

Po drugie. 464XLAT składa się z dwóch translatorów. CLAT na urządzeniu zamienia ruch IPv4 aplikacji na IPv6. PLAT w sieci operatora zamienia IPv6 z powrotem na IPv4 i przypisuje publiczny adres. To właśnie w PLAT rodzi się wyjściowy adres IPv4, który widzi strona.

Po trzecie. NAT64 i DNS64 działają w parze. DNS64 syntetyzuje adresy IPv6 z adresów IPv4 dla stron bez rekordu AAAA, używając prefiksu 64:ff9b. NAT64 w osobie PLAT dostarcza pakiety pod te adresy do rzeczywistych serwerów IPv4. Razem sprawiają, że cały Internet IPv4 jest dostępny dla urządzenia czysto IPv6.

Po czwarte. Podwójny stos i happy eyeballs wyjaśniają, dlaczego sprawdzanie pokazuje raz jeden protokół, raz drugi. Klient urządza wyścig połączeń i wybiera zwycięzcę. Dla stabilności wymuszaj protokół kluczami -4 lub -6.

Po piąte. Dla wielokont krytyczne jest zrozumienie: podsieć /64 jest postrzegana przez inteligentne platformy jako jeden klient. Zmiana adresu w obrębie jednej /64 jest bezużyteczna dla separacji. IPv4 przez NAT64 przeciwnie, miesza Cię z innymi abonentami operatora.

Jakie są kolejne kroki? Wprowadź zasadę przeprowadzania systematycznej diagnostyki stosu w każdej nowej sieci mobilnej według naszej ramy siedmiu kroków. Opanuj curl z kluczami -4 i -6 jako główne narzędzie. Zawsze sprawdzaj adres wyjściowy na rzeczywistym zewnętrznym serwisie, a nie po interfejsie urządzenia. I pamiętaj o różnicy między tym, gdzie mieszka urządzenie, a tym, skąd ruch faktycznie wychodzi do Internetu.

Zrozumienie tej mechaniki zmienia Cię z użytkownika, który dziwi się skaczącym adresom, w inżyniera, który dokładnie wie, co dzieje się z każdym pakietem. A wiedza, jak wiadomo, to kontrola. Niech ten artykuł będzie Twoją ściągawką dotyczącą IPv6 w sieciach mobilnych. Wracaj do niego za każdym razem, gdy napotkasz kolejną sieciową zagadkę – i przestanie być zagadką.