VPN üzerinden yayın: keşif, denetim veya akış?
Eksik bir alıcı, reddedilen bir oturum ve takılan bir akış farklı yerlerde başarısız olur. Telefonun VPN ilkesini veya ağı değiştirmeden önce aşamayı adlandırın.
Yayın, kanepeden aynı görünen üç yerde bozulur. Telefon alıcıyı hiç görmeyebilir, alıcı görünüp oturumu reddedebilir veya oturum başlayıp bir dakika sonra takılabilir. Telefondaki tünel bu yolların her birini farklı değiştirir ve biri için hiçbir şeyi değiştirmez. Önce başarısız olan aşamayı adlandırın, sonra ilke değişikliğinin doğru kol olup olmadığına karar verin.
İlkeyi değiştirmeden önce başarısız aşamayı adlandırın
Yayın simgesine dokunduktan hemen sonra telefonun ne yaptığını izleyin. Boş liste bir keşif sonucudur, hata bildiren bir dokunuş denetim sonucudur ve takılmadan önce başlayan oturum bir oynatma sonucudur. Bu üçünün sahipleri farklıdır ve genellikle yalnızca ilk ikisi telefonun tünel ayarlarıyla ilgilidir.
| Stage | What the phone shows | Evidence that separates it |
|---|---|---|
| Discovery | No receiver in the list | Another device on the same segment sees the receiver |
| Control | Receiver listed, session refused | Port answer versus permission prompt |
| Playback | Session starts, then stalls | The receiver's own link, not the phone's |
Bir şeyi değiştirmeden önce aşamayı yazın. Yanlış aşamaya uygulanan düzeltme bir sonraki testi okunamaz hale getirir ve yayınla ilgili hikâyelerin çoğu tam olarak bu karışıklıktan çıkar.
Keşif yerel trafiktir ve tünel onu gizler
Alıcılar kendilerini yerel duyurularla tanıtır ve telefon onları aynı bağlantıdaki sorgularla bulur, bu yüzden telefonu o bağlantıdan çıkaran her şey alıcıyı listeden çıkarır. Tüm trafiği LAN dışına yönlendiren bir tünel bu alışverişleri gizleyebilir ve uygulama düzeyindeki yerel ağ izni rota var olsa bile bunları engelleyebilir. İstemci yalıtımı olan konuk Wi-Fi, hiç VPN olmadan aynı boş listeyi verir. Tüneli suçlamadan önce iki cihazın aynı segmenti paylaştığını kanıtlayın.
avahi-browse -at | grep -i -E 'chromecast|googlecast'
dig +short @224.0.0.251 -p 5353 _googlecast._tcp.local PTRİlk komut yardımcı makinenin segmentinde neyin kendini duyurduğunu listeler, ikincisi çoklu yayın DNS grubuna doğrudan sorar. İkisinde de olmayan bir alıcı, telefonun tünel durumu ne olursa olsun telefon uygulamasında da görünmez. Alıcı tüneli kapalı bir cihazdan görünüyor ve tüneli açık bir cihazdan görünmüyorsa, aşamayı ve nedeni birlikte bulmuşsunuz demektir.
LAN istisnası tüneli açık tutar
Birçok istemci, yerel adreslere izin verirken tüneli etkin bırakan bir yerel ağ istisnası sunar. Kill switch'i veya tüm güvenlik duvarını kapatmak yerine bu belgelenmiş ayarı kullanın, çünkü onlar yayının ihtiyacından çok daha fazlasını değiştirir. Ağ akıllı cihazları bilerek ayırıyorsa, sahibinden düz erişim yerine belirli keşif, denetim ve dönüş trafiğini isteyin.
nc -vz 192.168.1.50 8009Alıcıya doğru bir denetim testi izin ile erişilebilirliği ayırır: yanıt veren bir bağlantı noktası yolun var olduğunu gösterir, reddetme ise telefona cihazı keşfetme izni verildiğini ve yine de onunla konuşamadığını gösterir. 8008 ve 8009 olağan yayın bağlantı noktalarıdır ve bir uygulama başkalarını kullanabilir, bu yüzden reddedilen tek bir bağlantı noktasını hüküm değil ipucu olarak görün. İstisna ile uygulama izni bağımsız kalır, çünkü yerel erişim vermek rota oluşturmaz ve rota eklemek izin vermez. Kill switch yeniden bağlandıktan sonra yerel trafiği de düşürebilir, bu yüzden tünel geri geldiğinde keşif yeniden test edilmelidir.
Oynatma telefonun bağlantısını kullanmayabilir
Uygulamanın yönlendirdiği bir oturumda telefon alıcıya bir medya adresi verir ve alıcı onu kendi bağlantısı üzerinden alır, bu yüzden telefonun genel adresini değiştirmek akışa hiçbir şey yapmaz. Hesapla sınırlanan bir başlık kendi nedenleriyle yine de başarısız olabilir ve Google'ın yayın gereklilikleri ağ yolunu değil uygulama ve cihaz uyumluluğunu kapsar. Televizyonun kendisini bir tünelden geçirmek, kendi ilke soruları olan ayrı bir yapılandırmadır.
İki ipucu kipleri ayırır. Telefonun ekranı kilitlendikten sonra da süren bir yayın uygulama yönlendirmelidir, çünkü alıcı kendi başına alır; gönderenin ekranı kilitlenince duran bir yansıtma telefondan gelen sürekli bir akıştır. Keşif ve denetim başarılı ama oynatma takılıyorsa, bunun yerine alıcının Wi-Fi bağlantısına ve internet yoluna bakın, çünkü telefondaki hız testi telefonu tanımlar, televizyonu değil.
İstisnayı geri alın ve yeniden test edin
Her geçici değişikliğin bir dönüş yolu olmalı ve sıra önemlidir. LAN istisnasını kaldırın, istemcinin ilkesini yeniden uygulaması için tüneli yeniden bağlayın, sonra keşif adımını yineleyin ve alıcının yeniden kaybolup kaybolmadığını not edin. Bu sıra, işi istisnanın mı yaptığını yoksa arada başka bir şeyin mi değiştiğini söyler.
# after removing the LAN exception, reconnect and confirm the tunnel is up
resolvectl status | grep -E 'DNS Servers|Default Route|Protocols'
avahi-browse -at | grep -i -E 'chromecast|googlecast'Sonra üç aşamayı ayrı ayrı doğrulayın, çünkü birinin geçmesi diğerleri hakkında hiçbir şey söylemez. Ardından ilgisiz telefon uygulamalarının hâlâ amaçlanan rotayı izleyip izlemediğini kontrol edin, çünkü sessizce tam bir atlatmaya dönüşen yerel bir istisna, bir fazladan dokunuş gerektiren yayından daha kötü bir sonuçtur.