Okuma: ~3 dk
Karşılama Portalı Açılmıyor: Captive Portal Teşhisi
Captive portal'ın hiç açılmaması, çoğu zaman tek bir ayar hatasından değil, DNS yönlendirmesi, HTTPS/HSTS kısıtları ve işletim sistemlerinin farklı algılama mekanizmalarının üst üste binmesinden kaynaklanır. Bu yazı sorunu katman katman çözer.
- Teknik inceleme bekliyor
Captive portal aslında bir 'ağ yalanı'dır
Captive portal mekanizması teknik olarak bir yanıltmaya dayanır: istemci herhangi bir siteye erişmeye çalıştığında, ağ gerçek yanıtı vermek yerine kendi yönlendirme sayfasını döner. Bu, DNS seviyesinde (sorgulanan her alan adına portal IP'sini döndürme) veya HTTP seviyesinde (TCP bağlantısı kabul edilip 302 yönlendirmesi yapılma) gerçekleştirilebilir.
Bu yalanın çalışabilmesi için istemcinin ilk isteğinin düz HTTP (port 80) ve şifresiz olması gerekir. Günümüzde çoğu site ve işletim sistemi varsayılan olarak HTTPS kullandığından, portal'ın bu isteği yakalayabileceği pencere giderek daralmaktadır.
İşletim sistemleri bu kırılganlığı bildiği için artık kendi 'captive portal algılama' (CNA — Captive Network Assistant, veya Android'de NCSI benzeri) mekanizmalarını kullanır: bağlantı kurulur kurulmaz, bilinen ve sabit bir URL'ye düz HTTP isteği gönderilir. Beklenen yanıt (ör. sabit bir metin veya 204 No Content) gelmezse, cihaz 'bu ağda portal var' sonucuna varır ve kullanıcıya kontrollü bir mini tarayıcı penceresi açar.
- İşletim sistemi CNA isteğiApple/Google/Microsoft'un sabit algılama URL'si
- DNS yönlendirmesiPortal IP'sine çözümleme veya NXDOMAIN
- HTTP yakalama302 yönlendirme veya doğrudan portal içeriği
- Kullanıcı tarayıcısıManuel gezinme, HTTPS/HSTS siteleri
Dört katmandan biri bozulduğunda kullanıcı 'portal açılmıyor' der, ama neden farklıdır.
DNS yönlendirmesi doğru mu çalışıyor?
En temel arıza noktası, misafir DHCP kapsamının istemciye yanlış veya erişilemeyen bir DNS sunucusu dağıtmasıdır. İstemci DNS çözümlemesini hiç yapamazsa, ne gerçek siteye ne de portal'a ulaşır; tarayıcıda 'sunucuya ulaşılamıyor' hatası görülür ve bu, portal'ın hiç olmamasıyla karıştırılabilir.
İkinci nokta, DNS yönlendirmesinin tüm sorgulara mı yoksa yalnızca belirli bir listeye mi uygulandığıdır. Bazı sistemler (ör. walled garden yaklaşımı) yalnızca bilinen domain'leri serbest bırakır, geri kalan her sorguyu portal IP'sine yönlendirir. Walled garden listesi eksikse, işletim sisteminin CNA isteği attığı domain bu listede değilse, algılama hiç tetiklenmez ve kullanıcı internete çıktığını sanıp boş sayfalarla karşılaşır.
Saha teşhisinde en hızlı yöntem, misafir SSID'sine bağlı bir cihazdan `nslookup` ile rastgele bir domain sorgulamak ve dönen IP'nin gerçekten portal sunucusuna ait olup olmadığını doğrulamaktır. Portal IP'si yerine gerçek internet IP'si dönüyorsa, DNS yakalama hiç çalışmıyor demektir.
HTTPS ve HSTS: portal'ın en büyük düşmanı
Kullanıcının tarayıcısı zaten HTTPS'e zorlanmış bir site açmaya çalışıyorsa (ör. HSTS ön yükleme listesindeki google.com, bankalar, birçok büyük site), captive portal bu isteği şeffafça yönlendiremez. TLS el sıkışması, sunucunun kimliğini sertifika ile kanıtlamasını gerektirir; portal cihazı bu sertifikaya sahip olmadığından, tarayıcı ya bağlantıyı tamamen reddeder ya da güven hatası gösterir ve devam etmeye izin vermez.
Bu nedenle sağlıklı bir captive portal dağıtımı, kullanıcının ilk isteğini yakalamak için işletim sistemlerinin kendi algılama URL'lerine (plaintext, HSTS'siz) güvenir; kullanıcının kendi başlattığı HTTPS gezintisine değil. Yönetici tarafında yapılacak en kritik kontrol, portal çözümünün bu CNA domainlerini walled garden'da serbest bıraktığından ve bu isteklere doğru yanıtı verdiğinden emin olmaktır.
Bazı kurumlar, güvenlik sertleştirmesi (SSL inceleme, DNS filtreleme) uygularken farkında olmadan bu CNA domainlerini engeller. Sonuç: hem iOS hem Android cihazlar portal'ı hiç algılamaz, kullanıcı manuel olarak tarayıcı açıp bir HTTP sitesine gitmek zorunda kalır — ki bugün böyle bir site bulmak bile zorlaşmıştır.
- iOS/macOS: captive.apple.com ve ilgili domain'ler walled garden'da serbest olmalı.
- Android: connectivitycheck.gstatic.com ve msftconnecttest.com (Windows) benzer şekilde serbest bırakılmalı.
- SSL inceleme/filtreleme politikaları bu domainler için istisna içermeli.
İşletim sistemine göre davranış farkları
iOS ve Android portal algılamasında farklı toleranslara sahiptir. iOS, algılama isteğine beklenmeyen bir yanıt geldiğinde oldukça hassas davranır ve sıkça mini tarayıcıyı tekrar açar; bu bazen kullanıcıya 'portal sürekli açılıyor ama giriş kabul edilmiyor' şikayeti olarak yansır. Android ise bazı sürümlerde algılamayı arka planda bildirimle gösterir, kullanıcı bildirime dokunmazsa portal hiç görünmez ve internetsiz kalır.
Windows'ta NCSI (Network Connectivity Status Indicator) benzer bir rol oynar ve kendi sabit test adresine istek atar; bu adres engellenirse Windows ağı 'sınırlı' olarak işaretler ama portal penceresini otomatik açmayabilir, kullanıcı manuel olarak tarayıcı açmak zorunda kalır.