Chromecast/AirPlay Bulunamıyor: Ekran Yansıtma Sorunları

mDNS/Bonjour: ekran yansıtmanın temel keşif mekanizması

Chromecast, AirPlay, Google Home ve birçok IoT cihazı birbirini bulmak için mDNS (multicast DNS, Apple'da Bonjour olarak bilinir) protokolünü kullanır. Bu protokol merkezi bir DNS sunucusuna ihtiyaç duymadan, yerel ağ segmentinde 224.0.0.251 adresine multicast paket göndererek '_googlecast._tcp.local' veya '_airplay._tcp.local' gibi servis kayıtlarını anons eder. Telefon bu anonsu dinleyip cihazı listesinde gösterir.

mDNS'in çalışabilmesi için kritik ön koşul şudur: yayıncı cihaz (Chromecast) ile dinleyici cihaz (telefon) aynı Layer 2 broadcast domaininde, yani aynı VLAN ve aynı subnet içinde olmalıdır. Multicast trafiği, normal unicast IP trafiği gibi router'lar tarafından otomatik olarak yönlendirilmez; bir router arayüzü aksi yapılandırılmadıkça multicast paketleri bir VLAN'dan diğerine geçirmez.

Bu nedenle kurumsal ve ev ağlarında en sık görülen senaryo şudur: telefon ana Wi-Fi SSID'sine (örneğin VLAN 10), Chromecast ise misafir ağına veya IoT VLAN'ına (VLAN 30) bağlıdır. İkisi fiziksel olarak aynı binada, hatta aynı odada olsa bile, Layer 2'de ayrı oldukları için mDNS anonsu birbirine ulaşmaz ve cihaz 'bulunamıyor' olarak görünür.

İstemci izolasyonu: güvenlik özelliği, cast'in düşmanı

Çoğu kurumsal AP ve ev router'ı, misafir ağlarında 'client isolation' (istemci izolasyonu / AP izolasyonu) özelliğini varsayılan olarak açık tutar. Bu özellik, aynı SSID'ye bağlı istemcilerin birbirine erişmesini Layer 2 seviyesinde tamamen engeller — bir misafirin başka bir misafirin dizüstü bilgisayarına veya paylaşılan dosyalara erişmesini önlemek için tasarlanmıştır. Ancak bu koruma, aynı zamanda tüm cihazlar arası multicast/unicast keşif trafiğini de keser.

Sonuç olarak, telefon ve Chromecast'in aynı SSID ve aynı VLAN'da olduğu durumlarda bile istemci izolasyonu açıksa cast çalışmaz. Bu, kullanıcıların en çok kafa karıştıran senaryosudur çünkü 'aynı ağdayım ama göremiyorum' şikayeti doğrudan bu ayara işaret eder.

Kurumsal/misafir ortamlarında doğru yaklaşım, istemci izolasyonunu tamamen kapatmak değil, 'mDNS proxy' veya 'mDNS gateway' özelliği destekleyen bir çözümle sadece cast/print gibi servis anonslarına izin veren seçici bir izolasyon politikası uygulamaktır. RUCKUS, Aruba ve Cisco gibi üreticilerin kurumsal kontrolcüleri bu özelliği 'Bonjour Gateway' veya benzeri isimlerle sunar.

VLAN'lar arası keşif: mDNS reflector/proxy çözümleri

Ev kullanıcılarının aksine kurumsal ortamlarda (otel, ofis, okul) genellikle birden fazla VLAN vardır: personel, misafir, IoT, güvenlik kameraları gibi. Toplantı odasındaki Apple TV genelde ayrı bir 'sunum/AV' VLAN'ına, kullanıcıların telefonları ise kurumsal VLAN'a bağlıdır. Bu mimari güvenlik açısından doğru olsa da cast işlevselliğini doğası gereği bozar.

Çözüm olarak iki yaklaşım kullanılır: Birincisi mDNS reflector/repeater — bir yazılım (örn. Avahi, mdns-repeater) veya anahtar/kontrolcü üzerindeki yerleşik özellik, bir VLAN'da alınan mDNS anonsunu diğer belirlenen VLAN'lara kopyalar. İkincisi ise kurumsal kablosuz kontrolcülerin sunduğu merkezi Bonjour/mDNS Gateway özelliğidir; bu, kontrolcü üzerinde hangi servis türlerinin (AirPlay, Chromecast, AirPrint) hangi VLAN'lar arasında paylaşılacağını politika bazlı tanımlamaya izin verir.

Üçüncü ve daha basit bir yaklaşım, toplantı odaları ve ortak kullanım alanlarındaki cast cihazlarını ayrı bir VLAN'a koymak yerine kullanıcıların erişebileceği aynı VLAN'da, sadece erişim kontrol listeleri (ACL) ile internet erişimini kısıtlayarak tutmaktır. Güvenlik gereksinimi düşükse bu, en az karmaşıklığa sahip pratik çözümdür.

• mDNS reflector: VLAN'lar arası anons kopyalama yazılımı/özelliği
• Kurumsal Bonjour Gateway: politika bazlı servis paylaşımı (AirPlay, Chromecast, AirPrint)
• Basit alternatif: cast cihazlarını kullanıcı VLAN'ında tutup ACL ile internet erişimini kısıtlamak
• 5 GHz/2.4 GHz band farkı da bazen sorun gibi görünür; ancak mDNS IP seviyesinde çalıştığı için bandın kendisi doğrudan engel değildir

Diğer sık nedenler: multicast dönüşümü ve IGMP snooping

mDNS, Layer 2 multicast olarak üretilir ama Wi-Fi üzerinden iletilirken AP'ler çoğu zaman multicast trafiği unicast'e dönüştürüp her istemciye ayrı ayrı gönderir (multicast-to-unicast conversion). Bu, RF verimliliği için iyi bir uygulamadır çünkü multicast trafiği en düşük ortak veri hızında (genelde 1-6 Mbps) gönderilmek zorundadır ve havayı gereksiz yere işgal eder. Ancak bu dönüşüm düzgün yapılandırılmazsa, özellikle büyük istemci sayılarında anonsların bir kısmı gecikir veya kaybolur.

İkinci teknik etken IGMP snooping'dir. Switch'ler multicast trafiğinin hangi portlara gönderileceğini IGMP üyelik mesajlarını izleyerek öğrenir. Eğer IGMP snooping yanlış yapılandırılmışsa veya 'querier' (sorgulayıcı) cihaz ağda tanımlı değilse, switch multicast trafiğini ya tüm portlara taşırır (gereksiz yük) ya da hiç taşımaz (cast çalışmaz). Kurumsal switch'lerde IGMP snooping querier'ın doğru VLAN'da etkin olduğundan emin olunmalıdır.

Son olarak, bazı kurumsal güvenlik duvarları veya AP'ler 'rogue multicast' önleme amacıyla 5353 UDP portunu tamamen engelleyebilir. Sorun giderme sırasında ilgili VLAN'da bu portun açık olduğu paket yakalama (packet capture) ile doğrulanmalıdır.

F2 sahada nasıl çözüyor?

F2 mühendisleri cast sorunlarında önce ağ topolojisini çıkararak istemci ve cast cihazının hangi VLAN/SSID'de olduğunu doğrular, ardından Wireshark ile mDNS anonslarının gerçekten ağda dolaşıp dolaşmadığını kontrol eder. RUCKUS ve Aruba altyapılarında yerleşik Bonjour Gateway özelliği etkinleştirilerek VLAN'lar arası seçici servis paylaşımı sağlanır; bu sayede güvenlik mimarisi bozulmadan ekran yansıtma sorunsuz çalışır hale getirilir.