Makale içeriği

Garip bir senaryo düşünün. Telefonunuzda IP kontrol servisini açıyorsunuz ve size bir IPv4 adresi gösteriyor. Ancak aynı cihazın ağ arayüzü ayarlarına baktığınızda, uzun bir IPv6 adresi görüyorsunuz. Nasıl oluyor? Cihaz IPv6 dünyasında yaşıyor, ama site loglarında emin adımlarla dört noktalı ondalık sayıyı yazıyor. Peki bu değişim nerede gerçekleşti?

Bu bir hata veya sihir değil. Operatörlerin on yılı aşkın süredir dünya çapında uyguladığı, titizlikle tasarlanmış bir çevrim sistemidir. Mobil proxy'ler, veri kazıma, çoklu hesap yönetimi ile uğraşıyorsanız veya trafiğinize ne olduğunu anlamak istiyorsanız, bu mekaniği kavramak kritik öneme sahiptir.

Bu rehberde, paketin telefondaki uygulamadan hedef siteye kadar olan tüm yolculuğunu adım adım izleyeceğiz. 464XLAT'i bileşenlerine ayıracak, NAT64 ve DNS64'ün rolünü anlayacak, çıkış IPv4 adresinin tam olarak nerede oluştuğunu görecek ve bağlantı yığınını kendi ellerinizle teşhis etmeyi öğreneceksiniz. Bu yüzeysel bir inceleme değil. Sadece ne olduğunu değil, nasıl ve neden olduğunu da bilmek isteyenler için derin bir dalıştır.

Giriş: Telefon neden IPv6 alırken site IPv4 görüyor?

Paradoksun özüyle başlayalım. Büyük bir operatörün mobil ağındaki modern bir akıllı telefon neredeyse kesinlikle IPv6 üzerinden bağlanır. Dahası, çoğu zaman radyo arayüzünde gerçek bir IPv4 adresi yoktur. Operatör bunu vermez. Bu, adres alanının katı kıtlığından kaynaklanan bilinçli bir karardır.

Ancak internet homojen değildir. Çok sayıda site, API ve hizmet hâlâ yalnızca IPv4 üzerinden erişilebilir. DNS'lerinde AAAA kaydı yoktur, sunucuları IPv6 dinlemez. Telefon yalnızca IPv6 konuşabiliyorsa, internetin yarısını açamaz. Bir çelişki ortaya çıkar: cihaz yeni bir dil konuşur, muhatap ise yalnızca eski dili anlar.

Bu çelişkinin çözümü, konuşmamızın ana konusudur. 464XLAT adı verilen teknoloji, NAT64 ve DNS64 mekanizmalarıyla birlikte görünmez bir köprü oluşturur. Cihaz paketleri IPv6 ile gönderir, operatör ağının derinliklerinde bu paketler IPv4'e dönüştürülür ve gerçek bir IPv4 adresiyle hedef sunucuya ulaşır. Sunucu yanıt verir ve dönüş yolu aynı dönüşümü ayna görüntüsünde gerçekleştirir.

Bu nedenle hedef site IPv4 görür. Bu nedenle, gerçek bir telefon veya operatör modemine dayalı bir mobil proxy, dışarıya IPv4 adresi verirken, cihazın içinde IPv6 hüküm sürer. Değişim ne telefonda ne de sitede olur. Operatör ağında PLAT adı verilen bir ara düğümde gerçekleşir.

Sonuna kadar okuduğunuzda öğrenecekleriniz:

  • IPv4 adres kıtlığının nasıl işlediği ve operatörleri neden IPv6'ya geçmeye zorladığı
  • APN türlerinin ne olduğu ve IPv4v6'nın saf IPv6'dan farkı
  • 464XLAT'in adım adım nasıl çalıştığı, CLAT ve PLAT'ın nerede olduğu
  • NAT64 ve DNS64'ün AAAA kaydı olmayan bir siteyi nasıl erişilebilir kıldığı
  • Mobil proxy'nin çıkış IPv4 adresinin nereden geldiği
  • Happy eyeballs'ın IP kontrol servisinin neden bazen IPv4 bazen IPv6 göstermesine yol açtığı
  • Bağlantı yığınını teşhis etmek için pratik komutlar
  • /64 alt ağının neden tek bir istemci olarak algılandığı ve bunun hesaplar için anlamı

Hemen sınırları belirleyelim. Yalnızca ağ mekaniğinden bahsediyoruz. Ne satın almanın daha avantajlı olduğunu ne de hangi protokolün ticari açıdan daha iyi olduğunu tartışmıyoruz. Bu bir mühendislik rehberidir, pazar incelemesi değil.

Temeller: IPv4 kıtlığı, IPv6'ya geçiş ve APN türleri

Tüm yapıyı anlamak için temelden başlayalım. Temel ise tek bir şey: IPv4 adreslerinin feci şekilde yetersiz olması.

IPv4 neden bitti?

IPv4 protokolü 32 bitlik adresler kullanır. Bu, yaklaşık 4,3 milyar benzersiz kombinasyon sağlar. 1981'de protokol standartlaştırıldığında bu astronomik bir sayı gibi görünüyordu. Cihaz sayısının gezegendeki insan sayısını geçeceğini kim tahmin edebilirdi?

Gerçeklik acımasızdı. Akıllı telefonlar, tabletler, akıllı saatler, buzdolapları, kameralar, arabalar... hepsi adres istiyor. 2010'ların başında bölgesel internet kayıt kuruluşları boş blokları tüketmeye başladı. Bugün büyük bir beyaz IPv4 bloğu almak neredeyse imkansız ve ikincil piyasada adres başına onlarca dolar ödeniyor.

On milyonlarca abonesi olan bir mobil operatör için bu temel bir sorundur. Her akıllı telefona kişisel bir genel IPv4 vermek fiziksel olarak imkansızdır. Adresler yeterli değildir.

IPv6 sorunu nasıl çözüyor?

IPv6 protokolü 128 bitlik adresler kullanır. Olası kombinasyonların sayısı o kadar büyüktür ki insan beyni bunu algılayamaz - yaklaşık 340 undesilyon adres. Kabaca söylemek gerekirse, Dünya yüzeyindeki her atoma birkaç adres verebilir ve yine de artar.

Operatör, kayıt kuruluşundan devasa bir IPv6 bloğu alır ve abonelere muazzam bir bollukla dağıtır. Tipik uygulama, her abone cihazına tam bir /64 alt ağı vermektir. Bu, bir telefon için 18 kentilyon adres demektir. Bu bilgiyi aklınızda tutun; çoklu hesap bölümünde önemli rol oynayacak.

APN nedir ve türleri neden önemlidir?

APN, Access Point Name (Erişim Noktası Adı) anlamına gelir. Bu, telefona operatörün paket ağına nasıl bağlanacağını bildiren bir yapılandırma profilidir. Akıllı telefon veri bağlantısı kurduğunda, ağdan belirli bir protokol türüyle oturum oluşturmasını ister.

Üç ana PDN veya PDP bağlam türü vardır:

  • IPv4 - cihaza yalnızca IPv4 adresi atanır. Klasik eski düzen. Çalışır, ancak olmayan adresler gerektirir.
  • IPv6 - cihaza yalnızca IPv6 öneki atanır. Arayüzde hiç IPv4 yoktur. Operatör için maksimum tasarruf sağlar.
  • IPv4v6 - çift yığın. Cihaz, tek bir oturum içinde her iki tür adresi de ister.

İşte burada bir incelik var. Telefon IPv4v6 istese bile, operatör yalnızca IPv6 kısmını verebilir, IPv4 kısmını reddedebilir veya çevrim mekanizması aracılığıyla özel bir adres verebilir. Birçok büyük operatör, abonenin varsayılan olarak saf IPv6 almasını ve IPv4 internet uyumluluğunun daha önce açıklanan 464XLAT teknolojisi ile sağlanmasını sağlayacak şekilde yapılandırılmıştır.

Yardımcı bir benzetme. Dünyanın yeni bir iletişim diline geçtiğini, ancak birçok eski kurumun belgeleri yalnızca eski dilde kabul ettiğini düşünün. Devlet her vatandaşa kişisel bir eski pasaport veremez - yeterli değildir. Bu nedenle herkese yeni belgeler verir ve eski kurumların girişine bir tercüman koyar. Bu tercüman 464XLAT'tir.

Derinlemesine İnceleme: Bileşenlere Göre 464XLAT

Artık teknolojinin kendisini incelemeye hazırız. 464XLAT adı four-six-four translation (dört-altı-dört çevirisi) olarak okunur. Rakamlar özü yansıtır: paket, uygulama içinde IPv4 olarak başlar, ağ üzerinde IPv6 olarak seyahat eder ve çıkışta tekrar IPv4 olur. XLAT, translation (çeviri) kelimesinin kısaltmasıdır.

Temel, IETF spesifikasyonlarında açıklanan protokoller arası adres çevirisi standardıdır. Ancak 464XLAT, buna birlikte çalışan iki bileşenli bir mimari ekler.

CLAT - Cihazdaki çevirmen

CLAT, Customer-side translator (müşteri tarafı çevirmeni) anlamına gelir. Doğrudan akıllı telefonunuzda, işletim sistemine gömülü olarak yaşar. Android'de bu işlevi özel bir arka plan programı yerine getirir, diğer sistemlerde benzer modüller vardır.

CLAT'ın tek bir önemli görevi vardır. Telefondaki bir uygulama IPv4 üzerinden paket göndermek istediğinde - örneğin, doğrudan IPv4 soketi kullanıyorsa veya bir IP adresine doğrudan bağlanıyorsa - CLAT bu IPv4 paketini yakalar ve IPv6'ya sarar. Teknik olarak, durum bilgisi olmayan çeviri algoritması (stateless translation) ile başlıkları çevirir, kaynak ve hedef IPv4 adreslerini önceden bilinen bir öneki kullanarak ilgili IPv6 adreslerine dönüştürür.

CLAT, cihazda özel bir IPv4 adresi atanmış sanal bir ağ arayüzü oluşturur. Uygulamalar bu adresi görür ve normal bir IPv4 ortamında yaşadıklarını düşünür. Perde arkasında her şeyin çoktan IPv6'ya taşındığından habersizdirler.

PLAT - Operatör ağındaki çevirmen

PLAT, Provider-side translator (sağlayıcı tarafı çevirmeni) anlamına gelir. Operatör ağının çekirdeğinde bir yerde bulunan ve NAT64 işlevini uygulayan güçlü bir düğümdür. Son dönüşüm burada gerçekleşir.

PLAT, cihazdan gelen IPv6 paketlerini alır ve bunlardan orijinal IPv4 hedefi hakkında bilgi çıkarır. Ardından durum bilgisi olan (stateful) çeviri yapar: IPv6 paketini tekrar IPv4 paketine dönüştürür, kaynak adres olarak kendi havuzundaki operatörün genel IPv4 adreslerinden birini koyar ve paketi normal IPv4 internetine gönderir.

Anahtar kelime stateful, yani durum bilgisini koruyarak. PLAT, sunucudan gelen geri dönüş paketlerinin bağlantıyı başlatan cihaza doğru şekilde ulaşması için bir eşleme tablosu tutar. Bu, temelde klasik NAT ile aynı prensiptir, ancak farklı protokoller arasında gerçekleşir.

Neden iki çevirmen?

Mantıklı bir soru: PLAT her şeyi çevirecekken neden cihazda CLAT'a ihtiyaç var? Cevap, IPv6'yı bilmeyen uygulamalardır.

Birçok uygulama, IPv4'ü sıkı bir şekilde kullanacak şekilde yazılmıştır. IPv4 soketi isterler, IPv4 adres sabitleriyle çalışırlar, hatta bazı eski protokoller IP adreslerini yükün içinde taşır. Cihazda yalnızca saf IPv6 olsaydı, bu uygulamalar bozulurdu. CLAT, onlara tam teşekküllü bir IPv4 ortamı yanılsaması verirken görünmez kalır.

Böylece, ikili şu şekilde çalışır: CLAT cihazdaki uyumluluk sorununu çözer, PLAT internet uyumluluk sorununu çözer. Birlikte kesintisiz bir köprü oluştururlar.

NAT64 ve DNS64: AAAA Kaydı Olmayan Bir Site Nasıl Canlanır?

Paket çevirisini anladık. Ancak temel bir sorun daha var: cihaz, hedef site yalnızca IPv4 dünyasında mevcutsa ve herhangi bir IPv6 kaydı yoksa, IPv6 paketini nereye göndereceğini nasıl bilir?

İşte burada NAT64 ve DNS64 ikilisi sahneye çıkar. Yakın bir işbirliği içinde çalışırlar ve birini diğeri olmadan anlamak imkansızdır.

Eksik AAAA kaydı sorunu

Alan adı sisteminde farklı protokollerin adresleri farklı kayıt türlerinde saklanır. IPv4 adresi A türü kayıtta saklanır. IPv6 adresi AAAA (quad-A olarak telaffuz edilir) türü kayıtta saklanır.

Saf bir IPv6 cihazı bir siteyi açmak istediğinde, DNS'den AAAA kaydı ister. Ancak sitenin IPv6 altyapısı yoksa, AAAA kaydı da yoktur. Yalnızca IPv4 adresini içeren bir A kaydı vardır. Cihaz boş bir yanıt alır ve teoride sitenin erişilemez olduğunu söylemelidir. Ancak DNS64 sayesinde bu olmaz.

DNS64 nasıl çalışır?

DNS64, süper gücü olan özel bir operatör DNS çözümleyicisidir. Cihaz bir alan adı için AAAA kaydı istediğinde ve gerçek bir AAAA kaydı yoksa, DNS64 pes etmez. Şunları yapar:

  1. Yetkili sunucudan normal A kaydını ister ve sitenin IPv4 adresini alır
  2. Bu IPv4 adresini alır ve ondan yapay bir AAAA kaydı sentezler
  3. Sentez için, 32 bit IPv4 adresini özel bir IPv6 önekinin içine yerleştirir
  4. Bu sentezlenmiş AAAA kaydını hiçbir şey olmamış gibi cihaza döndürür

Cihaz geçerli bir IPv6 adresi alır ve sevinçle paketleri o adrese gönderir. Bu adresin yapay olduğunu bilmez ve bilmesi de gerekmez.

Sentezlenmiş önek 64:ff9b::/96

İşte tüm sistemin en tanınabilir yapıtlarından birine geldik. Adresleri sentezlemek için özel olarak ayrılmış 64:ff9b::/96 öneki kullanılır. Buna Well-Known Prefix (İyi Bilinen Önek) denir ve tam olarak NAT64 çevirisi için standartlaştırılmıştır.

Mekanik basit ve zariftir. Önek, adresin ilk 96 bitini kaplar. Kalan 32 bit, tam olarak IPv4 adresinin boyutudur. DNS64, sitenin IPv4 adresini önekin sonuna ekler.

Örneğin, sitenin IPv4 adresi dört sayı ile ifade ediliyorsa, sentezlenmiş IPv6 adresi 64:ff9b öneki ve ardından son 32 bitte kodlanmış bu dört sayı olarak görünür. Böyle bir paket PLAT'a ulaştığında, düğüm tanıdık öneki görür, bunun bir NAT64 çevirisi olduğunu anlar, son 32 biti çıkarır ve gerçek IPv4 hedef adresini elde eder. Ardından normal bir IPv4 paketi gönderir.

Bazı operatörler, iyi bilinen önek yerine kendi adres alanlarından özel bir ağ öneki kullanır. Mantık aynıdır, yalnızca ilk bitlerin değeri değişir.

İkili birlikte nasıl çalışır?

Yapbozu birleştirelim. DNS64, cihazın IPv4 internetine gitmek için bir IPv6 adresi almasını sağlamaktan sorumludur. PLAT şeklindeki NAT64, bu adresteki paketin gerçek IPv4 sunucusuna ulaşmasını sağlamaktan sorumludur. Biri diğeri olmadan işe yaramaz: DNS64, yalnızca NAT64'ün işleyebileceği bir adres oluşturur ve NAT64 yalnızca DNS64'ün sentezlediği adresleri işler.

Peki ya gerçek AAAA kaydı olan siteler? Burada işler daha basittir. DNS64 gerçek bir AAAA kaydı görür ve herhangi bir sentez yapmadan olduğu gibi iletir. Cihaz, tüm çevrim mekanizmasını atlayarak doğrudan IPv6 üzerinden siteye bağlanır. Bu, en uygun uçtan uca yoldur.

464XLAT ile Paketin Uygulamadan Siteye Yolculuğu: Sözlü Şema

Tüm mekanizmayı tek bir adım adım şemada birleştirme zamanı. Bir paketi, bir uygulamada doğduğu andan hedef IPv4 sunucusuna varana ve geri dönene kadar takip edelim. Bu, mobil proxy trafiğinin izlediği yoldur.

Gidiş yolu: Telefondan siteye

  1. Adım 1. Uygulama bağlanmak ister. Telefondaki uygulama, yalnızca IPv4'ü olan bir siteyi açmaya karar verir. Adres için DNS'e başvurur.
  2. Adım 2. DNS64 adresi sentezler. Operatörün çözümleyicisi gerçek bir AAAA kaydı bulamaz, A kaydını alır, IPv4 adresini 64:ff9b::/96 önekine yerleştirir ve sentezlenmiş bir AAAA kaydı döndürür.
  3. Adım 3. Uygulama paketi gönderir. İki seçenek vardır. Uygulama IPv6 ile çalışıyorsa, doğrudan sentezlenmiş adrese bir IPv6 paketi gönderir. Uygulama IPv4'e sıkı sıkıya bağlıysa, CLAT'ın sanal arayüzüne bir IPv4 paketi gönderir.
  4. Adım 4. CLAT, IPv4'ü IPv6'ya çevirir. IPv4 uygulaması durumunda, CLAT arka plan programı paketi yakalar ve durum bilgisi olmayan çeviri kurallarına göre aynı NAT64 öneki kullanarak onu bir IPv6 paketine dönüştürür.
  5. Adım 5. Paket radyo ağı üzerinden uçar. Artık bu saf bir IPv6 paketidir. Baz istasyonu ve operatörün mobil ağ çekirdeğinden geçer. Tüm radyo kısmının içinde yalnızca IPv6 yaşar.
  6. Adım 6. Paket PLAT'a ulaşır. Ağ çekirdeğinde, NAT64 işlevine sahip PLAT düğümü bulunur. Paketi, hedefi NAT64 öneki ile başlayan bir paket olarak görür.
  7. Adım 7. PLAT, IPv6'yı IPv4'e çevirir. Düğüm, hedef adresin son 32 bitini çıkarır - bu sitenin gerçek IPv4 adresidir. Ardından kaynak olarak kendi havuzundan bir genel IPv4 koyar, eşlemeyi durum tablosuna kaydeder.
  8. Adım 8. Paket internete çıkar. Artık bu normal bir IPv4 paketidir. Küresel ağ üzerinden hedef sunucuya gider.
  9. Adım 9. Site IPv4 görür. Sunucu, operatörün genel IPv4 adresinden bir bağlantı alır. Loglarına tam olarak bu IPv4'ü yazar. İşte gerçek an: site, paketin aslında bir IPv6 ortamında doğduğunu asla bilemez.

Dönüş yolu: Siteden telefona

  1. Adım 10. Sunucu yanıt verir. Site, gördüğü genel adrese bir yanıt IPv4 paketi gönderir.
  2. Adım 11. PLAT eşleşmeyi bulur. NAT64 düğümü durum tablosuna bakar, bağlantının hangi cihaza ait olduğunu belirler ve IPv6 adresini geri yükler.
  3. Adım 12. IPv6'ya ters çeviri. PLAT, IPv4 yanıtını bir IPv6 paketine dönüştürür ve ağ çekirdeği üzerinden telefona geri gönderir.
  4. Adım 13. CLAT, uygulamaya IPv4'ü geri verir. Başlangıçta uygulama IPv4 ile çalışıyorsa, cihazdaki CLAT, IPv6 yanıtını tekrar IPv4'e çevirir ve sanal arayüz aracılığıyla uygulamaya iletir.
  5. Adım 14. Uygulama yanıtı alır. Uygulama için her şey normal bir IPv4 değişimi gibi görünür. Döngü tamamlanmıştır.

Bir saniye durun ve bu yapının zerafetini takdir edin. Paket, protokol kimliğini dört kez değiştirdi, iki çevirmenden geçti ve uç noktalar - uygulama ve site - bunun farkında bile olmadı. Her biri yalnızca kendi tanıdık IPv4 dünyasını gördü.

Tüm Bunların Proxy'ler İçin Anlamı: Çıkış Adresi Nerede Doğuyor?

Şimdi tüm teoriyi mobil proxy pratiğine uygulayalım. Trafikle çalışanlar için en önemli bölüm budur.

Çıkış adresi nerede doğuyor?

Mobil proxy, aslında operatöre bağlı gerçek bir mobil cihaz veya modem aracılığıyla ağa bir giriş noktasıdır. Trafiği böyle bir proxy üzerinden yönlendirdiğinizde, telefondan çıkan trafikle aynı şekilde internete çıkar.

Ve bu trafiğe ne olduğunu biliyoruz. 464XLAT'ten geçer, PLAT'a ulaşır ve orada operatörün havuzundan bir genel IPv4 adresi atanır. PLAT'ın bu adresi, proxy'nizin çıkış adresi olur. Cihazda değil, modemde değil, operatör ağının çekirdeğindeki NAT64 düğümünde doğar.

Bu nedenle mobil çıkış genellikle IPv4'tür. Cihazın kendisi IPv6'da yaşar, ancak trafiğin IPv4 sitelerine küresel internete çıktığı nokta, IPv4 veren PLAT'tır.

Hedef site sonuçta ne görür?

Hedef site, operatörün genel IPv4 adresini görür. Bu, arkasında birçok abonenin gizlenebileceği bir CGN veya NAT64 düğümünün adresidir. Site, ne cihazın dahili IPv6 adresini ne de CLAT arayüzünün sanal IPv4'ünü görür. Yalnızca PLAT'ın harici IPv4'ünü görür.

Bu kritik bir noktadır. Mobil proxy'ler, IPv4 adreslerinin canlı abonelerin adresleri gibi görünmesi nedeniyle değerlidir - çünkü teknik olarak öyledir. Çok sayıda gerçek kullanıcı, aynı genel IPv4'ü tek bir PLAT üzerinden paylaşır. Hedef sitenin bakış açısından böyle bir adres, sıradan bir mobil istemciden ayırt edilemez.

Site ne zaman IPv6 görebilir?

Ancak çıkış adresi her zaman IPv4 olmayacaktır. Hedef sitenin gerçek bir AAAA kaydı ve tam teşekküllü bir IPv6 altyapısı varsa, cihaz PLAT'ı atlayarak doğrudan IPv6 üzerinden bağlanır. Bu durumda site, operatör tarafından aboneye tahsis edilen alt ağdan bir IPv6 adresi görür.

Bu nedenle aynı mobil proxy, farklı sitelere farklı türde adresler verebilir. IPv6'sı olmayan bir siteye NAT64 üzerinden genel IPv4; IPv6'sı olan bir siteye doğrudan gerçek IPv6. Bu bir arıza değil, çift yığın sisteminin normal davranışıdır.

Çıkış adresini anlamak için kontrol listesi

  • Cihaz IPv6 ağında - evet, büyük operatörlerde neredeyse her zaman
  • IPv4 sitesine çıkış adresi - operatörün PLAT düğümünün genel IPv4'ü
  • IPv6 sitesine çıkış adresi - abone alt ağından gerçek IPv6
  • Çeviri nerede gerçekleşir - ağ çekirdeğindeki PLAT'ta, cihazda değil
  • IPv4 sitesi ne görür - aboneler arasında paylaşılan operatörün ortak IPv4 adresi

Çift Yığın ve Happy Eyeballs: Kontrol Neden Bazen IPv4 Bazen IPv6 Gösteriyor?

Muhtemelen IP kontrol servisinin tekrarlanan sorgularda farklı adresler gösterdiğini görmüşsünüzdür - bazen IPv4, bazen IPv6. Bu kafa karıştırıcıdır. Nedenini inceleyelim.

Çift yığın nedir?

Çift yığın, cihazın aynı anda hem IPv4 hem de IPv6 adresine sahip olması ve her iki protokolü de kullanabilmesi anlamına gelir. Mobil ortamda bu genellikle IPv4v6 APN veya yerel IPv6 artı yerel IPv4 sağlayan CLAT kombinasyonu ile gerçekleştirilir.

İstemcinin iki protokol arasında seçim yapması gerektiğinde, hangisini kullanacağı sorusu ortaya çıkar. Eskiden bu kaba bir şekilde çözülürdü ve gecikmelere yol açardı. IPv6 yolu bozuksa, tarayıcı IPv4'e geçmeden önce zaman aşımını beklerdi. Kullanıcılar yavaş yüklemeden muzdaripti.

Happy eyeballs algoritması

Bu sorunu çözmek için happy eyeballs (mutlu gözler) algoritması geliştirildi. Temel fikri, hangi protokolün daha iyi olduğunu önceden tahmin etmek yerine bir yarış düzenlemektir.

Genel hatlarıyla şu şekilde çalışır:

  1. İstemci, alan adı için aynı anda hem A hem de AAAA kaydını ister
  2. Her iki protokolün adreslerini aldıktan sonra, neredeyse paralel olarak bağlantı kurmaya başlar
  3. IPv6 denemesi genellikle birkaç on veya yüz milisaniyelik küçük bir avantajla ilk başlar
  4. IPv6 bağlantısı hızlı kurulursa, o kullanılır
  5. IPv6 yavaşsa veya yanıt vermiyorsa, istemci neredeyse anında IPv4'e geçer
  6. Yarışın galibi veri iletimi için kullanılır, kaybeden bağlantı kapatılır

Algoritma, IPv6 iyi çalıştığında onu tercih eder, ancak bir sorun varsa işi yavaşlatmasına izin vermez. Adı da buradan gelir - gecikme olmadığı için gözler mutlu kalır.

Kontrol neden farklı adresler gösteriyor?

Şimdi tutarsızlığın nereden geldiği anlaşılıyor. IP kontrol servisini açtığınızda şunlar olur:

  • Servisin hem A hem de AAAA kaydı varsa, happy eyeballs devreye girer
  • Hangi bağlantının yarışı kazandığına bağlı olarak, o anda ya IPv4 ya da IPv6 görürsünüz
  • Ağ durumu, yük, bağlantı önbelleği - bunların hepsi yarışın sonucunu etkiler
  • Bir sonraki sorguda yarış farklı sonuçlanabilir ve adres değişir

Bu, proxy'nin hatası veya bağlantı kararsızlığı değildir. Happy eyeballs yönetimindeki çift yığının beklenen davranışıdır. Tahmin edilebilir bir sonuç istiyorsanız, protokol sürümünü zorla sabitlemelisiniz - bunu bir sonraki bölümde ele alacağız.

Pratik içgörü

Birçok kişi, kontrol servisinde zıplayan adresler gördüğünde mobil proxy'nin kararsız olduğunu düşünerek hata yapar. Oysa bu, modern ağın sağlıklı bir davranışıdır. Yalnızca IPv4 çıkışını görmek istiyorsanız, AAAA kaydı olmayan servislere yönelin veya istemci düzeyinde IPv4'ü zorlayın. O zaman tablo stabilize olur.

Pratik: Bağlantı Yığını Nasıl Görülür?

Teori pratik olmadan ölüdür. Şimdi somut komutlarla donanalım ve bağlantınıza ne olduğunu kendi gözlerinizle görelim. Tüm araçlar standarttır ve çoğu sistemde mevcuttur.

Arayüz adreslerine bakalım

Yapılacak ilk şey, ağ arayüzlerine hangi adreslerin atandığını görmektir. IPv6 için şu komutu kullanın:

  • ip -6 addr - tüm arayüzlerdeki tüm IPv6 adreslerini gösterir
  • ip -4 addr - IPv4 için benzer
  • ip addr - hepsini birden gösterir

Adres türlerine dikkat edin. Küresel IPv6 adresleri genellikle 2000::/3 ile başlar. Yerel bağlantı adresleri fe80 ile başlar ve dışarıya yönlendirilmez. Küresel bir IPv6 görüyorsanız, cihazınız tam teşekküllü IPv6 bağlantısına sahiptir. Ayrı bir arayüzde özel bir IPv4 de görüyorsanız, bu büyük olasılıkla CLAT arayüzüdür.

Ping ile erişilebilirliği kontrol edin

Belirli bir protokolün çalışıp çalışmadığını ping ile kontrol edebilirsiniz:

  • ping6 adres veya ping -6 adres - IPv6 bağlantısını kontrol eder
  • ping -4 adres - IPv4 bağlantısını kontrol eder

IPv6 ping'i küresel bir düğüme ulaşıyorsa, çalışan bir IPv6 bağlantınız var demektir. Yalnızca IPv4 ulaşıyorsa, IPv6 ya yapılandırılmamıştır ya da çalışmıyordur.

Curl ile protokolü zorlayın

Web trafiği teşhisi için en güçlü araç, protokol seçimini zorlayan anahtarlarla curl'dür:

  • curl -4 adres - yalnızca IPv4 kullanmaya zorlar
  • curl -6 adres
  • curl -v adres - ayrıntılı mod, gerçekte hangi adrese bağlanıldığını gösterir

Anahtarları birleştirerek, uzak sitenin hangi adresi gördüğünü tam olarak öğrenebilirsiniz. IP'nizi döndüren bir servise -4 anahtarıyla istek gönderin ve saf IPv4 çıkışını görün. -6 ile gönderin ve IPv6 mevcutsa onu görün. Bu şekilde happy eyeballs'ın etkisini ayırmış ve her protokol için gerçek tabloyu görmüş olursunuz.

Yalnızca IPv6 uç noktasında test

Özellikle değerli bir yöntem, yalnızca IPv6 üzerinden erişilebilen, hiç A kaydı olmayan bir servise başvurmaktır. Böyle bir bağlantı kurulabiliyorsa, yerel IPv6 bağlantınız var demektir, yalnızca çevrim değil. Bağlantı -6 zorlamasına rağmen kurulamıyorsa, gerçek bir IPv6 çıkışınız yoktur ve tüm IPv6 etkinliğiniz NAT64 öneki etrafında döner.

Pratik kontrol senaryosu:

  1. IPv6-only uç noktasına curl -6 yapın - yerel IPv6 bağlantısını kontrol edin
  2. IP tanımlama servisine curl -4 yapın - PLAT üzerinden IPv4 çıkışını görün
  3. Adresleri karşılaştırın - IPv6 çıkışı abone alt ağından, IPv4 ise operatör havuzundan geliyorsa, 464XLAT ile tam teşekküllü çift yığın çalışıyor demektir

NAT64 ön ekinin varlığını belirleme

Ağınızın NAT64 kullanıp kullanmadığını anlamak için sentezlenmiş adreslere bakabilirsiniz. Kesinlikle IPv6'sı olmayan bir alan adı için AAAA kaydı isteyin ve yanıta bakın. 64:ff9b ile başlayan bir adres dönerse, bu DNS64 ve NAT64'ün çalıştığının açık bir işaretidir. Bazı sistemlerde, tam olarak bu şekilde çalışan yerleşik NAT64 öneki algılama mekanizmaları bulunur: bilinen bir adı sorgular ve yanıtın yapısına bakar.

Yığın teşhisi kontrol listesi

  • ip -6 addr - küresel IPv6 var mı?
  • ip -4 addr - IPv4 var mı ve özel bir CLAT adresi mi?
  • ping -6 küresel düğüme - IPv6 bağlantısı çalışıyor mu?
  • curl -4 IP servisine - site hangi IPv4'ü görüyor?
  • curl -6 IPv6-only uç noktasına - yerel IPv6 var mı?
  • IPv4-only alan adı için AAAA sorgusu - 64:ff9b öneki görülüyor mu?

Uyumluluk: /64 Alt Ağı Neden Tek Bir İstemci Olarak Algılanıyor?

Şimdi, birden fazla hesapla çalışan herkes için büyük pratik öneme sahip bir konuya geçiyoruz: Platformların IPv6 bağlantılarına nasıl davrandığı.

Bazı platformlar IPv6'ya neden daha kötü davranıyor?

Tarihsel olarak, birçok büyük platform, anti-fraud ve adres itibar sistemlerini IPv4 etrafında inşa etti. Birikmiş veritabanları, itibar puanlamaları, hız sınırlama kuralları - hepsi 32 bit adreslere göre ayarlanmıştı. IPv6 daha sonra geldi ve tüm sistemler eşit derecede iyi adapte olmadı.

Ayrıca yapısal bir neden de var. IPv4'te her adres kıt bir kaynaktır ve genellikle arkasında tek bir düğüm veya NAT arkasındaki bir düğüm bulunur. IPv6'da o kadar çok adres vardır ki, tek bir istemci kendi alt ağı içinde saatte binlerce kez adresini değiştirebilir. Bu, adres = istemci tanımlayıcısı olan alışılmış mantığı bozar.

Bu nedenle platformlar IPv6'ya özel bir yaklaşım geliştirmiştir ve bunu anlamak kritik öneme sahiptir.

/64 alt ağı nasıl yorumlanır?

Temel bilgiler bölümünde söylediğimizi hatırlayın: operatör her aboneye tam bir /64 alt ağı tahsis eder. Bu, tek bir cihaz için devasa miktarda adres demektir.

Akıllı itibar sistemleri bunu anlar. Her bir IPv6 adresini ayrı ayrı değerlendirmek yerine, tüm /64 alt ağını toplar ve tek bir tanımlayıcı olarak ele alır. Mantık basittir: bu alt ağın tamamı tek bir aboneye ait olduğuna göre, ona tek bir istemci gibi davranılmalıdır.

Bu, aynı /64 içinde IPv6 adresini değiştirmenin bu tür platformlar için yeni bir tanımlayıcı oluşturmadığı anlamına gelir. Adresin son bitlerini dilediğiniz kadar değiştirebilirsiniz, ancak platformun bakış açısından bu hâlâ aynı istemcidir çünkü /64 öneki değişmez.

Bunun birden fazla hesapla çalışmak için anlamı nedir?

Buradan önemli bir pratik sonuç çıkar. Hesapları aynı /64 alt ağı içindeki farklı IPv6 adreslerine ayırmaya çalışırsanız, gelişmiş platformlar için bunlar tek bir istemci gibi görünecektir. Ortak önek aynı olduğu sürece farklı adresler ayrım sağlamaz.

Bunu NAT64 üzerinden IPv4 davranışıyla karşılaştırın. PLAT düğümünün genel IPv4'ü, operatörün birçok farklı abonesi tarafından paylaşılır. Platformun bakış açısından, tek bir IPv4'ün arkasında düzinelerce gerçek insan vardır. Bu, trafik karışımı açısından tamamen farklı bir tablo oluşturur.

Çoklu hesap yönetimi için kilit çıkarımlar:

  • Aynı /64 içinde IPv6'nın son bitlerini değiştirmek, akıllı platformlar için tanımlayıcıyı değiştirmez
  • IPv6 için anlamlı birim, tek tek adres değil, /64 önekidir
  • Ayrım, aynı alt ağ içindeki adreslerde değil, farklı /64 alt ağları düzeyinde olmalıdır
  • NAT64 üzerinden IPv4, sizi operatörün diğer aboneleriyle karıştırır ve bu da farklı bir itibar dinamiği sağlar
  • Belirli bir platformla bağlantı için hangi protokolün kullanıldığını her zaman anlayın

Protokol kontrolü için pratik öneri

Tüm bunları göz önünde bulundurarak, hedef platformla bağlantınızın hangi protokol üzerinden gittiğini kontrol etmek mantıklıdır. Mobil operatör üzerinden IPv4 çıkışına ihtiyacınız olduğundan eminseniz, istemci düzeyinde IPv4'ü zorlayın. Bu şekilde, cihazınıza bağlı IPv6 alt ağı yerine, PLAT'ın paylaşılan genel adresini garanti altına alırsınız.

Mobil Ağlarda IPv6 ile Çalışırken Sık Yapılan Hatalar

Şimdi en yaygın yanılgıları ve hataları tek bir yerde toplayalım. Bunları dikkatlice inceleyin - her biri işinizi bozabilir veya yanlış sonuçlara yol açabilir.

Hata bir: Telefondaki IPv6 adresinin IPv6 çıkışı anlamına geldiğini sanmak

Birçok kişi arayüzde küresel bir IPv6 görür ve tüm trafiğin IPv6 üzerinden gittiği sonucunu çıkarır. Oysa IPv4 sitelerine giden trafik PLAT'ta yine IPv4'e dönüşür. Cihazdaki IPv6, operatör ağı içindeki bir taşıyıcıdır, belirli bir siteye IPv6 çıkışının garantisi değildir.

Hata iki: Çıkış adresini arayüz adresiyle karıştırmak

Cihazın ağ arayüzündeki adres ile sitenin gördüğü adres farklı şeylerdir. Aralarında CLAT ve PLAT çevirisi ve NAT vardır. Çıkış adresini ip addr'nin gösterdiğine göre asla değerlendirmeyin. Her zaman gerçek bir harici serviste kontrol edin.

Hata üç: Kontroldeki zıplayan adresler yüzünden panik yapmak

Happy eyeballs'ın çift yığının bazen IPv4 bazen IPv6 göstermesine neden olduğunu zaten açıkladık. Bu normaldir. Bunu proxy arızası olarak görmeyin. İstikrar istiyorsanız, protokolü zorlayın.

Hata dört: /64 içinde IPv6 değiştirmenin yeni bir tanımlayıcı verdiğini sanmak

Bu, çoklu hesap yönetiminde en pahalı hatalardan biridir. Akıllı platformlar tüm /64'ü toplar. Adresin son bitlerini değiştirmek, hesap ayrımı açısından anlamsızdır. Anlamlı birim önektir.

Hata beş: APN türünü göz ardı etmek

APN türü - IPv4, IPv6 veya IPv4v6 - trafiğe ne olacağını doğrudan belirler. Hangi türün kullanıldığını bilmeden körü körüne çalışırsınız. Oturum yapılandırmasını her zaman öğrenin.

Hata altı: Bağlantıyı yalnızca tek bir protokolle test etmek

Yalnızca IPv4 veya yalnızca IPv6 kontrolü yapmak eksik bir tablo verir. Gerçek teşhis, -4 ve -6 anahtarlarıyla her iki protokolün ayrı ayrı kontrol edilmesini ve ayrıca IPv6-only uç noktasına başvurmayı gerektirir.

Hata yedi: NAT64 önekini gerçek bir IPv6 sitesiyle karıştırmak

64:ff9b öneki ile sentezlenmiş bir adres IPv6 gibi görünür, ancak arkasında bir IPv4 sunucusu vardır. Böyle bir adrese bağlanıyorsanız, aslında NAT64 üzerinden bir IPv4 sunucusuna gidiyorsunuzdur, gerçek bir IPv6 düğümüyle iletişim kurmuyorsunuzdur. Sentezlenmiş adresten yola çıkarak sitenin yerel IPv6'sı olduğu sonucunu çıkarmayın.

Hata sekiz: CLAT ve PLAT'ı aynı şey sanmak

CLAT cihazda yaşar ve uygulamalar için durum bilgisi olmayan çeviri yapar. PLAT operatör ağında yaşar ve NAT ile durum bilgisi olan çeviri yapar. Bunlar farklı görevlere sahip farklı bileşenlerdir. Aralarındaki karışıklık, çıkış adresinin tam olarak nerede doğduğunu anlamayı zorlaştırır.

Protokol Yığını ile Çalışmak için Araçlar ve Kaynaklar

Mobil ortamda ağ yığınını teşhis etmenize ve anlamanıza yardımcı olacak bir araç seti oluşturalım. Hepsi standarttır ve egzotik bir şey gerektirmez.

Komut satırı

  • ip addr ve türevleri ip -4 addr, ip -6 addr - arayüz adreslerini görüntülemek için temel araç
  • ping ve ping6 - belirli bir protokol üzerinden bağlantıyı kontrol etme
  • -4 ve -6 anahtarlarıyla curl - web bağlantılarını teşhis etmek ve çıkış adresini kontrol etmek için ana araç
  • traceroute ve traceroute6 - yol izleme, trafiğin hangi düğümlerden geçtiğini görmeye yardımcı olur
  • dig ve nslookup - A ve AAAA kayıtlarını kontrol etmek, sentezlenmiş adresleri keşfetmek için DNS sorguları
  • ip route - her iki protokol için yönlendirme tablosunu görüntüleme

Çevrimiçi kontrol servisleri

  • Harici IP belirleme servisleri - uzak sitenin ne gördüğünü gösterir
  • IPv6-only test uç noktaları - yerel IPv6 bağlantısını kontrol eder
  • IPv4 ve IPv6'yı ayrı ayrı gösteren servisler - çift yığını görmeye yardımcı olur
  • Alan adının IPv6 desteğini kontrol eden araçlar - AAAA kaydının varlığını gösterir

DNS teşhisi

DNS sorguları, DNS64'ün çalışıp çalışmadığını anlamaya yardımcı olur. IPv6'sı olmayan bir alan adı için AAAA kaydı isteyin ve yanıtın yapısına bakın. 64:ff9b önekinin varlığı, sentezin çalıştığını gösterir. Bu, ağda NAT64 mekanizmasının varlığından emin olmanın en doğrudan yoludur.

Sistem yığın teşhisi çerçevesi

Herhangi bir mobil ağla ilk tanıştığınızda uygulamanız gereken adım adım bir çerçeve öneriyorum:

  1. Adres envanteri. ip addr çalıştırın, küresel IPv6'nın varlığını ve IPv4'ün yapısını belirleyin
  2. CLAT'ı belirleyin. Özel IPv4'e sahip sanal bir arayüz arayın - bu 464XLAT'ın işaretidir
  3. NAT64 kontrolü. IPv4-only alan adı için AAAA sorgulayın, 64:ff9b öneki arayın
  4. Yerel IPv6 testi. IPv6-only uç noktasına curl -6 yapın
  5. IPv4 çıkışını belirleyin. IP belirleme servisine curl -4 yapın
  6. IPv6 çıkışını belirleyin. IPv6 destekleyen bir servise curl -6 yapın
  7. Çift yığın davranışını analiz edin. Protokolü zorlamadan normal bir istek yapın ve happy eyeballs'ı gözlemleyin

Yedi adımı da tamamladığınızda, kapsamlı bir tablo elde edersiniz: ağın hangi tür bağlantıya sahip olduğu, çevrimin çalışıp çalışmadığı, farklı site türlerinin hangi adresleri gördüğü ve çift yığının nasıl davrandığı. Bu, standart denetiminizdir.

Vakalar ve Sonuçlar: Gerçek Senaryoların Analizi

Soyut mekanik, somut örneklerle daha iyi anlaşılır. Pratikte karşılaşılan birkaç tipik senaryoyu inceleyelim.

Vaka bir: Site loglarında bir IPv4 altında birçok istemci görülmesi

Durum. Bir analist site loglarını inceler ve aynı IPv4 adresinden çok farklı davranışlara sahip çok sayıda kullanıcı geldiğini fark eder. İlk akla gelen, bunun bir proxy veya botnet olduğudur.

Analiz. Aslında bu, büyük bir mobil operatörün NAT64 veya CGN düğümünün klasik genel IPv4 adresidir. Böyle bir adresin arkasında gerçekten onlarca, hatta yüzlerce gerçek abone vardır. Trafikleri tek bir PLAT üzerinden çıkar. Bu bir anormallik değil, IPv4 kıtlığı koşullarında 464XLAT'in olağan çalışmasıdır.

Sonuç. Mobil istemcileri yalnızca IPv4 adresine göre değerlendirmek verimsizdir. Mobil ortamda bir adres bir kullanıcıya eşit değildir. Mobil IPv4 adreslerini bu kadar karakteristik yapan da tam olarak bu özelliktir - tek bir adresin arkasında yüksek yoğunlukta gerçek kullanıcı bulunması.

Vaka iki: Kontrol servisinin tutarsız yanıtı

Durum. Bir mobil proxy operatörü, IP kontrol servisinin bazen IPv4 bazen IPv6 gösterdiğinden ve proxy'nin kararsız olduğu sonucuna varır.

Analiz. Kontrol servisinin hem A hem de AAAA kaydı vardır. İstemci çift yığınla çalışır. Her istek happy eyeballs'ı tetikler ve bağlantı yarışının sonucuna bağlı olarak farklı bir adres türü döner. Proxy kesinlikle kararlıdır, yalnızca algoritma tarafından seçilen protokol değişir.

Çözüm. Protokolü curl -4 veya istemcideki ilgili ayarlarla zorlayın. IPv4 sabitlendikten sonra adres tahmin edilebilir hale geldi. Kararsızlık sorununun hayali olduğu ortaya çıktı.

Vaka üç: Farklı IPv6'lara rağmen hesapların birleşmesi

Durum. Birden fazla hesapla IPv6 üzerinden çalışılıyor, her hesaba ayrı bir IPv6 adresi atanmış. Ancak platform hesapları birbiriyle ilişkilendiriyor.

Analiz. Atanan tüm adresler, operatör tarafından cihaza tahsis edilen aynı /64 alt ağı içindeydi. Gelişmiş itibar sistemi, tüm /64'ü topladı ve onu tek bir tanımlayıcı olarak ele aldı. Aynı önek içindeki farklı adresler hiçbir ayrım sağlamadı.

Sonuç. IPv6 için anlamlı birim /64 önekidir, tek tek adres değil. Ayrım, farklı önekler gerektirir. Bu durumda, trafiğin operatörün diğer aboneleriyle karıştığı NAT64 üzerinden IPv4 çıkışıyla çalışmak daha mantıklı olurdu.

Vaka dört: IPv6'yı bilmeyen uygulama

Durum. Eski bir uygulama doğrudan bir IPv4 adres sabitine bağlanıyor ve saf IPv6 ağında bozulması gerekirken çalışıyor.

Analiz. Cihazda CLAT çalışıyor. Uygulama, sanal arayüze bir IPv4 paketi gönderiyor, CLAT onu IPv6'ya çeviriyor, ardından paket PLAT üzerinden IPv4 internetine gidiyor. Uygulama, tam teşekküllü bir IPv4 ortamında yaşadığı yanılsaması içinde ve çevrimden haberi yok. CLAT'ın var olma nedeni tam olarak budur.

Sonuç. 464XLAT, eski uygulamalar için uyumluluğu şeffaf bir şekilde sağlar. Operatörlerin IPv6'ya geçişinin IPv4 yazılım ekosistemini neden bozmadığı da budur.

SSS: Sıkça Sorulan Sorular

Neden telefonum IPv6 gösterirken site loglarında IPv4 kaydediliyor?

Çünkü değişim operatör ağının çekirdeğindeki PLAT düğümünde gerçekleşir. Cihaz trafiği IPv6 ile gönderir, ancak IPv4 sitesine çıkarken NAT64 düğümü paketi IPv4'e çevirir ve operatörün genel adresini koyar. Site, cihazın dahili IPv6'sını değil, bu çıkış IPv4'ünü görür.

64:ff9b öneki nedir ve nereden gelir?

Bu, NAT64 çevirisi için standartlaştırılmış, iyi bilinen bir önektir. DNS64, AAAA kaydı olmayan sitelerin IPv4 adreslerinden yapay IPv6 adresleri sentezlemek için bunu kullanır. Böyle bir adresin son 32 biti, PLAT'ın çeviri sırasında çıkardığı gerçek IPv4'ü içerir.

CLAT ve PLAT arasındaki fark nedir?

CLAT cihazda çalışır ve IPv4 gerektiren uygulamalar için IPv4'ü IPv6'ya durum bilgisi olmadan çevirir. PLAT operatör ağında çalışır ve NAT ile IPv6'yı IPv4'e durum bilgisi olarak çevirir, genel adres koyar. CLAT cihazdaki uyumluluğu, PLAT IPv4 internetiyle uyumluluğu çözer.

IP kontrol servisi yenilediğimde neden farklı adresler gösteriyor?

Çift yığın ortamında happy eyeballs algoritması nedeniyle. Kontrol servisi hem IPv4 hem IPv6 üzerinden erişilebilirse, istemci bir bağlantı yarışı başlatır ve farklı zamanlarda farklı bir protokol kazanır. Bu normal bir davranıştır, arıza değil. Kararlı sonuç için protokolü bir anahtarla zorlayın.

Yalnızca NAT64 değil, gerçek IPv6 çıkışım olup olmadığını nasıl anlarım?

Yalnızca IPv6 üzerinden erişilebilen bir uç noktaya curl -6 komutuyla başvurun. Bağlantı kurulursa, yerel IPv6 bağlantınız var demektir. -6 zorlamasına rağmen başarısız olursa, gerçek bir IPv6 çıkışınız yoktur ve tüm IPv6 etkinliğiniz sentezlenmiş NAT64 öneki etrafında döner.

IPv6 adresini değiştirmek neden hesapları ayırmaya yardımcı olmuyor?

Çünkü operatör cihaza tam bir /64 alt ağı tahsis eder ve gelişmiş platformlar bu alt ağın tamamını tek bir tanımlayıcı olarak toplar. Adresin son bitlerini değiştirmek öneki değiştirmez, bu nedenle platform için hâlâ aynı istemcidir. Anlamlı birim /64'tür, tek bir adres değil.

Mobil proxy'nin çıkışı neden genellikle IPv4 değil de IPv6 oluyor?

Çoğu hedef sitenin IPv6 altyapısı olmadığı için trafik NAT64 üzerinden geçer. PLAT düğümü paketleri IPv4'e çevirir ve operatörün genel adresini atar. Bu adres çıkış adresi olur. Gerçek AAAA kaydı olan sitelere proxy doğrudan IPv6 ile de çıkabilir.

İstemciyi belirli bir protokol sürümünü kullanmaya nasıl zorlayabilirim?

Curl düzeyinde, IPv4 için -4, IPv6 için -6 anahtarlarını kullanın. Birçok uygulama ve kütüphane benzer protokol tercih ayarlarına sahiptir. Ayrıca sistem adres politikası öncelik ayarlarıyla da kontrol edilebilir. Bu, happy eyeballs'ın belirsizliğini ortadan kaldırır ve tahmin edilebilir bir çıkış sağlar.

Mobil ağ üzerinden bağlanırken hedef site ne görür?

Sitenin yalnızca IPv4'ü varsa, operatörün NAT64 düğümünün birden fazla abone tarafından paylaşılan genel IPv4 adresini görür. Sitenin gerçek IPv6'sı varsa, aboneye tahsis edilen alt ağdan bir IPv6 adresi görür. Cihazın dahili adresleri ve sanal CLAT adresi site tarafından asla görülmez.

APN türü sitenin hangi adresi göreceğini etkiler mi?

Dolaylı olarak evet. APN türü, cihazın hangi protokollere erişebileceğini belirler. IPv4v6 veya CLAT'lı saf IPv6'da, açıklanan çevrim mekanizmasının tamamı çalışır. Saf IPv4 APN'de çevrime gerek yoktur, ancak büyük operatörlerde adres kıtlığı nedeniyle bu seçenek nadirdir.

Sonuç: Mobil Ağlarda IPv6 Mekaniği Hakkında Anahtar Noktalar

Uzun bir yol kat ettik. Telefon IPv6'da, site IPv4 görüyor bilmecesiyle başladık ve tamamen çözdük. Şimdi kilit çıkarımları pekiştirelim.

Birinci ve en önemlisi. IPv4 adres kıtlığı operatörleri IPv6'ya geçmeye zorladı. Cihazlar, genellikle radyo arayüzünde hiçbir genel IPv4 olmadan IPv6 ortamında yaşar. Eski IPv4 internetiyle uyumluluk 464XLAT teknolojisi ile sağlanır.

İkincisi. 464XLAT iki çevirmenden oluşur. Cihazdaki CLAT, uygulamaların IPv4 trafiğini IPv6'ya dönüştürür. Operatör ağındaki PLAT, IPv6'yı tekrar IPv4'e dönüştürür ve genel bir adres atar. Çıkış IPv4 adresi tam olarak PLAT'ta doğar ve site bunu görür.

Üçüncüsü. NAT64 ve DNS64 birlikte çalışır. DNS64, AAAA kaydı olmayan siteler için IPv4'ten 64:ff9b önekini kullanarak IPv6 adresleri sentezler. PLAT şeklindeki NAT64, paketleri bu adresler üzerinden gerçek IPv4 sunucularına ulaştırır. Birlikte, saf IPv6 cihazı için tüm IPv4 internetini erişilebilir kılarlar.

Dördüncüsü. Çift yığın ve happy eyeballs, kontrolün neden bazen bir protokolü bazen diğerini gösterdiğini açıklar. İstemci bir bağlantı yarışı düzenler ve kazananı seçer. Kararlılık için protokolü -4 veya -6 anahtarlarıyla zorlayın.

Beşincisi. Çoklu hesap yönetimi için kritik bir nokta: /64 alt ağı akıllı platformlar tarafından tek bir istemci olarak algılanır. Aynı /64 içinde adres değiştirmek ayrım için faydasızdır. NAT64 üzerinden IPv4 ise sizi operatörün diğer aboneleriyle karıştırır.

Sonraki adımlar? Herhangi bir yeni mobil ağda yedi adımlı çerçevemize göre sistemli bir yığın teşhisi yapmayı alışkanlık haline getirin. Ana aracınız olarak -4 ve -6 anahtarlarıyla curl'ü öğrenin. Çıkış adresini her zaman cihaz arayüzüne göre değil, gerçek bir harici hizmette kontrol edin. Cihazın nerede yaşadığı ile trafiğin internete gerçekte nereden çıktığı arasındaki farkı aklınızda tutun.

Bu mekaniği anlamak, sizi zıplayan adresler karşısında şaşkına dönen bir kullanıcıdan, her pakete ne olduğunu tam olarak bilen bir mühendise dönüştürür. Ve bilgi, bilindiği gibi, kontroldür. Bu makale, mobil ağlarda IPv6'nın yapısı hakkında masanızda bulunan bir başvuru kaynağı olsun. Bir ağ gizemiyle karşılaştığınızda ona geri dönün - ve gizem olmaktan çıkacaktır.