Misafir Ağına Giremiyorum: Portal, İzolasyon ve Sınırlar

Misafirin gördüğü ekran, sizin gördüğünüz log değildir

Bir misafir 'ağa bağlanamıyorum' dediğinde aslında üç farklı aşamadan birinde takılmış olabilir: SSID'ye ilişkilendirme, IP/DNS alma, veya captive portal'dan geçiş. Bu üç aşama tamamen farklı katmanlarda çalışır ve farklı loglara düşer. Yönetici genelde yalnızca AP/controller tarafındaki ilişkilendirme logunu görür; misafirin telefonunda portal'ın hiç açılmadığını göremez.

Saha pratiğinde en verimli yöntem, şikayeti aldığınız anda misafirin cihazında üç şeyi birlikte kontrol etmektir: SSID'ye bağlı mı, IP adresi almış mı, ve tarayıcı herhangi bir siteye yönlendirildiğinde portal sayfası geliyor mu. Bu üçünden hangisinde durduğu kök nedeni doğrudan işaret eder.

Çoğu kurumsal ortamda misafir SSID'si açık veya PSK ile korunur ve gerçek kimlik doğrulama captive portal üzerinden yapılır. Bu mimaride ilişkilendirme neredeyse her zaman başarılıdır; sorun genelde DHCP veya portal yönlendirmesinde yaşanır. Bu yüzden 'bağlanamıyorum' şikayetini 'ilişkilendirme sorunu' olarak okumak teşhisi yanlış yöne sürükler.

Portal açılmadığında sırayla kontrol edilecekler

Portal açılmama sorunlarının kökeninde çoğunlukla DNS yönlendirmesi vardır. Captive portal, istemcinin herhangi bir alan adına yaptığı DNS sorgusunu veya HTTP isteğini yakalayıp kendi sayfasına yönlendirir. Ancak işletim sistemleri artık bu yakalamayı kendi 'captive portal algılama' mekanizmalarıyla test eder: iOS/macOS belirli bir Apple URL'sine, Android belirli bir Google URL'sine istek atar; beklenen yanıt gelmezse cihaz portal olduğunu anlar ve mini tarayıcı açar.

Bu mekanizmanın kırıldığı en yaygın nokta HTTPS ve HSTS'tir. Modern tarayıcılar birçok siteyi HSTS listesinde tutar; bu sitelere HTTP üzerinden erişim denemesi otomatik olarak HTTPS'e yükseltilir. Captive portal ise genelde yalnızca HTTP (port 80) trafiğini şeffafça yönlendirebilir — başlamış bir TLS el sıkışmasını yönlendiremez, bunun yerine sertifika hatası veya bağlantı reddi ile sonuçlanır.

İkinci yaygın neden, işletim sistemlerinin captive portal algılama isteklerinin ağ tarafından engellenmesidir. Kurumsal güvenlik politikaları bazen bilinmeyen dış domainlere giden DNS sorgularını kısıtlar; bu durumda algılama isteği yanıt almaz ve cihaz bazen portalın olmadığını varsayıp sessizce internetsiz kalır, bazen de sonsuz döngüde portal sayfasını tekrar açar.

Süre ve kota sınırları: 'az önce bağlandım' problemi

Misafir portallarının çoğunda oturum süresi (ör. 2 saat, 24 saat) ve bazen veri kotası tanımlıdır. Bu sınırlar dolduğunda kullanıcı aniden internetten düşer ama SSID'ye bağlı kalmaya devam edebilir — çünkü süre kısıtı Wi-Fi katmanında değil, portal/RADIUS oturum katmanında uygulanır. Kullanıcı bunu 'Wi-Fi koptu' olarak algılar, oysa aslında portala tekrar giriş gerekir.

Süre sınırının sıfırlanma mantığı da kafa karıştırıcıdır: bazı sistemlerde süre MAC adresine, bazılarında telefon numarasına, bazılarında yalnızca IP'ye bağlı tutulur. MAC rastgeleleştirme açık bir cihaz her yeniden bağlanışta farklı MAC gösterebilir; bu da süre sınırını MAC bazlı uygulayan sistemlerde beklenmedik biçimde sürekli yeni oturum açılmasına ya da tam tersine meşru kullanıcının engellenmesine yol açabilir.

Kota bazlı sınırlamalarda sorun genelde görünürlük eksikliğidir: kullanıcıya kalan kotası gösterilmez, kota bittiğinde net bir mesaj yerine sessiz yavaşlama veya tam kesinti yaşanır. Kota ve süre sınırlarının kullanıcıya açıkça gösterildiği portallarda şikayet hacmi belirgin biçimde düşer.

İzolasyonun görünmeyen yan etkileri

Misafir ağlarında istemci izolasyonu güvenlik gereği neredeyse zorunludur: bir misafir cihazının aynı SSID'deki diğer cihazları göremeyip yalnızca internete çıkabilmesi istenir. Ancak bu izolasyon bazı protokolleri de kırar: AirPlay, Chromecast, ağ içi yazıcı keşfi gibi mDNS/Bonjour tabanlı özellikler izolasyon açıkken çalışmaz.

Otel ve toplantı salonu gibi ortamlarda bu durum doğrudan şikayete dönüşür: misafir kendi telefonundan toplantı odasındaki ekrana yayın yapmaya çalışır, izolasyon nedeniyle cihazlar birbirini göremez. Çözüm genelde tam izolasyonu kaldırmak değil, mDNS reflector/proxy gibi seçici mekanizmalarla yalnızca gerekli keşif trafiğine izin vermektir.

İzolasyonun bir diğer yan etkisi, aynı ağdaki iki misafir cihazının (telefon ve dizüstü bilgisayar) dosya paylaşımı için birbirini bulamamasıdır. Bu tasarım gereği beklenen bir davranıştır; kullanıcıya önceden bilgi verilmesi şikayetleri azaltır.

• İzolasyon açıkken AirPlay/Chromecast çalışmaz — mDNS reflector ile seçici izin tanımlanmalı.
• Yazıcı erişimi gerekiyorsa misafir subneti için ayrı, kısıtlı bir ACL istisnası tanımlanmalı.
• Portal sayfasında izolasyon ve sınırlar hakkında kısa bir not, şikayet hacmini düşürür.

F2'nin saha yaklaşımı

F2 mühendisleri misafir ağı şikayetlerinde önce üç aşamalı teşhis matrisini (ilişkilendirme / DHCP-DNS / portal) uygular, ardından RADIUS ve portal loglarını gerçek zamanlı paket yakalamayla eşleştirir. Böylece 'Wi-Fi bozuk' algısının aslında portal'ın HSTS nedeniyle tetiklenmemesinden mi, yoksa MAC rastgeleleştirmenin süre sınırını bozmasından mı kaynaklandığı net biçimde ayrıştırılır ve kalıcı, ölçülebilir bir düzeltme uygulanır.