CGNAT Nedir? Genel IPv4'e Karşı Çalışma Prensibi Nedir?

CGNAT nasıl çalışır?

CGNAT, servis sağlayıcının ağı içinde ağ adresi çevirisi gerçekleştirir.

Tipik bir ev ağı zaten NAT kullanır:

Dizüstü bilgisayar / telefon / TV
       ↓
Özel IPv4 adresleri
192.168.x.x
       ↓
Ev yönlendiricisi NAT
       ↓
Genel IPv4 adresi
       ↓
İnternet

Müşterinin yönlendiricisi, birden fazla özel cihazdan gelen trafiği bağlantıya atanmış genel IPv4 adresine çevirir.

CGNAT ile servis sağlayıcı ek bir çeviri katmanı ekler:

Müşteri cihazları
       ↓
Ev yönlendiricisi
       ↓
Müşteri tarafı adresi
       ↓
ISP CGNAT
       ↓
Paylaşılan genel IPv4 havuzu
       ↓
İnternet

Bu nedenle birçok dağıtımda iki çeviri alanı bulunur: müşterinin ağı içindeki NAT ve sağlayıcının ağı içindeki CGNAT.

IETF, Carrier-Grade NAT’i aynı IPv4 adresini birden fazla abone arasında paylaşmak için kullanılan NAT tabanlı bir işlev olarak tanımlar; burada CGN, aboneler yerine servis sağlayıcı tarafından yönetilir. Bu tanım ve yaygın operasyonel gereksinimler RFC 6888: Common Requirements for Carrier-Grade NATs. belgesinde açıklanmıştır.

CGNAT adreslerin yanı sıra portları da paylaşır

CGNAT aboneleri yalnızca genel IP adresine göre ayırt etmez.

Taşıma katmanı portları da çevirinin bir parçasıdır.

Basit bir örnek şu şekilde olabilir:

Abone A
100.64.10.20:50001
       ↓
203.0.113.20:22001

Abone B
100.64.20.30:51002
↓
203.0.113.20:22002

Abone C
100.64.30.40:52003
↓
203.0.113.20:22003

Harici bir hizmet açısından bakıldığında, üç abone de şu adresten bağlanıyor gibi görünebilir:

203.0.113.20

CGNAT platformu, geri dönen trafiğin doğru abone ve bağlantıyla eşleştirilebilmesi için çeviri durumunu tutar.

Bu adres ve port paylaşımı, nispeten küçük bir genel IPv4 havuzunun çok daha fazla kullanıcıya hizmet vermesini sağlar.

ISP’ler neden CGNAT kullanır?

ISP’ler CGNAT’ı temel olarak abone başına gereken genel IPv4 kapasitesini azaltmak için kullanır.

Yüz binlerce konut müşterisine hizmet veren bir erişim sağlayıcısını düşünün. Her bağlantıya kendi genel IPv4 adresini vermek, buna karşılık gelen büyük bir adres havuzu tüketir.

CGNAT, tahsis modelini şundan:

1 abone
=
1 genel IPv4

şuna daha yakın bir yapıya dönüştürür:

çok sayıda abone
=
paylaşılan genel IPv4 kapasitesi

Bu durum CGNAT’ı, müşteri trafiğinin çoğunlukla dışarı yönlü olduğu geniş bant, mobil, kablosuz ve diğer büyük erişim ağları için kullanışlı hale getirir.

LARUS, CGNAT’ı diğer adres yönetimi yaklaşımlarıyla birlikte ISP’lerin IPv4 kıtlığını nasıl yönettiği rehberinde ele almaktadır.

Önemli ayrım basittir:

CGNAT yeni IPv4 adresleri oluşturmaz. Mevcut genel IPv4 kapasitesinin daha yoğun şekilde paylaşılmasını sağlar.

100.64.0.0/10 CGNAT aralığı nedir?

100.64.0.0/10 IPv4 öneki, CGN dağıtımları dahil olmak üzere servis sağlayıcı ağları için ayrılmış Paylaşılan Adres Alanıdır.

Aralık şu adreslerden oluşur:

100.64.0.0
ile
100.127.255.255

IETF bu alanı RFC 6598: IANA-Reserved IPv4 Prefix for Shared Address Space belgesinde tahsis etmiştir. Belge, Paylaşılan Adres Alanını RFC 1918 özel adres alanından ayırır; çünkü bu alan özellikle servis sağlayıcı ağlarında kullanılmak üzere tasarlanmıştır.

Bu nedenle aşağıdaki tanıdık özel aralıklardan farklıdır:

10.0.0.0/8
172.16.0.0/12
192.168.0.0/16

100.64.0.0/10 ayrıca normal, küresel olarak yönlendirilebilir bir genel IPv4 alanı değildir.

Bir müşteri yönlendiricisi 100.64.0.0 ile 100.127.255.255 arasında bir WAN adresi alıyorsa, bu CGNAT’ın mevcut olabileceğine dair güçlü bir göstergedir.

Ancak bu evrensel bir tespit yöntemi değildir. Sağlayıcı mimarileri farklılık gösterebilir ve her paylaşılan adres dağıtımı müşteri tarafından aynı şekilde görünmek zorunda değildir.

CGNAT ve NAT: fark nedir?

Normal müşteri NAT’i ile CGNAT arasındaki temel fark, çevirinin nerede gerçekleştiği ve genel adresi kimin paylaştığıdır.

Geleneksel NAT genellikle tek bir müşteri ağı içindeki cihazların, müşterinin yönlendiricisi tarafından kontrol edilen bir genel adresi paylaşmasına olanak tanır.

CGNAT ise servis sağlayıcı düzeyinde ek bir çeviri katmanı oluşturur ve birden fazla bağımsız abone ağının genel IPv4 kapasitesini paylaşmasına imkan verir.

Temel çeviri modeli için LARUS’ın Network Address Translation ve NAT’ın nasıl çalıştığı . rehberine bakın.

Bu nedenle CGNAT, yalnızca ev NAT’inin başka bir adı değildir. Büyük ölçekli adres paylaşımını sağlayıcı ağı içine taşır.

CGNAT neden abone ilişkilendirmesini zorlaştırır?

Paylaşılan bir genel IPv4 adresi aynı anda birçok aboneyi temsil edebilir.

Bu, tek başına genel IP adresinin belirli bir bağlantıyı hangi abonenin oluşturduğunu tanımlamak için yeterli olmayabileceği anlamına gelir.

Bir kötüye kullanım raporunun yalnızca şunları içerdiğini varsayalım:

Genel IP: 203.0.113.20
Saat:     14:35 UTC

Eğer saat 14:35’te yüzlerce abone bu adresi paylaşıyorsa, adres tek başına doğru ilişkilendirme için yetersiz olabilir.

Daha yararlı bilgiler şunları içerebilir:

Genel IP:     203.0.113.20
Kaynak portu: 22002
Zaman damgası:14:35:27 UTC
Protokol:     TCP

Servis sağlayıcı daha sonra bu bilgileri abone atamaları veya CGN çeviri kayıtlarıyla ilişkilendirebilir.

RFC 6888, CGN günlüklemesini ele alır ve çevrilmiş bir oturumla ilişkili aboneyi tanımlamak için yeterli bilginin kaydedilmesinin operasyonel sonuçlarına dikkat çeker.

Bu durum önemli bir mühendislik dengesi oluşturur:

CGNAT, genel IPv4 tüketimini azaltırken doğru oturum eşleştirme, zaman damgaları, günlükleme altyapısı ve kötüye kullanım müdahale süreçlerinin önemini artırabilir.

CGNAT’ın sınırlamaları nelerdir?

CGNAT, birçok normal dışarı yönlü İnternet uygulaması için iyi çalışır.

Sınırlamalar; iş yükü istenmeyen gelen bağlantılara, öngörülebilir port davranışına veya ayrı bir genel kaynak adresine bağlı olduğunda daha görünür hale gelir.

IETF’nin RFC 6269: Issues with IP Address Sharing belgesi, büyük ölçekli adres paylaşımının çeşitli sonuçlarını açıklar. Bunlar arasında gelen bağlantılar, benzersiz kaynak adresi varsayan uygulamalar, izleme, güvenlik, port tahsisi ve IP tabanlı kontroller üzerindeki etkiler yer alır.

Gelen bağlantılar daha zor hale gelebilir

CGNAT arkasındaki bir müşteri genellikle sağlayıcının genel taraftaki çevirisini kontrol etmez.

Bu durum şunları zorlaştırabilir:

• Kendi kendine barındırılan uygulamalar

• Uzaktan erişim hizmetleri

• Müşteri tarafından işletilen sunucular

• Eşler arası uygulamalar

• Bazı VPN yapılandırmaları

• Güvenlik kameraları

• Bazı oyun senaryoları

Uygulamalar ve sağlayıcılar NAT geçiş mekanizmalarını veya alternatif tasarımları destekleyebilir, ancak CGNAT bağlantısı doğrudan kullanılabilir genel IPv4’e sahip olmakla otomatik olarak eşdeğer kabul edilmemelidir.

Port kapasitesi ağ planlamasının bir parçası haline gelir

Bir genel IPv4 adresi sınırlı bir taşıma portu alanına sahiptir.

Birçok abone aynı adresi paylaştığında, CGN platformunun portları dağıtması ve çeviri durumunu aboneler arasında tutması gerekir.

Bu nedenle operatörlerin yalnızca şunu düşünmesi yeterli değildir:

Kaç genel IPv4 adresi mevcut?

Ayrıca şunu da değerlendirmeleri gerekir:

Planlanan paylaşım oranında kaç eşzamanlı çeviri ve kullanılabilir port desteklenebilir?

Agresif paylaşım adres kapasitesinden tasarruf sağlayabilirken hizmet mimarisinin başka noktalarında baskı oluşturabilir.

Paylaşılan adresler itibar etkisinin diğer kullanıcılara yayılmasına neden olabilir

Harici hizmetler aşağıdakileri uygularken kaynak IP’yi çoğu zaman sinyallerden biri olarak kullanır:

• Kötüye kullanım kontrolleri

• Dolandırıcılık tespiti

• Spam filtreleme

• Oran sınırlamaları

• Güvenlik politikaları

• İtibar puanlaması

CGNAT ile birbirleriyle ilgisi olmayan aboneler aynı sinyali paylaşabilir.

Paylaşılan bir genel IPv4 adresi engellenirse veya kötü bir itibar geliştirirse, soruna neden olan davranışla hiçbir ilgisi olmayan müşteriler de sorun yaşayabilir.

RFC 6269 bu tür dolaylı etkiyi büyük ölçekli IP adres paylaşımının sonuçlarından biri olarak ele almaktadır.

CGNAT ve genel IPv4: gerçekte ne değişir?

En yararlı karşılaştırma CGNAT ile NAT olmaması arasında değildir.

Asıl soru, hizmetin paylaşılan dışarı yönlü IPv4 erişimine mi yoksa doğrudan genel IPv4 yeteneklerine mi ihtiyaç duyduğudur.

İki mimari farklı sorunları çözer.

CGNAT adres kullanımını optimize eder. Genel IPv4, bir ağa veya müşteriye İnternet tarafından görülen adresle daha doğrudan bir ilişki sağlar.

İki mimari farklı sorunları çözer.

CGNAT adres kullanımını optimize eder. Genel IPv4, bir ağa veya müşteriye İnternet tarafından görülen adresle daha doğrudan bir ilişki sağlar.

CGNAT ne zaman uygun bir seçenektir?

CGNAT, abonelerin ağırlıklı olarak dışarı yönlü bağlantılar başlattığı ve İnternet’e açık bir IPv4 adresini kontrol etmelerine gerek olmadığı hizmetler için uygundur.

Tipik örnekler şunlardır:

• Konut tipi geniş bant

• Mobil İnternet erişimi

• Büyük tüketici ağları

• Halka açık Wi-Fi

• Dışarı yönlü IoT bağlantısı

• Giriş seviyesi İnternet hizmetleri

Bu müşteriler için her aboneye bir genel IPv4 adresi ayırmak, tüketilen adres kapasitesine kıyasla çok az ek operasyonel değer sağlayabilir.

CGNAT, operatörün genel IPv4’ü daha seçici şekilde kullanmasına olanak tanır.

Genel IPv4 ne zaman daha uygun bir seçenektir?

Genel IPv4, bir iş yükü büyük ölçekli adres paylaşımının kısıtladığı ağ yeteneklerine bağlı olduğunda daha önemli hale gelir.

Örnekler şunlardır:

• Genel uygulamaları barındırma

• Kurumsal VPN ağ geçitleri

• Kurumsal güvenlik duvarı izin listeleri

• Uzaktan erişim altyapısı

• Müşteri kontrollü gelen hizmetler

• Öngörülebilir genel adresleme gerektiren ağ cihazları

• Paylaşılan IP itibarına duyarlı hizmetler

• Kararlı genel çıkış adreslemesi gerektiren kurumsal bağlantılar

Bir servis sağlayıcının her müşteri için tek bir model seçmesi gerekmez.

Bölümlendirilmiş bir tasarım şu şekilde olabilir:

Konut / temel geniş bant
       ↓
CGNAT

Kurumsal bağlantı
↓
Genel IPv4 seçeneği

Barındırma / altyapı
↓
Yönlendirilen genel IPv4 kapasitesi

CGNAT, paylaşım iş yüküne uygun olduğunda adres kapasitesini koruyabilir; buna karşılık özel veya yönlendirilen genel IPv4, buna ihtiyaç duyan hizmetler için kullanılabilir durumda kalır.

CGNAT genel IPv4 talebini ortadan kaldırmaz

Bir CGNAT mimarisi, İnternet’e bakan tarafta hâlâ genel IPv4 gerektirir.

Operatörler ayrıca kurumsal aboneler, barındırma müşterileri, genel hizmetler, altyapı ürünleri veya paylaşılan adres modelinden istisna isteyen müşteriler için ayrı adres kapasitesine ihtiyaç duyabilir.

Ağ büyüdükçe kapasite planlaması bu nedenle şu bileşenlerin birleşimine dönüşür:

Paylaşılan IPv4’e uygun trafik
+
Genel IPv4 gerektiren trafik
+
Büyüme için ayrılan kapasite

Bu nedenle adres paylaşımı, daha geniş IPv4 kıtlığı ve kapasite planlama sorununun. yalnızca bir parçasıdır.

Kurumsal IP ürünleri, barındırma talebi, genel adres istisnaları, abone büyümesi veya CGN port baskısı artıyorsa, konu yalnızca NAT’ın nasıl yapılandırılacağından daha kapsamlı hale gelir. Bu, bir genel IPv4 kapasitesi kararı haline gelir.

LARUS IPv4 Kullanılabilirliği ve Continuity Assurance seçeneğini kontrol edin ve mevcut bir CGNAT mimarisinin yanında ek üretim IPv4 kapasitesini değerlendirin.

LARUS şu anda kendi adres havuzundan birinci taraf IPv4 kiralama hizmeti sunmakta ve yönlendirme geçerliliği, rDNS, RPKI/ROA hazırlığı, itibar, kötüye kullanım iş akışı, coğrafi konum, destek yanıtı ve yenileme gibi alanları kapsayan süreklilik kontrolleri sağlamaktadır.

Adres paylaşımının operasyonel maliyeti

CGNAT genel IPv4 tüketimini azaltabilir, ancak başka alanlarda ek operasyonel iş yükü oluşturur.

Ağa ve gereksinimlere bağlı olarak operatörlerin şunları yönetmesi gerekebilir:

• Çeviri altyapısı

• Oturum kapasitesi

• Port tahsisi

• Abone eşleştirmesi

• Zaman senkronizasyonu

• Günlük üretimi ve depolama

• Kötüye kullanım incelemeleri

• Paylaşılan adres itibarı

• Müşteri istisnaları

• Özel genel IP hizmet katmanları

BTW.Media, bu sorunun günlükleme tarafını CGNAT günlükleme zorunlulukları ve IPv4 kıtlık maliyetleri analizinde ele almakta; çeviri kayıtları, zaman doğruluğu, depolama ve abone ilişkilendirmesi için gereken altyapıyı incelemektedir.

Operatörler açısından bu, iş yüküne özel bir tasarım seçimine yol açar: paylaşılan adreslemeyi müşteri gereksinimlerini karşıladığı yerde kullanmak; doğrudan erişilebilirlik, ayrı kaynak adresleme, itibar izolasyonu veya daha fazla kontrol gereken yerlerde ise genel IPv4 kapasitesini korumak.

SSS

100.64.0.0/10 genel bir IP aralığı mıdır?

Hayır. 100.64.0.0/10, servis sağlayıcı kullanımı için ayrılmış Paylaşılan Adres Alanıdır. RFC 6598 bu aralığı Carrier-Grade NAT dahil çeşitli senaryolar için tanımlar ve normal genel IPv4 alanından ayırır.

CGNAT arkasında olup olmadığımı nasıl anlayabilirim?

Yönlendiriciniz tarafından gösterilen WAN IPv4 adresini, bir İnternet hizmetinin gördüğü genel IPv4 adresiyle karşılaştırın. Eğer farklılarsa — özellikle de yönlendiricinin adresi 100.64.0.0/10 aralığındaysa — CGNAT kullanılıyor olabilir. Sağlayıcı mimarileri farklılık gösterebilir, bu nedenle kesin yanıtı ISP’niz verebilir.

CGNAT port yönlendirmeyi engeller mi?

CGNAT genellikle normal müşteri kontrollü gelen port yönlendirmeyi daha zor hale getirir; çünkü müşteri sağlayıcının harici çeviri katmanını kontrol etmez. Bazı sağlayıcılar veya uygulamalar alternatif mekanizmaları destekler, bu nedenle kesin davranış dağıtıma bağlıdır. RFC 6269, adres paylaşımının gelen portlar ve bağlantılar için oluşturduğu zorlukları ele almaktadır.

CGNAT oyunlar, VPN’ler veya eşler arası uygulamalar için kötü müdür?

Her zaman değil. Birçok uygulama normal çalışırken, gelen oturumlara, doğrudan eş bağlantısına, belirli NAT davranışlarına veya öngörülebilir port eşlemelerine bağlı uygulamalar sınırlamalar yaşayabilir. Sonuç, uygulamaya ve sağlayıcının CGN uygulamasına bağlıdır.

CGNAT IPv4 tükenmesini çözer mi?

CGNAT, adresleri paylaşarak abone başına gereken genel IPv4 adresi sayısını azaltır; ancak yeni genel IPv4 alanı oluşturmaz. Sağlayıcılar, CGN’in İnternet’e bakan tarafı ve doğrudan genel adresleme gerektiren hizmetler için hâlâ genel IPv4’e ihtiyaç duyar.