VPN ilə yayım dayanır: kəşf, idarəetmə, yoxsa axın?

Yayım divandan eyni görünən üç yerdə pozulur. Telefon qəbuledicini heç görməyə bilər, qəbuledici görünüb sonra sessiyanı rədd edə bilər, ya da sessiya başlayıb bir dəqiqə sonra ilişib qala bilər. Telefondakı tunel bu yolların hər birini fərqli şəkildə dəyişir və onlardan biri üçün heç nəyi dəyişmir. Əvvəlcə uğursuz mərhələni adlandırın, sonra siyasət dəyişikliyinin ümumiyyətlə düzgün qol olub-olmadığına qərar verin.

Siyasəti dəyişməzdən əvvəl uğursuz mərhələni adlandırın

Yayım nişanına toxunduqdan dərhal sonra telefonun nə etdiyinə baxın. Boş siyahı kəşf nəticəsidir, uğursuzluq bildirən toxunuş idarəetmə nəticəsidir, ilişməzdən əvvəl başlayan sessiya isə axın nəticəsidir. Bu üçünün sahibləri fərqlidir və adətən yalnız ilk ikisi telefonun tunel ayarlarına aiddir.

Nəyisə dəyişməzdən əvvəl mərhələni yazın. Yanlış mərhələyə tətbiq edilən düzəliş növbəti testi oxunmaz edir və yayımla bağlı əksər şayiələr məhz bu qarışıqlıqdan yaranır.

Kəşf yerli trafikdir və tunel onu gizlədir

Qəbuledicilər özlərini yerli elanlarla tanıdır və telefon onları eyni keçiddə sorğularla tapır, ona görə telefonu o keçiddən çıxaran hər şey qəbuledicini də siyahıdan çıxarır. Bütün trafiki LAN-dan yayındıran tunel bu mübadilələri gizlədə bilər və tətbiq səviyyəsində yerli şəbəkə icazəsi marşrut mövcud olsa da onları bloklaya bilər. Müştəri izolyasiyalı qonaq Wi-Fi heç bir VPN iştirak etmədən eyni boş siyahını yaradır. Tuneli günahlandırmazdan əvvəl iki cihazın eyni seqmenti paylaşdığını sübut edin.

avahi-browse -at | grep -i -E 'chromecast|googlecast'
dig +short @224.0.0.251 -p 5353 _googlecast._tcp.local PTR

Birinci əmr köməkçi maşının seqmentində özünü elan edənləri sadalayır, ikincisi isə multicast DNS qrupundan birbaşa soruşur. Hər ikisində olmayan qəbuledici telefon tətbiqində də görünməyəcək, telefonun tunel vəziyyətindən asılı olmayaraq. Əgər qəbuledici tuneli söndürülmüş cihazdan görünür, tuneli yandırılmış cihazdan isə görünmürsə, mərhələni və səbəbi birlikdə tapmısınız.

LAN istisnası tuneli işlək saxlayır

Bir çox müştəri tuneli aktiv saxlayaraq yerli ünvanlara icazə verən yerli şəbəkə istisnası təklif edir. Kill switch-i və ya bütün firewall-u söndürmək əvəzinə bu sənədləşdirilmiş ayardan istifadə edin, çünki onlar yayımın ehtiyac duyduğundan qat-qat çoxunu dəyişir. Əgər şəbəkə ağıllı cihazları qəsdən ayırırsa, düz giriş istəmək əvəzinə sahibindən konkret kəşf, idarəetmə və qayıdış trafikini istəyin.

nc -vz 192.168.1.50 8009

Qəbulediciyə qarşı idarəetmə testi icazəni əlçatanlıqdan ayırır: cavab verən port yolun mövcud olduğunu bildirir, rədd isə telefonun cihazı kəşf etməsinə icazə verildiyini, amma onunla danışa bilmədiyini göstərir. 8008 və 8009 portları adi yayım portlarıdır və tətbiq başqalarını da işlədə bilər, ona görə bir rədd edilmiş portu hökm deyil, işarə kimi qəbul edin. İstisna ilə tətbiq icazəsi bir-birindən asılı deyil, çünki yerli giriş vermək marşrut yaratmır, marşrut əlavə etmək isə icazə vermir. Kill switch yenidən qoşulmadan sonra yerli trafiki də ata bilər, buna görə tunel qayıdan kimi kəşf yenidən yoxlanmalıdır.

Axın telefonun bağlantısından istifadə etməyə bilər

Tətbiqin idarə etdiyi sessiyada telefon qəbulediciyə media ünvanı verir və qəbuledici onu öz bağlantısı ilə yükləyir, ona görə telefonun ictimai ünvanını dəyişmək axın üçün heç nə etmir. Hesabla məhdudlaşdırılmış başlıq öz səbəblərindən yenə də uğursuz ola bilər və Google-un yayım tələbləri şəbəkə yolu deyil, tətbiq və cihaz uyğunluğunu əhatə edir. Televizorun özünü tuneldən keçirmək ayrı konfiqurasiyadır və öz siyasət sualları var.

İki ipucu rejimləri ayırır. Telefonun ekranı kilidlənəndə davam edən yayım tətbiq yönümlüdür, çünki qəbuledici özü yükləyir; göndərənin ekranı kilidlənəndə dayanan güzgü isə telefondan gələn davamlı axındır. Kəşf və idarəetmə uğurlu olub axın ilişəndə isə telefonun sürət testi televizoru deyil, telefonu təsvir etdiyi üçün qəbuledicinin Wi-Fi keçidinə və internet yoluna baxın.

İstisnanı geri qaytarın və yenidən yoxlayın

Hər müvəqqəti dəyişikliyin geri qayıtma yolu olmalıdır və sıra vacibdir. LAN istisnasını silin, müştəri siyasətini yenidən tətbiq etsin deyə tuneli yenidən qoşun, sonra kəşf addımını təkrarlayın və qəbuledicinin yenidən yoxa çıxıb-çıxmadığını qeyd edin. Bu ardıcıllıq işi istisnanın görüb-görmədiyini, yoxsa arada başqa nəyinsə dəyişdiyini göstərir.

# 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 üç mərhələni ayrı-ayrılıqda yoxlayın, çünki birinin keçməsi digərləri haqqında heç nə demir. Sonra əlaqəsiz telefon tətbiqlərinin hələ də nəzərdə tutulan marşruta getdiyini yoxlayın, çünki səssizcə tam yan keçidə çevrilən yerli istisna bir əlavə toxunuş tələb edən yayımdan daha pis nəticədir.