Okuma: ~3 dk
Wi-Fi Şifresi Doğru Ama Kabul Edilmiyor
Kullanıcı şifreyi harfi harfine doğru girdiğinden emin ama cihaz bağlanamıyor veya bağlanıp hemen düşüyor. Bu belirti çoğu zaman şifre hatası değil, WPA2/WPA3 geçiş modu, PMF zorunluluğu veya eski istemci uyumsuzluğudur. Bu yazıda bu sorunların kök nedenlerini ve 4-way handshake hatalarını inceliyoruz.
- Teknik inceleme bekliyor
Şifre Doğru Olduğu Halde Bağlanamama Neden Mümkün?
WPA2-Personal ve WPA3-Personal gibi PSK tabanlı güvenlik modlarında, kullanıcının girdiği parola doğrudan ağa gönderilmez. Parola, SSID ile birlikte PBKDF2 algoritmasından geçirilerek bir PSK (Pre-Shared Key) türetilir; bu PSK daha sonra 4 yönlü el sıkışma (4-way handshake) sırasında kullanılan PTK'nın (Pairwise Transient Key) hesaplanmasında kullanılır. Yani 'şifrenin doğru olması', güvenlik protokolünün her adımının sorunsuz tamamlanacağı anlamına gelmez.
4-way handshake sırasında istemci ve AP arasında dört EAPOL mesajı değiş tokuş edilir. Bu mesajlardan herhangi biri RF kaybı, zamanlama sorunu veya protokol uyumsuzluğu nedeniyle kaybolursa, istemci tarafı 'yanlış şifre' hatası gösterebilir — oysa gerçek şifre doğrudur ve sorun tamamen protokol seviyesindedir. Bu, kullanıcıları ve hatta deneyimsiz BT ekiplerini yanıltan en klasik durumdur.
- 1 Mesaj 1 (AP→İstemci)
AP, ANonce değerini gönderir
- 2 Mesaj 2 (İstemci→AP)
İstemci SNonce ve MIC değerini gönderir, PTK hesaplanır
- 3 Mesaj 3 (AP→İstemci)
AP, GTK'yı ve kurulum onayını gönderir
- 4 Mesaj 4 (İstemci→AP)
İstemci onayı tamamlar, şifreleme devreye girer
Bu dört mesajdan biri kaybolursa istemci genelde 'yanlış şifre' veya 'kimlik doğrulama hatası' gösterir; gerçek sebep RF veya zamanlama olabilir.
WPA2/WPA3 Geçiş Modu (Transition Mode) Sorunları
Kurumsal ve ev tipi birçok ağda, eski cihazlarla uyumluluğu korumak amacıyla WPA2/WPA3 Transition Mode kullanılır. Bu modda aynı SSID hem WPA2 hem WPA3 istemcilerini kabul eder; AP, beacon ve probe response içinde her iki güvenlik protokolünü de ilan eder. Teoride sorunsuz çalışması gereken bu yapı, sahada sık sık uyumsuzluklara yol açar çünkü bazı eski Wi-Fi çipsetleri (özellikle 2015 öncesi üretilmiş IoT cihazlar, eski yazıcılar, bazı Android sürümleri) RSN (Robust Security Network) bilgi elemanındaki çifte protokol ilanını doğru ayrıştıramaz.
Bu uyumsuzluk, cihazın ya hiç bağlanamaması ya da bağlanıp saniyeler içinde düşmesi şeklinde kendini gösterir. Sorunun ayırt edici özelliği, aynı SSID'ye yeni nesil bir telefonun sorunsuz bağlanırken, eski bir IoT cihazının sürekli başarısız olmasıdır — bu, şifre sorunundan ziyade protokol uyumsuzluğuna işaret eden güçlü bir ipucudur.
Pratik çözüm, eski cihaz filosu büyük olan ortamlarda ayrı bir WPA2-only SSID oluşturmak ya da geçici olarak transition mode yerine saf WPA2-PSK kullanmaktır. Mümkünse eski cihazların üretici yazılımı (firmware) güncellenerek WPA3/transition mode uyumluluğu da iyileştirilebilir.
PMF (Protected Management Frames) Zorunluluğu
WPA3, yönetim çerçevelerinin korunmasını sağlayan PMF'yi (802.11w) zorunlu kılar; WPA2 ortamlarında ise PMF isteğe bağlıdır ve bazı eski istemciler onu hiç desteklemez. Transition mode'da genellikle PMF 'optional' (capable) olarak ayarlanır, ancak bazı yapılandırmalarda yanlışlıkla 'required' (zorunlu) seçilir. Bu durumda PMF desteklemeyen eski istemciler bağlanma aşamasında sessizce reddedilir ve kullanıcı yalnızca 'bağlanamadı' mesajı görür — sebep hiçbir yerde açıkça belirtilmez.
PMF zorunluluğu kaynaklı sorunların teşhisi için AP/WLC üzerindeki WLAN güvenlik ayarlarında PMF değerinin kontrol edilmesi yeterlidir. Eğer ortamda hala PMF desteklemeyen cihazlar varsa, PMF 'optional' olarak bırakılmalı; sadece tüm istemci filosunun WPA3 ve PMF uyumlu olduğu doğrulanmış ortamlarda 'required' tercih edilmelidir.
- PMF 'required' → eski istemciler reddedilir, çözüm 'optional' yapmaktır (eğer eski cihaz varsa)
- WPA3-only SSID → sadece WPA3 destekleyen cihazlar bağlanabilir
- Transition mode → geniş uyumluluk ama bazı eski çipsetlerde sorun riski
- Ayrı WPA2-only SSID → eski IoT/cihaz filosu için güvenli alternatif
Diğer Yaygın Nedenler: Özel Karakterler, 802.1X ve Zamanlama
Bazı durumlarda sorun gerçekten şifreyle ilgilidir ama görünenden farklı bir şekilde: parolada Türkçe karakter (ı, ğ, ş gibi) veya klavye düzenine bağlı özel karakterler kullanılmışsa, farklı işletim sistemleri bu karakterleri farklı kodlayabilir ve PSK türetimi istemci ile AP arasında tutarsız sonuç verebilir. Kurumsal ortamlarda parola politikasında yalnızca ASCII standart karakter seti kullanılması önerilir.
802.1X (WPA2/WPA3-Enterprise) ortamlarında ise 'şifre kabul edilmiyor' belirtisinin arkasında genellikle sertifika sorunları yatar: RADIUS sunucusunun sertifikasının süresi dolmuş olabilir, istemci cihazın güven deposunda (trust store) kök sertifika eksik olabilir veya EAP yöntemi (PEAP, EAP-TLS) istemci ile sunucu arasında uyuşmayabilir. Bu durumda kullanıcı adı/şifre doğru olsa bile RADIUS sunucusu kimlik doğrulamayı reddeder.
Son olarak, 4-way handshake'in zaman aşımına uğraması da mümkündür: özellikle yoğun RF ortamlarında veya istemci zayıf sinyal bölgesindeyken EAPOL mesajları gecikebilir, AP varsayılan zaman aşımı süresi içinde yanıt alamayınca el sıkışmayı iptal eder. Bu, görünürde 'şifre hatası' gibi algılanan ama aslında saf bir RF/zamanlama sorunudur.
F2 Sahada Nasıl Çözüyor?
F2 mühendisleri 'şifre kabul edilmiyor' şikayetlerinde önce sorunun tek bir cihaz tipine mi yoksa tüm istemcilere mi özgü olduğunu ayırt eder; bu basit ayrım, protokol uyumsuzluğu ile gerçek RF/zamanlama sorununu birbirinden hızlıca ayıklamaya yeter. Saha ölçümlerinde Ekahau ile ilgili bölgedeki sinyal kalitesi doğrulanır, WLC/AP günlüklerinde 4-way handshake hangi mesajda kesiliyor tespit edilir ve PMF/transition mode ayarları mevcut cihaz envanterine göre optimize edilir. Kurumsal 802.1X projelerinde F2, RADIUS sertifika zincirini ve EAP yöntemi uyumluluğunu kurulum öncesi test ortamında doğrulayarak bu tür sorunların üretim ağında hiç yaşanmamasını sağlar.