VPN orqali kasting: aniqlash, boshqarish yoki oqim?

Kasting divandan bir xil ko‘rinadigan uch joyda buziladi. Telefon qabul qilgichni hech qachon ko‘rmasligi mumkin, qabul qilgich paydo bo‘lib keyin sessiyani rad etishi mumkin, yoki sessiya boshlanib bir daqiqadan so‘ng tiqilib qolishi mumkin. Telefondagi tunnel bu yo‘llarning har birini boshqacha o‘zgartiradi, birortasi uchun esa hech narsani o‘zgartirmaydi. Avval muvaffaqiyatsiz bosqichni nomlang, keyin siyosatni o‘zgartirish to‘g‘ri dastak ekanini hal qiling.

Siyosatni o‘zgartirishdan oldin muvaffaqiyatsiz bosqichni nomlang

Kasting belgisini bosgandan so‘ng telefon nima qilishini kuzating. Bo‘sh ro‘yxat aniqlash natijasi, xatoni ko‘rsatuvchi bosish boshqarish natijasi, tiqilishdan oldin boshlanadigan sessiya esa ijro natijasidir. Bu uchtasining egalari boshqa, va odatda faqat birinchi ikkitasi telefon tunnel sozlamalariga tegishli.

Nimadirni o‘zgartirishdan oldin bosqichni yozib qo‘ying. Noto‘g‘ri bosqichga qo‘llangan tuzatish keyingi sinovni o‘qib bo‘lmaydigan qiladi, kasting haqidagi hikoyalarning ko‘pchiligi aynan shu chalkashlikdan chiqadi.

Aniqlash — bu mahalliy trafik, tunnel uni yashiradi

Qabul qilgichlar o‘zini mahalliy e’lonlar orqali reklama qiladi, telefon esa ularni shu tarmoqdagi so‘rovlar bilan topadi, shuning uchun telefonni bu tarmoqdan olib tashlaydigan har qanday narsa qabul qilgichni ro‘yxatdan olib tashlaydi. Butun trafikni LAN tashqarisiga yo‘naltiruvchi tunnel bu almashinuvlarni yashirishi mumkin, ilova darajasidagi mahalliy tarmoq ruxsati esa yo‘l mavjud bo‘lsa ham ularni to‘sishi mumkin. Mijozlarni ajratish bilan mehmon Wi-Fi hech qanday VPNsiz xuddi shunday bo‘sh ro‘yxat beradi. Tunnelni ayblashdan oldin ikkala qurilma bir segmentni bo‘lishishini isbotlang.

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

Birinchi buyruq yordamchi mashina segmentida nima o‘zini e’lon qilayotganini sanaydi, ikkinchisi multicast DNS guruhidan to‘g‘ridan-to‘g‘ri so‘raydi. Ikkalasida ham bo‘lmagan qabul qilgich telefon ilovasida ham ko‘rinmaydi, telefon tunnel holati qanday bo‘lishidan qat’i nazar. Qabul qilgich tunneli o‘chirilgan qurilmadan ko‘rinib, yoqilgan qurilmadan ko‘rinmasa, siz bosqichni ham, sababni ham birga topdingiz.

LAN istisnosi tunnelni yoqilgan holda saqlaydi

Ko‘p mijozlar mahalliy manzillarga ruxsat berib, tunnelni faol qoldiradigan mahalliy tarmoq istisnosini taklif qiladi. Kill switch yoki butun firewallni o‘chirish o‘rniga o‘sha hujjatlashtirilgan sozlamadan foydalaning, chunki ular kastingga kerak bo‘lganidan ancha ko‘proq narsani o‘zgartiradi. Agar tarmoq aqlli qurilmalarni ataylab ajratsa, tekis kirish o‘rniga egasidan aniq aniqlash, boshqarish va qaytish trafigini so‘rang.

nc -vz 192.168.1.50 8009

Qabul qilgichga qaratilgan boshqaruv sinovi ruxsatni yetib borishdan ajratadi: javob beradigan port yo‘l borligini bildiradi, rad etish esa telefonga qurilmani aniqlashga ruxsat berilganini va u bilan baribir gaplasha olmasligini bildiradi. 8008 va 8009 odatiy kasting portlari, ilova boshqalarini ishlatishi mumkin, shuning uchun bitta rad etilgan portni hukm emas, ishora deb biling. Istisno va ilova ruxsati mustaqil qoladi, chunki mahalliy kirish yo‘l yaratmaydi, yo‘l qo‘shish esa ruxsat bermaydi. Kill switch qayta ulangandan so‘ng mahalliy trafikni ham tashlab yuborishi mumkin, shuning uchun tunnel qaytgach aniqlashni yana sinash kerak.

Ijro telefonning ulanishidan foydalanmasligi mumkin

Ilova boshqaradigan sessiyada telefon qabul qilgichga media manzil beradi va qabul qilgich uni o‘z ulanishi orqali oladi, shuning uchun telefonning umumiy manzilini o‘zgartirish oqimga hech narsa qilmaydi. Hisob bilan cheklangan sarlavha o‘z sabablariga ko‘ra baribir muvaffaqiyatsiz bo‘lishi mumkin, va Google kasting talablari tarmoq yo‘lini emas, ilova va qurilma mosligini qamrab oladi. Televizorning o‘zini tunnel orqali o‘tkazish o‘z siyosat savollariga ega alohida konfiguratsiya.

Ikki belgi rejimlarni ajratadi. Telefon ekrani qulflangandan keyin ham davom etadigan kasting ilova boshqaruvida bo‘ladi, chunki qabul qilgich o‘zi oladi; yuboruvchining ekrani qulflanganda to‘xtaydigan ko‘zgu telefondan keladigan uzluksiz oqimdir. Aniqlash va boshqarish muvaffaqiyatli bo‘lib, ijro tiqilib qolsa, buning o‘rniga qabul qilgichning Wi-Fi aloqasi va uning internet yo‘lini ko‘ring, chunki telefondagi tezlik sinovi telefonni tasvirlaydi, televizorni emas.

Istisnoni bekor qiling va qayta sinang

Har bir vaqtinchalik o‘zgarish orqaga yo‘l talab qiladi, tartib esa muhim. LAN istisnosini olib tashlang, mijoz siyosatini qayta qo‘llashi uchun tunnelni qayta ulang, keyin aniqlash qadamini takrorlang va qabul qilgich yana yo‘qoladimi-yo‘qmi yozib qo‘ying. Bu ketma-ketlik ishni istisno qilganini yoki orada boshqa narsa o‘zgarganini aytadi.

# 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'

Keyin uch bosqichni alohida tekshiring, chunki birining muvaffaqiyati qolganlari haqida hech narsa demaydi. So‘ng aloqasiz telefon ilovalari hali ham mo‘ljallangan yo‘lda ketayotganini tekshiring, chunki jimgina to‘liq chetlanishga aylangan mahalliy istisno bitta qo‘shimcha bosish talab qiladigan kastingdan yomonroq natija.