VPN પર કાસ્ટિંગ અટકે છે: શોધ, નિયંત્રણ કે સ્ટ્રીમ?
ગુમ થયેલું રીસીવર, નકારેલું સત્ર અને અટકતો સ્ટ્રીમ અલગ અલગ જગ્યાએ નિષ્ફળ જાય છે. ફોનની VPN નીતિ કે નેટવર્ક બદલતા પહેલાં તબક્કો ઓળખો.
કાસ્ટિંગ ત્રણ જગ્યાએ તૂટે છે, જે સોફા પરથી એકસરખી લાગે છે. કદાચ ફોન રીસીવરને કદી જોશે નહીં, રીસીવર દેખાય અને પછી સત્ર નકારી કાઢે, અથવા સત્ર શરૂ થાય અને એક મિનિટ પછી અટકી જાય. ફોન પરનો ટનલ આ દરેક માર્ગને જુદી રીતે બદલે છે, અને એક માટે તે કંઈ જ બદલતો નથી. પહેલાં નિષ્ફળ તબક્કાને નામ આપો, પછી નક્કી કરો કે નીતિ બદલવી ખરેખર યોગ્ય લિવર છે કે નહીં.
નીતિ બદલતા પહેલાં નિષ્ફળ તબક્કાને નામ આપો
કાસ્ટ આઇકન દબાવ્યા પછી તરત જ ફોન શું કરે છે તે જુઓ. ખાલી યાદી શોધનું પરિણામ છે, નિષ્ફળતા જણાવતું ટેપ નિયંત્રણનું પરિણામ છે, અને અટકતા પહેલાં શરૂ થતું સત્ર પ્લેબેકનું પરિણામ છે. આ ત્રણના માલિક અલગ છે, અને સામાન્ય રીતે ફક્ત પહેલા બે જ ફોનના ટનલ સેટિંગ્સ સાથે સંબંધિત છે.
| 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 |
કંઈપણ બદલતા પહેલાં તબક્કો લખી લો. ખોટા તબક્કા પર લાગુ કરેલો સુધારો આગળની કસોટીને વાંચી ન શકાય તેવી બનાવે છે, અને કાસ્ટિંગ વિશેની મોટાભાગની દંતકથા એ જ ગૂંચવણમાંથી આવે છે.
શોધ સ્થાનિક ટ્રાફિક છે, અને ટનલ તેને છુપાવે છે
રીસીવરો સ્થાનિક જાહેરાતો દ્વારા પોતાની જાહેરાત કરે છે અને ફોન તેમને એ જ લિંક પરની પૂછપરછથી શોધે છે, તેથી જે પણ ફોનને એ લિંક પરથી દૂર કરે છે તે રીસીવરને યાદીમાંથી દૂર કરે છે. જે ટનલ બધો ટ્રાફિક LAN થી દૂર લઈ જાય છે તે આ વિનિમયને છુપાવી શકે છે, અને એપ સ્તરની સ્થાનિક-નેટવર્ક પરવાનગી રસ્તો હોવા છતાં તેમને અવરોધી શકે છે. ક્લાયન્ટ આઇસોલેશન સાથેનું મહેમાન Wi-Fi કોઈપણ VPN વિના એ જ ખાલી યાદી બનાવે છે. ટનલને દોષ આપતા પહેલાં સાબિત કરો કે બંને ઉપકરણો એક જ સેગમેન્ટ વહેંચે છે.
avahi-browse -at | grep -i -E 'chromecast|googlecast'
dig +short @224.0.0.251 -p 5353 _googlecast._tcp.local PTRપહેલો આદેશ સહાયક મશીનના સેગમેન્ટમાં શું જાહેર થાય છે તેની યાદી આપે છે, અને બીજો મલ્ટિકાસ્ટ DNS જૂથને સીધો પૂછે છે. બંનેમાં ન હોય તેવું રીસીવર ફોનની એપમાં પણ દેખાશે નહીં, ફોનના ટનલની સ્થિતિ ગમે તે હોય. જો રીસીવર ટનલ બંધ હોય તેવા ઉપકરણથી દેખાય અને ટનલ ચાલુ હોય તેવા ઉપકરણથી ન દેખાય, તો તમે તબક્કો અને કારણ સાથે શોધી કાઢ્યાં છે.
LAN અપવાદ ટનલ ચાલુ રાખે છે
ઘણા ક્લાયન્ટ સ્થાનિક-નેટવર્ક અપવાદ આપે છે જે સ્થાનિક સરનામાંને મંજૂરી આપતાં ટનલ સક્રિય રાખે છે. કિલ સ્વિચ કે આખું ફાયરવોલ બંધ કરવાને બદલે એ દસ્તાવેજી સેટિંગ વાપરો, કારણ કે તે કાસ્ટિંગને જરૂરી હોય તેના કરતાં ઘણું વધારે બદલે છે. જો નેટવર્ક જાણી જોઈને સ્માર્ટ ઉપકરણોને અલગ પાડે છે, તો સપાટ ઍક્સેસને બદલે માલિકને ચોક્કસ શોધ, નિયંત્રણ અને પરત ટ્રાફિક માટે પૂછો.
nc -vz 192.168.1.50 8009રીસીવર સામેની નિયંત્રણ કસોટી પરવાનગીને પહોંચથી અલગ પાડે છે: જવાબ આપતો પોર્ટ એટલે રસ્તો છે, જ્યારે નકાર એટલે ફોનને ઉપકરણ શોધવાની પરવાનગી હતી અને તેમ છતાં તેની સાથે વાત કરી શકતો નથી. 8008 અને 8009 પોર્ટ સામાન્ય કાસ્ટ પોર્ટ છે, અને એપ બીજા પોર્ટ વાપરી શકે છે, તેથી એક નકારેલા પોર્ટને ચુકાદા નહીં, સંકેત ગણો. અપવાદ અને એપ પરવાનગી સ્વતંત્ર રહે છે, કારણ કે સ્થાનિક ઍક્સેસ રસ્તો બનાવતું નથી અને રસ્તો ઉમેરવો પરવાનગી આપતો નથી. કિલ સ્વિચ ફરી જોડાયા પછી સ્થાનિક ટ્રાફિક પણ પાડી શકે છે, તેથી ટનલ પાછો આવે કે તરત શોધ ફરી ચકાસવી પડે છે.
પ્લેબેક ફોનના જોડાણનો ઉપયોગ ન પણ કરે
એપ-નિર્દેશિત સત્રમાં ફોન રીસીવરને મીડિયા સરનામું આપે છે અને રીસીવર તેને પોતાના જોડાણ પરથી મેળવે છે, તેથી ફોનનું જાહેર સરનામું બદલવાથી સ્ટ્રીમ માટે કંઈ થતું નથી. ખાતા-મર્યાદિત શીર્ષક પોતાના કારણોસર હજી નિષ્ફળ થઈ શકે છે, અને Google ની કાસ્ટિંગની જરૂરિયાતો એપ અને ઉપકરણની સુસંગતતા આવરે છે, નેટવર્ક માર્ગ નહીં. ટેલિવિઝનને જ ટનલમાંથી પસાર કરાવવું એ અલગ ગોઠવણી છે, જેની પોતાની નીતિ-પ્રશ્નો છે.
બે સંકેત આ મોડને અલગ પાડે છે. ફોનની સ્ક્રીન લૉક કરવા છતાં ટકી રહેતું કાસ્ટ એપ-નિર્દેશિત છે, કારણ કે રીસીવર પોતે મેળવે છે; મોકલનારની સ્ક્રીન લૉક થતાં અટકતું મિરર ફોન તરફથી સતત સ્ટ્રીમ છે. જ્યારે શોધ અને નિયંત્રણ સફળ થાય પણ પ્લેબેક અટકે, ત્યારે તેના બદલે રીસીવરની Wi-Fi લિંક અને તેનો ઇન્ટરનેટ માર્ગ જુઓ, કારણ કે ફોન પરની સ્પીડ ટેસ્ટ ફોનનું વર્ણન કરે છે, ટેલિવિઝનનું નહીં.
અપવાદ રદ કરો અને ફરી ચકાસો
દરેક કામચલાઉ ફેરફારને પાછા ફરવાનો માર્ગ જોઈએ, અને ક્રમ મહત્વનો છે. LAN અપવાદ દૂર કરો, ટનલ ફરી જોડો જેથી ક્લાયન્ટ પોતાની નીતિ ફરી લાગુ કરે, પછી શોધનું પગલું પુનરાવર્તિત કરો અને નોંધો કે રીસીવર ફરી અદૃશ્ય થાય છે કે નહીં. એ ક્રમ તમને કહે છે કે કામ અપવાદ કરતો હતો કે વચ્ચે બીજું કંઈ બદલાયું.
# 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'પછી ત્રણેય તબક્કા અલગ અલગ ચકાસો, કારણ કે એકમાં પાસ થવાથી બીજા વિશે કંઈ કહેવાય નહીં. પછી તપાસો કે ફોનની અસંબંધિત એપ હજી ઇચ્છિત માર્ગે જાય છે, કારણ કે ચૂપચાપ સંપૂર્ણ બાયપાસ બની ગયેલો સ્થાનિક અપવાદ એક વધારાનું ટેપ જરૂરી હોય તેવા કાસ્ટ કરતાં ખરાબ પરિણામ છે.