Chromecast ਅਤੇ DLNA ਖੋਜ ਕਦੇ ਵੀ ਰਾਊਟ ਕੀਤੇ VPN ਨੂੰ ਪਾਰ ਨਹੀਂ ਕਰਦੀ

ਕਾਸਟ ਬਟਨ ਕੁਝ ਵੀ ਸੂਚੀਬੱਧ ਨਹੀਂ ਕਰਦਾ, VLC DLNA ਖਾਲੀ ਰਹਿੰਦਾ ਹੈ, ਅਤੇ ਦੂਜੇ ਸਿਰੇ ਦੀ ਮਸ਼ੀਨ ਬਿਨਾਂ ਸ਼ਿਕਾਇਤ ping ਦਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ। ਇਹ ਸੰਜੋਗ ਬੈਂਡਵਿਡਥ ਦੀ ਸਮੱਸਿਆ ਨਹੀਂ ਹੈ ਅਤੇ ਫਾਇਰਵਾਲ ਦਾ ਰਹੱਸ ਵੀ ਨਹੀਂ। ਇਹਨਾਂ ਪ੍ਰੋਟੋਕੋਲਾਂ ਵਿੱਚ ਖੋਜ ਲੋਕਲ ਸੈਗਮੈਂਟ 'ਤੇ ਸਮੂਹ ਅਦਲ-ਬਦਲ ਹੈ, ਅਤੇ ਰਾਊਟ ਕੀਤੀ ਸੁਰੰਗ ਸਮੂਹ-ਪਤੇ ਵਾਲੀ ਟ੍ਰੈਫਿਕ ਨਹੀਂ ਢੋਂਦੀ. ਜਿਸ ਸੈਸ਼ਨ ਨੂੰ ਤੁਸੀਂ ਸ਼ੁਰੂ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ ਉਹ ਕਦੇ ਪੇਸ਼ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ।

ਪਹੁੰਚ ਠੀਕ ਹੈ। ਖੋਜ ਗੁੰਮ ਹੈ।

ਮਿੱਥ: ਸੁਰੰਗ ਨੂੰ ਸੈਟਿੰਗ ਜਾਂ ਵੱਧ ਸਮਰੱਥਾ ਚਾਹੀਦੀ ਹੈ

ਆਮ ਸੁਝਾਅ ਹਨ ਪੀਅਰ-ਟੂ-ਪੀਅਰ ਟ੍ਰੈਫਿਕ ਸਮਰੱਥ ਕਰਨਾ, MTU ਵਧਾਉਣਾ, ਜਾਂ ਸੁਰੰਗ ਡਿਵਾਈਸ ਦੀ ਕਿਸਮ ਬਦਲਣਾ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਪ੍ਰਸਾਰਨ ਡੋਮੇਨ ਨਹੀਂ ਜੋੜਦਾ। ਮਲਟੀਕਾਸਟ ਸਵਿੱਚਾਂ ਅਤੇ ਲੋਕਲ ਨੈੱਟਵਰਕ ਸਟੈਕ ਦੁਆਰਾ ਪਹੁੰਚਾਇਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਪੁਆਇੰਟ-ਟੂ-ਪੁਆਇੰਟ TUN ਇੰਟਰਫੇਸ ਕੋਲ ਭਰਨ ਲਈ ਕੋਈ ਸਮੂਹ ਪਤਾ ਨਹੀਂ ਹੈ।

ਸੈਟਿੰਗਾਂ ਬਦਲਣ ਨਾਲ ਅਸਫਲਤਾ ਹੋਰ ਉੱਚੀ ਹੋ ਸਕਦੀ ਹੈ। ਪਰ ਪ੍ਰੋਟੋਕੋਲ ਨੇ ਕਦੇ ਨਾ ਭੇਜਿਆ ਐਲਾਨ ਇਹ ਦਿਖਾ ਨਹੀਂ ਸਕਦੀ।

ਖੋਜ ਅਦਲ-ਬਦਲ ਅਸਲ ਵਿੱਚ ਕੀ ਹੈ

ਤੁਹਾਨੂੰ ਮਿਲਣ ਵਾਲੀਆਂ ਲਗਭਗ ਸਾਰੀਆਂ ਚੀਜ਼ਾਂ ਤਿੰਨ ਨਮੂਨੇ ਕਵਰ ਕਰਦੇ ਹਨ। mDNS 224.0.0.251 'ਤੇ UDP 5353 ਰਾਹੀਂ ਭੇਜਦਾ ਹੈ, SSDP 239.255.255.250 'ਤੇ UDP 1900 ਰਾਹੀਂ ਭੇਜਦਾ ਹੈ, ਅਤੇ ਪੁਰਾਣੀਆਂ SMB ਬ੍ਰਾਊਜ਼ ਸੂਚੀਆਂ ਸਬਨੈੱਟ ਦੇ ਪ੍ਰਸਾਰਨ ਪਤੇ 'ਤੇ ਜਾਂਦੀਆਂ ਸਨ। ਹਰ ਇੱਕ ਹੋਸਟ ਨੂੰ ਨਹੀਂ ਸਗੋਂ ਸਮੂਹ ਨੂੰ ਸੰਬੋਧਿਤ ਹੈ, ਅਤੇ ਹਰ ਇੱਕ ਉਸੇ ਸੈਗਮੈਂਟ 'ਤੇ ਸਰੋਤੇ ਦੀ ਉਮੀਦ ਕਰਦਾ ਹੈ। ਰਾਊਟ ਕੀਤੀ ਸੁਰੰਗ ਦੇ ਪਾਰਲੇ ਪਾਸੇ ਦਾ ਪ੍ਰਾਪਤਕਰਤਾ ਉਸ ਸੈਗਮੈਂਟ 'ਤੇ ਨਹੀਂ ਹੈ, ਇਸ ਲਈ ਕੁਝ ਨਹੀਂ ਪਹੁੰਚਦਾ।

ਰੀਲੇ ਕੀਤਾ ਐਲਾਨ ਵੀ ਪੇਲੋਡ ਢੋਂਦਾ ਹੈ: ਆਮ ਤੌਰ 'ਤੇ ਭੇਜਣ ਵਾਲੇ ਦਾ LAN ਪਤਾ ਅਤੇ ਪੋਰਟ, ਜਿੱਥੇ ਦੂਰ ਦੇ ਦਰਸ਼ਕ ਨੂੰ ਫਿਰ ਪਹੁੰਚਣਾ ਪੈਂਦਾ ਹੈ।

ਸੁਰੰਗ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਕੈਪਚਰ ਪੜ੍ਹੋ

ਐਪ ਸਕੈਨ ਕਰਦੇ ਸਮੇਂ ਸੁਰੰਗ ਇੰਟਰਫੇਸ 'ਤੇ ਕੈਪਚਰ ਕਰੋ। ਖਾਲੀ ਕੈਪਚਰ ਦਾ ਮਤਲਬ ਹੈ ਐਲਾਨ ਨੇ ਕਦੇ ਹੱਦ ਪਾਰ ਨਹੀਂ ਕੀਤੀ, ਅਤੇ ਸੁਰੰਗ ਦੀ ਕੋਈ ਵੀ ਟਿਊਨਿੰਗ ਇਹ ਨਹੀਂ ਬਦਲਦੀ। ਐਪ ਦੇ ਅਜੇ ਕੁਝ ਨਾ ਦਿਖਾਉਂਦੇ ਹੋਏ ਦਿਖਣ ਵਾਲੇ ਪੈਕਟ ਅਕਸਰ ਮਤਲਬ ਹੈ ਐਲਾਨਿਆ ਪਤਾ ਦਰਸ਼ਕ ਲਈ ਪਹੁੰਚ ਤੋਂ ਬਾਹਰ ਹੈ — ਇਹ ਖੋਜ ਦੇ ਭੇਸ ਵਿੱਚ ਰਾਊਟਿੰਗ ਸਮੱਸਿਆ ਹੈ।

ਦੋ ਮਿੰਟ ਦਾ ਕੈਪਚਰ ਪੋਰਟਾਂ ਬਾਰੇ ਇੱਕ ਘੰਟੇ ਦੇ ਅੰਦਾਜ਼ੇ ਦੀ ਥਾਂ ਲੈਂਦਾ ਹੈ: tcpdump -ni tun0 udp port 5353 or udp port 1900।

ਤਿੰਨ ਹੱਲ, ਸਭ ਤੋਂ ਸਸਤਾ ਪਹਿਲਾਂ

ਕਲਾਇੰਟ ਨੂੰ ਸਿੱਧਾ ਸੇਵਾ ਪਤੇ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰੋ। DLNA, SMB ਅਤੇ ਸਧਾਰਨ ਮੀਡੀਆ ਸਰਵਰਾਂ ਲਈ ਇਹ ਖੋਜ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਛੱਡ ਦਿੰਦਾ ਹੈ ਅਤੇ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਪੇਲੋਡ ਰਾਹ ਕੰਮ ਕਰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਇਹ ਸਭ ਤੋਂ ਵਧੀਆ ਪਹਿਲਾ ਟੈਸਟ ਅਤੇ ਵਰਤੋਂ ਯੋਗ ਬਦਲ ਵੀ ਬਣ ਜਾਂਦਾ ਹੈ। Chromecast ਅਪਵਾਦ ਹੈ, ਕਿਉਂਕਿ ਪ੍ਰਾਪਤਕਰਤਾ ਸੰਬੋਧਿਤ ਹੋਣ ਦੀ ਥਾਂ ਲੱਭੇ ਜਾਣ ਦੀ ਉਮੀਦ ਕਰਦਾ ਹੈ।

ਗੇਟਵੇ 'ਤੇ ਪ੍ਰੋਟੋਕੋਲ ਰੀਲੇ ਕਰੋ। mDNS ਪਰਾਵਰਤਕ ਸੁਰੰਗ ਅਤੇ LAN ਵਿਚਕਾਰ ਐਲਾਨ ਦੁਹਰਾਉਂਦਾ ਹੈ, ਅਤੇ Avahi ਸਪਸ਼ਟ ਇੰਟਰਫੇਸ ਸੂਚੀ ਲੈਣ ਵਾਲਾ ਪਰਾਵਰਤਕ ਭਾਗ ਦਿੰਦਾ ਹੈ। ਰੀਲੇ ਨੂੰ ਤੰਗ ਰੱਖੋ, ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਐਲਾਨਿਆ ਪਤਾ ਦੋਵਾਂ ਪਾਸਿਆਂ ਤੋਂ ਪਹੁੰਚ ਯੋਗ ਹੈ, ਨਹੀਂ ਤਾਂ ਜਵਾਬ ਅਜੇ ਵੀ ਉਸ ਸਬਨੈੱਟ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ ਜਿੱਥੇ ਦਰਸ਼ਕ ਰਾਊਟ ਨਹੀਂ ਕਰ ਸਕਦਾ।

ਰਾਊਟਿੰਗ ਦੀ ਥਾਂ ਬ੍ਰਿਜ ਕਰੋ। ਸਰਵਰ tap ਡਿਵਾਈਸ ਨੂੰ LAN 'ਤੇ ਬ੍ਰਿਜ ਕਰਨ ਵਾਲਾ TAP ਸੈਗਮੈਂਟ ਦੋਵੇਂ ਸਿਰਿਆਂ ਨੂੰ ਇੱਕ ਪ੍ਰਸਾਰਨ ਡੋਮੇਨ ਵਿੱਚ ਰੱਖਦਾ ਹੈ, ਇਸ ਲਈ ਐਲਾਨ ਅਣਬਦਲਿਆਂ ਲੰਘਦੇ ਹਨ। ਇਹ ਸਭ ਤੋਂ ਮਹਿੰਗਾ ਬਦਲ ਵੀ ਹੈ, ਕਿਉਂਕਿ ਇੱਕ ਸਬਨੈੱਟ ਦਾ ਮਤਲਬ ਇੱਕ ਅਸਫਲਤਾ ਡੋਮੇਨ ਹੈ ਅਤੇ LAN ਦੀ ਹਰ ਮਲਟੀਕਾਸਟ ਸੇਵਾ ਹੁਣ ਹਰ ਪੀਅਰ ਤੱਕ ਪਹੁੰਚਦੀ ਹੈ।

ਕੀ ਮਦਦ ਨਹੀਂ ਕਰਦਾ, ਭਾਵੇਂ ਕਿੰਨੀ ਵੀ ਵਾਰ ਸੁਝਾਇਆ ਜਾਵੇ

ਬ੍ਰਿਜ ਤੋਂ ਬਿਨਾਂ dev tun ਨੂੰ dev tap ਵਿੱਚ ਬਦਲਣ ਨਾਲ ਅਜੇ ਵੀ ਰਾਊਟ ਕੀਤਾ TAP ਡਿਵਾਈਸ ਰਹਿ ਜਾਂਦਾ ਹੈ, ਇਸ ਲਈ ਵਿਵਹਾਰ ਨਹੀਂ ਬਦਲਦਾ। client-to-client ਪੀਅਰ-ਟੂ-ਪੀਅਰ ਯੂਨੀਕਾਸਟ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ ਅਤੇ ਪ੍ਰਸਾਰਨ ਨਹੀਂ ਭਰਦਾ। ਖੋਜ ਪੋਰਟ ਨੂੰ ਇੱਕ ਹੋਸਟ 'ਤੇ ਫਾਰਵਰਡ ਕਰਨ ਨਾਲ ਸਮੂਹ-ਪਤੇ ਵਾਲੀ ਟ੍ਰੈਫਿਕ ਨਹੀਂ ਪਹੁੰਚਦੀ। ਇੱਕ ਪਤੇ ਨਾਲ ਬੱਝਿਆ ਮੀਡੀਆ ਸਰਵਰ ਆਪਣੀ ਸੰਰਚਨਾ ਵਿੱਚ VPN ਇੰਟਰਫੇਸ ਸੂਚੀਬੱਧ ਨਾ ਹੋਣ ਤੱਕ ਉਸੇ ਪਤੇ 'ਤੇ ਜਵਾਬ ਦਿੰਦਾ ਰਹਿੰਦਾ ਹੈ।

ਇੱਕ ਸਿੱਧੀ ਯੂਨੀਕਾਸਟ ਬੇਨਤੀ ਅਜ਼ਮਾਓ, ਫਿਰ ਇੱਕ ਐਲਾਨੀ ਬੇਨਤੀ। ਜੇ ਪਹਿਲੀ ਕੰਮ ਕਰੇ ਅਤੇ ਦੂਜੀ ਨਾ ਕਰੇ, ਸੁਰੰਗ ਤੰਦਰੁਸਤ ਹੈ ਅਤੇ ਖੋਜ ਹੀ ਪੂਰੀ ਸਮੱਸਿਆ ਹੈ।