RADIUS sunucu nedir? ISS'ler için neden vazgeçilmez?

RADIUS protokolü ve AAA

RADIUS (Remote Authentication Dial In User Service), bir ağ erişim sunucusu (NAS) ile merkezi bir kimlik doğrulama sunucusu arasındaki iletişimi tanımlayan protokoldür. Adındaki "dial in" ifadesi çevirmeli bağlantı dönemine işaret etse de protokol bugün PPPoE, IPoE, Wi-Fi (802.1X) ve VPN erişimlerinde yaygın olarak kullanılmaktadır. Protokolün çekirdeği iki IETF belgesinde tanımlıdır: RFC 2865 kimlik doğrulama ve yetkilendirmeyi, RFC 2866 ise accounting'i düzenler. RADIUS, UDP üzerinde çalışır (doğrulama için 1812, accounting için 1813 numaralı portlar) ve paketler NAS ile sunucu arasında paylaşılan bir gizli anahtarla (shared secret) doğrulanır.

RADIUS'un yaptığı iş üç harfle özetlenir, AAA:

• Authentication (kimlik doğrulama): Bağlanmak isteyen abone gerçekten iddia ettiği kişi mi? Kullanıcı adı ve parola (PAP, CHAP, MS-CHAPv2) ya da MAC adresi, devre kimliği gibi öznitelikler kontrol edilir.
• Authorization (yetkilendirme): Doğrulanan abone neye hak kazanıyor? Hız profili, IP adresi veya havuzu, VLAN, oturum süresi gibi parametreler NAS'a bildirilir.
• Accounting (kayıt): Abone ne zaman bağlandı, ne zaman ayrıldı, ne kadar veri aktardı? Oturum verileri sunucuda saklanır.

Bir ISS için RADIUS sunucu, ağ altyapısı ile ticari sistem (CRM) arasındaki köprüdür. Abonenin ağa girişi bu köprüden geçer; bu nedenle ISS operasyonunun en kritik bileşenlerinden biridir.

PPPoE / IPoE abone doğrulama akışı

Türkiye'deki ISS'lerde en yaygın erişim yöntemi PPPoE'dir; IPoE (DHCP tabanlı erişim) özellikle fiber ağlarda giderek yaygınlaşmaktadır. PPPoE RADIUS akışı adım adım şöyle ilerler:

IPoE'de akış benzer, ancak kimlik bilgisi yerine DHCP istemci kimliği, MAC adresi ya da Option 82 ile taşınan devre kimliği kullanılır; abone "giriş yapmaz", bağlı olduğu port üzerinden tanınır.

Yetkilendirme: hız profili, IP havuzu, VLAN

Access-Accept paketinde taşınan öznitelikler, abonenin ağdaki "haklarını" belirler. Standart öznitelikler (Framed-IP-Address, Framed-Pool, Session-Timeout, Idle-Timeout) RFC'lerde tanımlıdır; hız profili gibi üreticiye özgü ayarlar ise Vendor-Specific Attribute (VSA) olarak taşınır. Tipik yetkilendirme parametreleri:

Hız profilinin CRM'deki paketten türetilmesi kritik önemdedir: Abone paketini yükselttiğinde yeni hızın RADIUS'a ve oradan BNG'ye yansıması elle yapılıyorsa, hata ve gecikme kaçınılmazdır.

Accounting ve 5651 / uç IP logu ilişkisi

RFC 2866 ile tanımlanan accounting, oturumun yaşam döngüsünü üç tür paketle kayıt altına alır: Start (oturum kuruldu), Interim-Update (oturum sürüyor; belirli aralıklarla hacim ve durum bilgisi) ve Stop (oturum sonlandı; toplam hacim ve sonlanma nedeni). Her paket oturumu tekil olarak tanımlayan Acct-Session-Id, abonenin kullanıcı adı, atanan IP (Framed-IP-Address), NAS kimliği ve zaman bilgisi taşır.

Bu kayıtlar, erişim sağlayıcıların 5651 sayılı Kanun kapsamında saklamakla yükümlü olduğu trafik bilgisinin temel kaynağıdır: "Bu IP, bu zaman aralığında hangi aboneye atanmıştı?" sorusunun yanıtı doğrudan accounting kaydından bulunur. CG-NAT kullanan ağlarda ise accounting kaydı, abonenin iç IP'sini verir; genel IP:port eşleşmesi NAT cihazının kaydından alınır ve iki kayıt oturum/zaman üzerinden birleştirilir. Bu zincirin ayrıntısı için 5651 log yükümlülüğü rehberi ve uç IP logu nedir? yazılarına bakabilirsiniz.

Accounting kayıtlarının güvenilir olması için üç koşul gerekir: NAS'ta accounting'in tüm oturumlar için etkin olması, Interim-Update aralığının makul bir değere ayarlanması (çok seyrek aralık uzun oturumlarda kör noktalar oluşturur) ve RADIUS sunucunun accounting paketlerini kaybetmeden yazması. Yoğun ağlarda accounting yükü, doğrulama yükünden çok daha büyük olabilir; sunucu kapasitesi buna göre planlanmalıdır.

CoA ve Disconnect ile anlık işlem

Klasik RADIUS'ta sunucu yalnızca NAS'tan gelen isteklere yanıt verir; oturum kurulduktan sonra aboneye müdahale edemez. RFC 5176 (Dynamic Authorization Extensions) bu sınırı kaldırır ve sunucunun NAS'a iki tür mesaj göndermesine izin verir:

• Disconnect-Request: Belirli bir oturumu sonlandırır. Abone yeniden bağlanmaya çalıştığında güncel kurallar uygulanır. Tipik kullanım: borcunu ödemeyen abonenin kapatılması.
• CoA-Request (Change of Authorization): Oturumu düşürmeden yetkilendirme özniteliklerini değiştirir. Tipik kullanım: paket yükseltmede hız profilinin anında güncellenmesi, ödeme sonrası kısıtlı profilden normal profile geçiş.

CoA desteği, CRM'de yapılan işlemin aboneye yansıma süresini saatlerden saniyelere indirir. Borçlu kapatma ve ödeme sonrası açma akışlarının otomatik çalışması, hem tahsilat disiplinini hem de abone memnuniyetini doğrudan etkiler. WiRadius abone yönetimi modülündeki otomatik açma-kapama bu mekanizma üzerine kuruludur.

BNG / NAS uyumluluğu

RADIUS protokolü standart olsa da hız profili, kota ve bazı oturum parametreleri üreticiye özgü VSA'larla taşınır. Bu nedenle bir RADIUS sunucunun "çalışması" yetmez; kullandığınız BNG'nin (örneğin Huawei NetEngine, Mikrotik, Cisco ASR, Juniper MX) VSA sözlüğünü tanıması, CoA biçimini desteklemesi ve o cihazın accounting davranışına (Interim aralığı, Stop nedenleri) uyumlu olması gerekir. Birden fazla üreticiden BNG kullanan ISS'lerde, aynı abone profili için her üreticiye ayrı VSA seti üretebilen bir sunucu operasyonu sadeleştirir.

Yüksek erişilebilirlik ve yedeklilik

RADIUS sunucu durduğunda yeni abone oturumları kurulamaz; mevcut oturumlar sürse de yeniden bağlanan her abone düşer. Bu, ISS için doğrudan hizmet kesintisidir. Yedeklilik için yaygın yaklaşımlar:

• BNG üzerinde birincil ve ikincil RADIUS sunucu tanımı; birincil yanıt vermezse otomatik geçiş (failover) ve sağlık kontrolü (Status-Server).
• Sunucuların farklı fiziksel konum veya altyapıda çalışması; tek bir güç veya ağ arızasının her ikisini etkilememesi.
• Abone veritabanının sunucular arasında senkron tutulması; ikincil sunucunun güncel verilerle doğrulama yapabilmesi.
• Accounting kayıtlarının her iki sunucudan merkezi bir depoya akması; failover sırasında kayıp olmaması.
• Kapasite planlaması: Toplu kesinti sonrası binlerce abonenin aynı anda yeniden bağlanması (reconnect fırtınası) senaryosunun test edilmesi.
• İzleme ve uyarı: Access-Reject oranı, yanıt süresi ve accounting kuyruğu gibi metriklerin sürekli izlenmesi.

CRM ile senkronun önemi

RADIUS'taki abone kaydı ile CRM'deki abone kaydı aynı gerçeğin iki görünümüdür. İkisi arasındaki senkron kopukluğu şu sorunları doğurur: Borçlu abonenin açık kalması (gelir kaybı), ödeme yapan abonenin kapalı kalması (memnuniyet kaybı), paket değişikliğinin hız profiline yansımaması (destek talebi), iptal edilen abonenin hesabının silinmemesi (güvenlik ve lisans sorunu). Senkronun elle, dışa aktar / içe aktar yöntemiyle yapıldığı ISS'lerde bu sorunlar rutin hale gelir.

Doğru yaklaşım, CRM'in RADIUS'a doğrudan ve gerçek zamanlı yazmasıdır: Yeni abonelik → RADIUS hesabı; paket değişikliği → yeni profil ve CoA; fatura vadesi geçti → kısıtlı profil ve CoA; ödeme alındı → normal profil ve CoA; iptal → hesap kapatma ve Disconnect. WiRadius bu akışları PPPoE/RADIUS senkronu olarak sunar; RADIUS sunucuyu hizmet olarak almak isteyen ISS'ler için ise RADIUS sunucu yazılımı sayfamızda kapsamı bulabilirsiniz.

FreeRADIUS mi, ISS'ye özel RADIUS mu?

FreeRADIUS, dünyada en yaygın kullanılan açık kaynaklı RADIUS sunucudur; olgun, performanslı ve çok sayıda üretici sözlüğünü destekler. Pek çok ISS'ye özel RADIUS çözümü de temelde FreeRADIUS veya benzeri bir çekirdek üzerine kurulur. Dolayısıyla soru "hangisi daha iyi protokol konuşur" değil, "operasyonu kim ve nasıl yönetecek" sorusudur.

Her iki yol da doğru olabilir. Deneyimli bir sistem ekibiniz varsa ve senkron katmanını kendiniz geliştirebiliyorsanız FreeRADIUS tabanlı özel kurulum maliyet açısından avantajlıdır. Ekibinizin odağı ağ işletimi ise ve RADIUS'un CRM, faturalama ve log zinciriyle hazır konuşmasını istiyorsanız ISS'ye özel bir çözüm toplam sahip olma maliyetini düşürür. Bu kararı ISS yazılımının bütünü içinde değerlendirmek için ISS yazılımı nedir, nasıl seçilir? yazısına bakabilirsiniz.