Wi-Fi 802.1X Neden Başarısız Olur? RADIUS ve Sertifika

Kurumsal SSID’ye bağlanamayan bir kullanıcının ekranında çoğu zaman tek bir cümle vardır: “Bu ağa bağlanılamıyor.” Arkada ise üç taraf arasında onlarca mesaj gidip gelmiştir. İstemci, NAS ve RADIUS sunucusu bu mesajları taşır; NAS kablosuz ağda AP, controller ya da gateway olabilir. 802.1X’in nasıl çalıştığı, EAP-TLS ve PEAP farkı ve kablolu taraftaki sorun giderme sırası NAC: 802.1X, RADIUS ve MAB yazısında anlatıldı. Bu yazı o akışı tekrar etmiyor. Kablosuz ağda 802.1X başarısız olduğunda nereye bakılacağını, RADIUS sunucusunun gördüğü son mesajdan başlayarak anlatıyor.

Yazıdaki örnek adresler sitenin planından: istemci 10.0.20.25 (VLAN 20), RADIUS sunucusu 10.0.30.20. Yazıdaki bütün log ve mesaj örnekleri temsilidir; bir laboratuvarda ya da sahada kaydedilmemiştir.

Önce: RADIUS isteğini kim gönderiyor?

Kablosuz ağda istemcinin EAP mesajlarını RADIUS’a çeviren cihaza NAS denir. Hangi cihazın NAS olduğu mimariye göre değişir ve teşhisin ilk sorusu budur, çünkü RADIUS sunucusu isteği bu cihazın adresinden bekler:

Cisco Catalyst 9800: Merkezî kimlik doğrulamada istekleri controller gönderir. FlexConnect yerel kimlik doğrulamasında ise Cisco’nun yapılandırma belgesi, AP’nin RADIUS sunucusuna ağ cihazı olarak eklenmesini ilk adım olarak verir.
Cisco Meraki: Meraki’nin belgesine göre WPA2-Enterprise SSID’yi yayınlayan her gateway AP, sunucuda ayrı bir RADIUS istemcisi olarak tanımlanır; AP’ler LAN IP adresleriyle gelir. Meraki’nin RADIUS proxy özelliği açıldığında ise istekler AP’lerden değil Meraki bulutundan gelir ve sunucu bulutun adres aralıklarını tanımalıdır.
HPE Aruba AOS 10: Belgeye göre bridge modunda AP, istemci için NAS’tır ve RADIUS iletişimini kendisi başlatır. Tunnel modunda gateway RADIUS proxy olarak kimlik doğrulama ve accounting isteklerini iletir. Mixed modda tünellenen oturumlar için gateway’in IP adresi NAS IP olarak kullanılır.
Huawei: Huawei’nin kablosuz 802.1X örneğinde kimlik doğrulama noktası native AC işlevi gören switch’tir. RADIUS şablonu orada tanımlanır ve kimlik doğrulama için bir VLANIF adresi kaynak arayüz olarak kullanılır.
Fortinet: FortiGate’in yönettiği SSID’lerde Access-Request’i FortiGate gönderir. Fortinet’in belgesine göre FortiGate, standalone moddaki bir FortiAP’ye NAS-ID değerini iletebilir; bu durumda isteği FortiAP gönderir.

Aynı üreticide bile yanıt SSID’nin moduna ve sürüme göre değişir. Sunucuda “istek yok” görüldüğünde ilk iş, isteğin hangi cihazdan ve hangi adresten gelmesi gerektiğini netleştirmektir.

NAS-IP-Address ile kaynak IP aynı şey değildir

RADIUS paketinin içinde NAS-IP-Address adlı bir öznitelik bulunur, ama bu paketin gerçek kaynak adresi değildir. RFC 2865 bu ayrımı açıkça yapar: sunucu, isteği doğrulayacağı shared secret’ı NAS-IP-Address’e göre değil, paketin IP başlığındaki kaynak adrese göre seçmelidir. Fortinet’in belgesindeki örnek çıktıda istek 172.16.200.254 adresinden gelir, ama paketteki NAS-IP-Address 0.0.0.0’dır; NAS’ı tanımlayan değer NAS-Identifier’dır. Kaynak adres NAT ya da başka bir çıkış arayüzü yüzünden beklenenden farklıysa sunucu NAS’ı tanımaz. RFC 2865’e göre shared secret’ı olmayan bir istemciden gelen istek sessizce atılır, yani yanıt dönmez.

Portlar da karıştırılmamalıdır. RFC 2865’e göre kimlik doğrulama UDP 1812 kullanır, RFC 2866’ya göre accounting UDP 1813. İki port ayrı işler görür: 1813’ün açık olması tek başına kimlik doğrulamayı sağlamaz; 1812 kapalıysa istemci doğrulanmaz. Tersine, 1812 açık ve kimlik doğrulama çalışırken 1813 engellenmiş olabilir; bu durumda oturum kayıtları eksik kalır. Accounting’in erişimi etkileyip etkilemeyeceği platforma ve politikaya bağlıdır: bazı tasarımlarda oturum takibi accounting kayıtlarına dayanır, bazılarında accounting yalnızca kayıt amaçlıdır. Kullanılan NAS ve sunucunun belgesi bu davranışı belirler.

Bir oturum, birçok tur

Bir 802.1X oturumu tek bir istek ve yanıt değildir. EAP-TLS'te sertifikalar onlarca Access-Request ve Access-Challenge turunda taşınabilir; kırılma bu turların herhangi birinde olabilir.

802.1X oturumu tek bir istek ve yanıttan ibaret değildir. RFC 3579’a göre NAS, istemcinin EAP mesajını EAP-Message özniteliğiyle bir Access-Request içinde taşır. Sunucu henüz karar vermediyse bir sonraki EAP mesajını Access-Challenge ile geri gönderir, NAS bunu istemciye iletir ve istemcinin yanıtı yeni bir Access-Request ile sunucuya gider. Bu döngü yöntem bitene kadar sürer.

EAP-TLS’te tur sayısı belirgin biçimde artar. RFC 5216’ya göre bir sertifika mesajı MTU’dan ve 4096 baytlık RADIUS paket sınırından büyük olabileceği için EAP-TLS kendi parçalama mekanizmasını taşımak zorundadır. Her parça ayrı bir EAP Request ve Response ile taşınır; RADIUS tarafında da her biri ayrı bir Access-Challenge ve Access-Request turu demektir. Cisco’nun belgesi, ISE’nin kendi sertifikasını gönderirken veriyi 1002 baytlık parçalara böldüğünü ve her parça için ayrı bir tur yapıldığını gösterir. EAP-TLS 1.3’ü tanımlayan RFC 9190 da bazı EAP uygulamalarının ve erişim ağlarının işleyebileceği tur sayısını sınırlayabildiğini belirtir; parçalamayı azaltmak için sertifikaların küçük, zincirlerin kısa tutulmasını önerir.

RFC 3579, EAP-Message taşıyan bütün paketlerde Message-Authenticator özniteliğini zorunlu tutar. Bu özniteliği doğrulanamayan bir isteği sunucu sessizce atar. Yanlış bir shared secret bu yüzden çoğu zaman bir Reject olarak değil, yanıt gelmeyen bir istek olarak görünür.

Beş başlangıç noktası

Teşhise sunucunun gördüğü son mesajla başlanır, ama karar üç tarafın kanıtıyla verilir.

Teşhise RADIUS sunucusunun bu oturum için gördüğü son mesajla başlamak işi daraltır. Ama bu bir başlangıç noktasıdır, kesin neden değil. Logun son satırı yalnızca konuşmanın nerede durduğunu söyler, neden durduğunu değil. Aynı oturum için istemci logu, NAS’ın kayıtları ve sunucu logu birlikte okunur; gerekirse NAS’ta ve sunucuda aynı anda paket yakalanır.

1. Access-Request görünmüyor

Sunucuda istek yoksa bu otomatik olarak ağ kesintisi demek değildir. Dört olasılık birlikte değerlendirilir:

İstemci EAP’yi hiç başlatmamış olabilir. İstemcinin ağ profili SSID’nin güvenlik ayarıyla uyuşmuyorsa (örneğin Enterprise yerine Personal bekliyorsa) ilişkilendirme aşamasında kalır. İstemcinin kendi olay kaydı ve NAS’taki istemci olayları bunu gösterir.
NAS isteği oluşturmamış olabilir. SSID’ye bir RADIUS sunucusu ya da sunucu grubu bağlanmamış, sunucu NAS tarafında erişilemez olarak işaretlenmiş olabilir.
İstek yolda kalmış olabilir. Aradaki bir firewall ya da ACL UDP 1812’yi engelliyor olabilir.
İstek ulaşmış ama sunucu onu kayda değer bulmamış olabilir. Kaynak adres sunucuda tanımlı bir NAS değilse istek sessizce atılır. Bazı sunucular bunu ayrı bir olay olarak kaydeder, bazıları kimlik doğrulama logunda hiç göstermez. Sunucunun önünde paket yakalamak, isteğin gerçekten gelip gelmediğini ayırır.

2. Request var ama yanıt görünmüyor

Sunucu isteği aldıysa iki ihtimal kalır: yanıt hiç üretilmedi ya da üretildi ama NAS’a dönmedi.

Yanıt üretilmediyse: Yanlış shared secret ya da doğrulanamayan Message-Authenticator yüzünden istek sessizce atılmış olabilir. Sunucu kullanıcıyı sorguladığı dizinden zamanında yanıt alamamış da olabilir.
Yanıt dönmediyse: Dönüş yolu farklı bir firewall’dan geçiyor (asimetrik yol), NAT dönüşü eşleşmiyor ya da yanıt başka bir adrese gidiyor olabilir.

NAS bu sırada isteği tekrar gönderir ve tanımlıysa yedek sunucuya geçer. Huawei’nin RADIUS anlatımı, birincil ve yedek sunucu ile yeniden gönderme mekanizmalarını bu tür kayıplara karşı tanımlar. Sunucunun “gönderdim” dediği yanıtın NAS’a ulaşıp ulaşmadığı iki uçta yapılan yakalamayla doğrulanır.

3. Access-Challenge turları tamamlanmıyor

Sunucu Challenge göndermiş ama oturum bir yerde durmuşsa önce hangi turda durduğuna bakılır. Hep aynı yerde, örneğin sunucu sertifikasının gönderildiği turlarda duruyorsa iki aday öne çıkar.

İstemci sunucu sertifikasını reddetmiş olabilir. Sunucu sertifikası yenilendiğinde yeni sertifika farklı bir ara CA’dan geliyor, farklı bir ad taşıyor ya da istemcinin profili eski adı bekliyor olabilir. İstemci bu durumda el sıkışmayı keser. Bu her zaman sunucuda açık bir Access-Reject olarak görünmez; sunucu tarafında yarım kalmış bir oturum ya da zaman aşımı görülebilir ve bunun nasıl adlandırıldığı ürüne göre değişir. Nedeni çoğu zaman istemcinin kendi logu gösterir.

Büyük parçalar yolda kayboluyor olabilir. Burada iki ayrı parçalama birbirine karıştırılmamalıdır:

EAP-TLS’in kendi parçalaması: Sunucu ya da istemci, TLS mesajlarını EAP katmanında kendisi böler (RFC 5216, RFC 9190). Bu parçalar ayrı EAP turlarıdır ve normaldir.
IP, RADIUS ve tünel düzeyinde parçalama: Bir EAP parçası RADIUS öznitelikleriyle birlikte paketin sığabileceği boyutu aşarsa IP paketi bölünür. Cisco’nun belgesi bu zinciri gösterir: istemci sertifikasını MTU’ya yakın parçalarla gönderir, AP CAPWAP başlığını eklemek için paketi yeniden böler, controller paketi birleştirip yaklaşık 400 baytlık RADIUS özniteliği ekler ve sunucuya giderken paketi bir kez daha böler. Yolda bir VPN ya da başka bir tünel varsa parçalar yeniden bölünebilir. IP parçalarını düşüren ya da yeniden birleştiremeyen bir firewall bu noktada oturumu durdurur.

Üreticiler bu boyutu kontrol etmek için farklı yollar sunar. Cisco 9800’de controller, RADIUS isteklerini varsayılan olarak 1396 baytta böler. Belgeye göre IOS XE 17.11 ile, sunucu grubuna bir kaynak arayüz tanımlandığında istekler o arayüzün MTU’su ile bölünür; böylece tünel olan yollar için daha küçük bir değer seçilebilir. Huawei’nin kablosuz 802.1X örneği ise Access-Challenge içindeki EAP verisi 1200 baytı aştığında istemcinin EAP isteğini alamayabileceğini not eder ve Framed-MTU özniteliğini 1000’e düşürür. Belge, bazı üçüncü taraf RADIUS sunucularının bu özniteliği desteklemediğini de belirtir. RFC 3579’a göre Framed-MTU, sunucunun gönderdiği EAP verisinin boyutunu sınırlamak için kullanılır.

4. Access-Reject dönüyor

Reject, sunucunun bir karar verdiği anlamına gelir ve bu kararın nedenini en iyi sunucunun kendi kaydı söyler. NAS genellikle yalnızca Reject’i görür. Tipik adaylar:

Yanlış kullanıcı adı ya da parola, kilitli ya da devre dışı hesap.
İstemci sertifikasının süresinin dolması, iptal edilmesi ya da sunucunun güvenmediği bir CA’dan gelmesi.
Oturumun beklenen politikaya uymaması: SSID, NAS grubu, cihaz tipi ya da zaman koşulu eşleşmemiş olabilir.

Reject nedeni yanlış politikayı gösteriyorsa sorun kimlikte değil, politika sırasındadır; bu kısım NAC yazısında anlatıldı.

5. Access-Accept geliyor ama trafik çalışmıyor

Accept, yalnızca kimlik doğrulamanın başarılı olduğunu söyler. Arkasından birbirinden ayrı dört adım gelir ve her biri ayrı bozulabilir:

4-way handshake: Kimlik doğrulamanın sonunda oluşan anahtar malzemesiyle istemci ve NAS oturum anahtarlarını üretir. El sıkışma tamamlanmazsa istemci “kimlik doğrulandı” sonrasında bile bağlantıyı kurmaz. NAS’taki istemci olayları bunu gösterir.
VLAN ya da rol atanması: RADIUS bir VLAN ya da rol döndürdüyse, bunun hangi cihazda uygulanması gerektiği forwarding mimarisine bağlıdır. Local bridge ya da local switching’de istemci trafiği AP’den kablolu ağa çıkar; atanan VLAN AP’nin bağlı olduğu switch portunda tanımlı ve izinli olmalıdır. Controller ya da gateway üzerinden tunnel forwarding’de trafik tünelle taşınır ve kablolu ağa orada çıkar; bu durumda VLAN’ın AP’nin portunda değil, controller’ın ya da gateway’in kablolu arayüzünde bulunması gerekir. Rol ve politikanın uygulandığı nokta da aynı mimariye göre değişir (Local Bridge mı, Tunnel Forwarding mi?, VLAN).
DHCP: İstemci yeni VLAN’da adres alamıyor olabilir. Bu ayrı bir teşhis konusudur (AP Online Ama İstemci IP Alamıyor).
Veri yolu: Adres alınmış ama bir ACL ya da rol politikası trafiği kısıtlıyor olabilir (Wi-Fi Bağlı Ama İnternet Yok).

Bu adımlarda sorun yaşayan bir istemci için RADIUS logu “başarılı” der. Kimlik doğrulamayı yeniden incelemek yerine Accept’ten sonraki adımlara geçilir.

Sertifika sorunlarında doğrulamayı kapatmadan kontrol

Sertifika hatası gören bir yöneticinin ilk refleksi, istemcide sunucu sertifikası doğrulamasını kapatmak olabilir. Bu bir çözüm değildir. RFC 9190’a göre sunucu adı eşleştirilmezse istemcinin doğru sunucuyla konuştuğuna olan güven azalır; açık bir kök CA ile ad eşleştirmesi kullanılmıyorsa o CA’dan sertifika alan herhangi bir sunucu güvenilir görünür. Doğrulamayı kapatmak bu yüzden ağı sahte bir erişim noktasına açar. Bunun yerine şunlar kontrol edilir:

CA zinciri: İstemci, sunucu sertifikasını imzalayan kök ve ara CA’ya güveniyor mu? Yenilenen sertifika yeni bir ara CA’dan geliyorsa istemcilere bu zincir dağıtıldı mı?
Ad (SAN/FQDN): RFC 9190’a göre sunucu kimliği genellikle sertifikanın SubjectAltName alanındaki FQDN’dir ve istemci profili bu adla eşleştirme yapar. Microsoft’un belgesi de kablosuz istemciler için SubjectAltName’in sunucunun FQDN’ini içermesini ve sertifikada Server Authentication amacının bulunmasını şart koşar. Yeni sertifikanın adı eski profildeki adla aynı mı?
Geçerlilik ve saat: Sertifikanın geçerlilik aralığı hem sunucunun hem istemcinin saatine göre değerlendirilir. Saati yanlış olan bir cihaz geçerli bir sertifikayı geçersiz görebilir.
İstemci profili: Yönetilen cihazlarda güvenilen CA’lar ve sunucu adları MDM ya da grup ilkesiyle dağıtılır. Profil eski değerleri taşıyorsa sertifika doğru olsa da bağlantı kurulmaz.

Kalıcı çözüm, sertifika yenilemesini istemci profilleriyle birlikte planlamaktır: yeni CA ya da ad, yenileme gününden önce profillere eklenir. EAP yöntemlerinin ve PKI tasarımının ayrıntısı ayrı bir yazının konusu.

Kendinizi deneyin

Alıştırma 1: Kurumsal SSID’nin RADIUS sunucusunun sertifikası dün yenilendi. Bu sabah yöneticinin dizüstüleri bağlanıyor. Kişisel telefonlarını kurumsal SSID’ye elle tanımlamış bazı kullanıcılar ise bağlanamıyor. Sunucu logunda bu telefonlar için Access-Reject yok; oturumlar Access-Challenge turlarının ortasında kalmış görünüyor. Olası neden, onu doğrulayacak kanıt ve bir sonraki kontrol nedir?

Cevap ve açıklama

Olası neden: Telefonlar yeni sunucu sertifikasını reddediyor ve el sıkışmayı kesiyor. Yönetilen dizüstüler muhtemelen yeni CA’yı ve sunucu adını içeren güncel bir profil almış. Elle tanımlanan telefonlar ise ilk bağlantıda kabul ettikleri eski sertifikaya ya da eski ada göre karar veriyor olabilir. Yeni sertifika farklı bir ara CA’dan geliyorsa ya da SAN’daki ad değiştiyse bu beklenen bir sonuçtur.
Kanıt: Sunucuda Reject olmaması ve oturumların sunucu sertifikasının gönderildiği turlarda kalması bu ihtimali destekler, ama tek başına kanıtlamaz. Asıl kanıt telefonun kendi kaydıdır: sertifika güveni ya da ad uyuşmazlığı hatası. Eski ve yeni sertifikanın issuer, SAN ve geçerlilik alanları da karşılaştırılır.
Sonraki kontrol: Telefonların cihaz saatleri ve hangi CA’ya güvendikleri kontrol edilir. Çözüm doğrulamayı kapatmak değildir. Kişisel cihazlar için doğru CA ve sunucu adını içeren bir yapılandırma profili dağıtılır ya da kullanıcılara bağlantıyı yeni bilgilerle yeniden tanımlamaları anlatılır. Bir sonraki yenilemede yeni CA ve ad, yenileme gününden önce profillere eklenir.

Alıştırma 2: Bir şubede AP’ler bridge modunda ve her AP RADIUS isteğini kendisi gönderiyor. İstekler merkezdeki RADIUS sunucusuna (10.0.30.20) bir IPsec tüneli üzerinden gidiyor. PEAP-EAP-MSCHAPv2 kullanan, yani istemcinin kullanıcı adı ve parolayla doğrulandığı eski bir SSID sorunsuz. Yeni EAP-TLS SSID’sinde ise istemciler bağlanamıyor. Sunucu logunda oturumlar, istemcinin kendi sertifikasını göndermesi gereken turda duruyor. Olası nedenler, kanıt ve sonraki kontrol nedir?