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'ਬਾਅਦ ਵਿੱਚ ਤਿੰਨੇ ਪੜਾਅ ਵੱਖਰੇ-ਵੱਖਰੇ ਜਾਂਚੋ, ਕਿਉਂਕਿ ਇੱਕ ਦੀ ਸਫਲਤਾ ਬਾਕੀਆਂ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਦੱਸਦੀ। ਫਿਰ ਵੇਖੋ ਕਿ ਗੈਰ-ਸੰਬੰਧਿਤ ਫ਼ੋਨ ਐਪਾਂ ਅਜੇ ਵੀ ਇਚ्छਿਤ ਰਾਹ ʼਤੇ ਚੱਲਦੀਆਂ ਹਨ, ਕਿਉਂਕਿ ਚੁੱਪ-ਚਾਪ ਪੂਰੀ ਬਾਈਪਾਸ ਬਣੀ ਸਥਾਨਕ ਛੋਟ ਇੱਕ ਵਾਧੂ ਟੈਪ ਚਾਹੁੰਦੀ ਕਾਸਟ ਨਾਲੋਂ ਮਾੜਾ ਨਤੀਜਾ ਹੈ।