Uyku Modundan Sonra Wi-Fi Bağlanmıyor: Yeniden Bağlanma Zinciri

Uyanınca tam olarak hangi aşama aksıyor?

Dizüstü bilgisayar uyandırıldığında simgede Wi-Fi görünmesi internete erişildiği anlamına gelmez. Uyanma sırasında radyo yeniden açılır, ağ taranır, AP seçilir, güvenlik oturumu kurulur, IP adresi yenilenir ve uygulamalar eski bağlantılarını toparlamaya çalışır. Bu zincirin bir basamağı yavaşlarsa şikayet ‘Wi-Fi bağlanmıyor’ olarak gelir. Önce zaman damgalı gözlem yapın: ekran açıldıktan sonra SSID kaç saniyede görünüyor, bağlantı hangi BSSID ve kanalda kuruluyor, IP adresi ne zaman geliyor, varsayılan ağ geçidi yanıt veriyor mu? Bu dört veri, sorunu soyut bir his yerine ölçülebilir bir olaya dönüştürür.

Sorun tek modeldeyse sürücü ve güç yönetimi; tüm modellerde aynı AP çevresindeyse ağ yapılandırması daha olasıdır. Sorunu yeniden üretirken hem kısa uyku hem uzun uyku denemesi yapın: kısa uyku mevcut DHCP kirasını koruyabilir, uzun uyku sırasında kira veya kimlik doğrulama oturumu bitebilir. Kablolu bağlantıda aynı davranışın olup olmadığını not edin. Telefonda ekran kapanması ile bilgisayarın sistem uykusu aynı şey değildir; test senaryosunu cihaz türüne göre kurun. Yeniden başlatmanın düzeltiyor olması kök nedeni açıklamaz; yalnız durum bilgisinin sıfırlandığını gösterir.

Radyo, sürücü ve güç tasarrufu

İstemci güç tasarrufu için radyoyu kapatabilir veya dinleme aralıklarını uzatabilir. Uyandırma sonrasında sürücü önceki BSSID'ye dönmeye çalışırken AP kanal değiştirmiş, kapanmış veya yeni bir güvenlik anahtarı kullanmaya başlamış olabilir. Olay kayıtlarında tarama, association ve deauthentication zamanlarını arayın. Bir 802.11 paket yakalaması, istemcinin hiç deneme gönderip göndermediğini ve AP'nin nasıl yanıtladığını ayırır. AP tarafında hiçbir deneme görünmüyorsa ağ politikasını değiştirmeden önce istemci radyosu, işletim sistemi ve sürücüye odaklanın. Üreticinin güncel ve onaylı sürücüsüyle sınırlı bir pilot test yapın.

Enerji tasarrufunu herkes için kapatmak ilk çözüm olmamalıdır: pil ömrünü düşürür ve temel uyumsuzluğu gizleyebilir. Önce etkilenen sürümün bilinen sorunlarını, uyku durumlarını ve belirli bantlarda görülen davranışı karşılaştırın. Yalnız 6 GHz'te gecikiyorsa keşif davranışı, yalnız bir AP grubunda gecikiyorsa kanal veya güvenlik profili incelenebilir. AP üzerinde band steering veya minimum veri hızı politikası varsa uyanan istemci ilk association denemesinde reddediliyor olabilir. İstemci ve AP saatleri eşitlenmiş kayıtlardan aynı olayı eşleştirmek, tahminle parametre değiştirmekten daha güvenilirdir.

Güvenlik oturumu ve IP yenileme

Kurumsal 802.1X ağında cihaz uyurken PMK önbelleği, sertifika oturumu veya RADIUS koşulları değişebilir. İstemci ilişkilendirilmiş görünse bile EAP kimlik doğrulaması tamamlanmadan kullanıcı trafiği geçmez. İstemci kaydındaki EAP hata türünü, RADIUS Access-Reject nedenini ve sertifika geçerliliğini inceleyin. Parola değiştiyse veya kullanıcı oturumu kapanmışsa kablosuz ağ otomatik yeniden bağlanamayabilir. Uyarıyı kapatmak için sertifika doğrulamasını devre dışı bırakmayın; sunucu adı, sertifika zinciri, zaman ayarı ve profil dağıtımını düzeltin. Kişisel ağlarda ise WPA3 geçiş modu ile eski sürücülerin etkileşimi ayrı incelenmelidir.

Association başarılı ve kimlik doğrulama tamam olsa bile IP yenilemesi aksayabilir. Uyanma sonrasında eski IP adresi, değişmiş VLAN, dolu DHCP havuzu veya geciken DHCP yanıtı erişimi keser. İstemcinin IP, ağ geçidi ve DNS bilgilerini uykudan önce ve sonra karşılaştırın; DHCP Discover/Request/ACK akışını AP'nin kablolu çıkışında izleyin. 169.254 ile başlayan kendiliğinden atanmış adres, DHCP zincirinin tamamlanmadığına işaret eder fakat nedenin AP, VLAN veya sunucu olduğunu tek başına söylemez. İstemci doğru IP'yi aldıysa ağ geçidine ping atıp DNS sorgusuyla uygulama katmanını ayrıca sınayın.

Kalıcı çözüm nasıl doğrulanır?

Tek bir başarılı uyanma güvenilir kanıt değildir. Etkilenen cihazla kısa ve uzun uyku döngülerini art arda tekrarlayın; cihazı farklı AP'lerin bulunduğu iki konumda deneyin. Her döngüde bağlanma süresi, BSSID, IP ve uygulama erişimi kaydedilsin. Sürücü güncellemesi yaptıysanız güncel sürümün diğer bantlar ve dolaşım üzerindeki etkisini de izleyin. Ağ politikasını değiştirdiyseniz yalnız arızalı cihazı değil, aynı SSID'deki farklı istemci sınıflarını pilot gruba alın. Böylece eski bir sürücü için yapılan gevşetmenin tüm ağa yayılması önlenir.

F2'nin sorun giderme sırası kullanıcı deneyiminden başlayıp olay kaydı ve paket akışına iner. ‘Uyku sonrası ağ yok’ olayını radyo, kimlik, adres ve uygulama olarak böldüğünüzde, her katmanın ayrı sorumlusu ve ayrı doğrulama ölçütü ortaya çıkar. Bir dizüstü bilgisayar uyanınca Wi-Fi simgesi doluysa ama yalnız kurum uygulaması çalışmıyorsa VPN oturumu veya uygulama zaman aşımı da incelenmelidir. Amaç kullanıcının yeniden başlatmasını alışkanlığa çevirmek değil, bağlantı zincirinde hangi adımın kaç saniyede başarısız olduğunu belgeleyerek o adımı onarmaktır.

• Uyanma anından itibaren SSID, BSSID, IP ve uygulama erişiminin zamanlarını ayrı kaydedin.
• AP'ye association isteği ulaşmıyorsa önce istemci radyo ve sürücüsünü, ulaşıyorsa ret nedenini inceleyin.
• Kurumsal ağda EAP/RADIUS kayıtları ile sertifika ve cihaz saatini kontrol edin; güvenliği gevşetmeyin.
• DHCP adresini uyku öncesi ve sonrası karşılaştırın; eski VLAN veya dolu havuzu ayırın.
• Çözümü kısa/uzun uyku ve farklı AP konumlarında birden fazla döngüyle sınayın.

Günlükleri bir olay zamanına bağlayın

İstemci, AP, DHCP ve RADIUS günlüklerinin saatleri uyuşmuyorsa ardışık görünen iki olayın aslında ilgisiz olması mümkündür. Önce saat eşitlemesini doğrulayın ve deneme başlangıcını saniye hassasiyetinde not edin. Kurumsal cihaz yönetimi yeni bir Wi-Fi profili dağıtıyorsa uyanma sırasında kayıtlı profil yeniden yazılabilir; olay sonrası SSID güvenlik türünü ve sertifika seçimini uykudan öncekiyle karşılaştırın. Aynı cihaz farklı kullanıcı hesabında sorunsuzsa kullanıcı profili veya sertifika deposu incelenir. Aynı kullanıcı farklı cihazda sorunsuzsa cihaz sürücüsü daha öne çıkar. Bu çapraz test, tüm AP'lerde agresif radyo değişikliklerine girişmeden önce küçük bir doğrulama maliyeti sağlar. Sorun Wi-Fi bağlantısı kurulurken değil, bağlantı kurulduktan hemen sonra ortaya çıkıyorsa DNS önbelleği ve VPN'in yeniden tünel oluşturması da gözlenmelidir. İşletim sistemi bağlantıyı ‘internet yok’ diye işaretlerken aslında kurum içi sunucu erişilebilir olabilir; denetim uç noktası engelleniyorsa simge yanıltıcıdır. Ağ geçidine, kurum içi DNS'e ve hedef uygulamaya ayrı test gönderin. Bazı işletim sistemleri uyku boyunca güç tasarrufu için ağı belirli aralıklarla uyandırır; bu davranışın AP kayıtlarında görünüp görünmediği incelenebilir. AP'nin istemciyi yaşlandırma süresi ile işletim sisteminin yeniden tarama döngüsü uyumsuzsa kısa ama tekrarlı gecikme yaşanır. Bu parametreleri varsayılan değerden uzaklaştırmadan önce üretici önerisi ve cihaz uyumluluğuna bakın. Son doğrulamada yalnız tek kullanıcının masa başı uyanmasını değil, toplantı salonundan ofise yürüyüp dizüstünü uyandırmasını da deneyin; böylece dolaşım ve uyku etkisi birbirinden ayrılabilir. Ağın başarılı görünmesine rağmen yalnız tek iş uygulaması toparlanmıyorsa uygulama ekibiyle zaman damgalı oturum kaydı paylaşın.