Uç IP logu nedir? CG-NAT kayıtları neden zorunlu?

IPv4 tükenmesi ve CG-NAT'a giden yol

IPv4 adres alanı yaklaşık 4,3 milyar adresten oluşur ve bu havuz, bölgesel internet kayıt kuruluşlarınca (RIPE NCC dahil) yıllar önce büyük ölçüde dağıtılmış durumdadır. Yeni bir ISS'nin her abonesine ayrı bir genel IPv4 adresi tahsis edecek kadar blok edinmesi bugün ya mümkün değildir ya da ikinci el piyasada ciddi bir maliyet gerektirir. IPv6 bu sorunun kalıcı çözümüdür; ancak abone cihazlarının, içerik sağlayıcıların ve ara ağların tamamı IPv6'ya geçene kadar IPv4 erişimi sürdürülmek zorundadır.

Bu iki gerçeğin kesişiminde ISS'ler, abonelerine özel adresler verip sınırlı sayıdaki genel IPv4 adresini paylaştıran bir ara çözüme yöneldi: Carrier-Grade NAT (CG-NAT). Türkiye'de özellikle kendi BNG'sini işleten bölgesel ISS'lerde bu yapı yaygındır.

CG-NAT (NAT444) nedir?

Ev kullanıcısının modeminde çalışan NAT, evdeki cihazların özel adreslerini (192.168.x.x) modeme verilen tek adrese çevirir. CG-NAT, aynı işlemi bir kademe daha üstte, ISS'nin çekirdeğinde yapar: Modeme verilen adres de özeldir (RFC 6598 ile bu amaç için ayrılan 100.64.0.0/10 bloğu) ve ISS'nin CG-NAT cihazı bu adresi genel bir IPv4 adresine çevirir. Paket, aboneden internete giderken iki kez adres çevrimi geçirdiği için bu yapıya NAT444 denir: özel (ev) → özel (ISS) → genel.

CG-NAT cihazı, her çıkan bağlantı için bir eşleşme (translation) oluşturur: "100.64.12.8:51220 numaralı iç adres ve port, 185.x.x.1:40117 numaralı genel adres ve porta çevrildi." Bir genel IPv4 adresinde 65.535 port olduğundan ve sistem portları dışında kalan on binlerce port abonelere dağıtılabildiğinden, tek bir genel IP'nin arkasına yüzlerce hatta binlerce abone yerleştirilebilir. Abone başına kaç port ayrıldığı (örneğin 1.000 ya da 2.000) bu oranı belirler.

Yetkili makam sorgusunda IP neden tek başına yetmez?

5651 sayılı Kanun kapsamında yetkili makamlardan gelen taleplerin klasik biçimi "bu IP, bu tarih ve saatte kime aitti?" sorusudur. Her aboneye ayrı genel IP verilen bir ağda bu sorunun yanıtı RADIUS accounting kaydından doğrudan bulunur. CG-NAT'lı ağda ise aynı anda aynı genel IP'yi kullanan yüzlerce abone vardır. IP ve saniye hassasiyetinde zaman verilse bile aday abone sayısı onlarca olabilir; bu, hem talebin karşılanamaması hem de masum abonelerin şüpheli konumuna düşmesi riskini doğurur.

Aboneyi tekil olarak belirlemek için talepte kaynak port bilgisinin de bulunması ve ISS'nin o anda bu genel IP:port'u hangi iç IP:port'a eşlediğini kaydetmiş olması gerekir. İşte bu kayıt uç IP logudur. İçerik sağlayıcılar ve yer sağlayıcılar da bu nedenle kendi erişim loglarında kaynak port bilgisini tutmaya yönlendirilmiştir; port olmadan CG-NAT arkasındaki aboneye ulaşmak teknik olarak mümkün değildir.

Kaydedilmesi gereken alanlar

Bir NAT port kaydının sorguya yanıt verebilmesi için en az aşağıdaki alanları içermesi gerekir. Kaynak port kayıtlarının çoğu "eşleşme oluşturuldu" ve "eşleşme sonlandı" olmak üzere iki olay olarak üretilir; port bloğu tahsisinde ise olay, blok bazında kaydedilir.

Hedef IP ve hedef port (abonenin bağlandığı sunucu) bazı cihazlarda kayda eklenebilir; ancak abone tespiti için zorunlu değildir ve kaydedilmesi hem hacmi büyütür hem de KVKK açısından amaçla sınırlılık ilkesi gözetilerek değerlendirilmelidir.

Log hacmi sorunu: deterministik NAT ve port blok tahsisi

Her bağlantı için ayrı bir kayıt üretilen (dinamik NAT, oturum bazlı loglama) yaklaşımda hacim hızla büyür. Bir abonenin cihazları gün içinde binlerce kısa ömürlü bağlantı açar; binlerce abonede bu, günde milyonlarca satır demektir. Bu kayıtların toplanması, indekslenmesi ve ilgili yönetmelikte belirlenen süre boyunca saklanması ciddi depolama ve işlem kapasitesi gerektirir.

Hacmi yönetilebilir hale getiren iki yaygın teknik vardır:

Port blok tahsisi (Port Block Allocation, PBA)

CG-NAT cihazı, aboneye bağlantı başına port vermek yerine belirli büyüklükte (örneğin 512 veya 1.024 portluk) bir blok tahsis eder ve yalnızca blok tahsis edildiğinde ve serbest bırakıldığında kayıt üretir. Abone bloğu doldurursa yeni bir blok tahsis edilir ve yine tek kayıt düşer. Böylece bağlantı başına milyonlarca satır yerine abone başına günde birkaç satır yeterli olur. Sorguda, genel IP ve portun hangi bloğa düştüğüne bakılarak aboneye ulaşılır.

Deterministik NAT

Daha ileri bir adımda, iç IP ile genel IP:port bloğu arasındaki eşleşme sabit bir algoritmayla (örneğin iç IP'nin son oktetine göre) hesaplanır. Bu durumda eşleşme kaydı tutmaya bile gerek kalmaz; yalnızca yapılandırma (hangi iç blok hangi genel IP'ye hangi port aralığıyla eşleniyor) ve bu yapılandırmanın değişiklik geçmişi saklanır. Sorguda genel IP:port'tan iç IP matematiksel olarak türetilir. Deterministik NAT, abone başına port sayısını sabitlediği için yoğun kullanan aboneler için esnekliği azaltır; bu nedenle çoğu ISS PBA ile deterministik yaklaşımı birlikte ya da aşamalı olarak kullanır.

Her iki teknikte de iç IP'nin hangi aboneye ait olduğu bilgisi NAT cihazında değil RADIUS'ta bulunduğundan, NAT kaydı tek başına yine yeterli değildir; RADIUS oturum kaydıyla birleştirilmesi gerekir.

A10 Thunder ve pfSense örnekleri

Uç IP logu üretiminde kullanılan cihaz, kayıtların biçimini ve toplanma yöntemini belirler. ISS'lerde sık karşılaşılan iki örnek:

• A10 Thunder CGN: Operatör sınıfı CG-NAT platformudur; PBA ve deterministik NAT'ı donanım hızında destekler. Kayıtlar syslog, NetFlow v9/IPFIX ya da üreticiye özgü kompakt formatlarda dışa aktarılabilir. Yüksek abone yoğunluğunda düşük kayıt hacmi sağlar.
• pfSense: Açık kaynaklı, FreeBSD tabanlı bir güvenlik duvarı ve yönlendiricidir; küçük ve orta ölçekli ISS'lerde outbound NAT ile CG-NAT görevi üstlenebilir. NAT durum tablosu ve pf log kayıtları syslog üzerinden dışarı aktarılır; PBA benzeri davranış için statik port aralığı kuralları tanımlanır. Ölçek büyüdükçe kayıt hacmi ve işlem yükü dikkatle izlenmelidir.

WiRadius, her iki platformla hazır entegrasyona sahiptir; kayıtlar RADIUS oturum verisiyle birleştirilerek sorgulanabilir hale getirilir. Ayrıntı için cihaz ve altyapı entegrasyonları sayfasına bakabilirsiniz.

RADIUS oturumu ile abone eşleştirme

NAT kaydında görünen iç IP (100.64.12.8), aboneye kalıcı olarak değil, PPPoE/IPoE oturumu süresince atanır. Abone modemini yeniden başlattığında aynı iç IP başka bir aboneye gidebilir. Bu nedenle eşleştirme üç kaynağı birleştirir:

1. RADIUS Accounting Start/Stop: Hangi kullanıcı adının (abonenin) hangi iç IP'yi hangi zaman aralığında kullandığı. RADIUS sunucu yazısında accounting akışını ayrıntılı anlattık.
2. NAT kaydı: İç IP:port'un hangi genel IP:port'a, ne zaman eşlendiği.
3. CRM: Kullanıcı adının hangi gerçek aboneye (ad, kimlik, adres, sözleşme) ait olduğu.

Üç kaynağın saatlerinin aynı NTP kaynağına bağlı olması, zaman aralığı kesişimlerinin doğru hesaplanması için zorunludur. Saniyelik bir kayma, oturum değişim anlarında yanlış aboneye işaret edebilir.

Sorgu senaryosu: adım adım

Yetkili makamdan şu talep geldiğini varsayalım: "185.x.x.1 IP adresi, 40117 kaynak portu, 21.10.2026 12:14:02 (UTC+3), TCP."

İyi tasarlanmış bir log sisteminde bu beş adım tek sorgu ekranında, dakikalar içinde tamamlanır. Ham dosyalarda elle arama ise saatler sürebilir ve hata payı yüksektir.

Saklama ve bütünlük

Uç IP logu, 5651 kapsamındaki diğer trafik bilgisiyle aynı doğruluk, bütünlük ve gizlilik gereklerine tabidir. Kayıtlar düzenli aralıklarla özetlenmeli (hash), zaman damgası ile imzalanmalı, şifreli ve yedekli depoda ilgili yönetmelikte belirlenen süre boyunca saklanmalı; erişim rol tabanlı olmalı ve her sorgu kayıt altına alınmalıdır. NAT kayıtlarının hacmi büyük olduğundan sıkıştırma ve soğuk depolama katmanı planlanmalı, ancak sıkıştırılmış arşivlerin sorgu süresi makul düzeyde tutulmalıdır.

• CG-NAT cihazı PBA veya deterministik NAT ile yapılandırılmış; kayıt hacmi ölçülüyor.
• NAT kayıtları syslog/IPFIX ile merkezi toplayıcıya kesintisiz akıyor; kayıp paket izleniyor.
• RADIUS, BNG, CG-NAT ve toplayıcı aynı NTP kaynağına bağlı.
• NAT kaydı, RADIUS oturumu ve CRM abonesi tek sorguda birleştirilebiliyor.
• Kayıtlar zaman damgasıyla imzalanıyor; arşiv şifreli ve yedekli.
• Örnek bir IP/port/zaman sorgusu düzenli olarak test ediliyor.

Cetvel Yazılım, bu zinciri uç IP logu (CG-NAT) hizmeti ve BTK uyumlu 5651 log hizmeti kapsamında kuruyor ve işletiyor. CG-NAT topolojisinin tasarımı için network altyapı desteği sayfasına da göz atabilirsiniz.