ਯੋਜਨਾ ਤੋਂ ਬਿਨਾਂ ਮਲਟੀਕਾਸਟ VPN ਨੂੰ ਕਿਉਂ ਪਾਰ ਨਹੀਂ ਕਰਦਾ

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

ਸਮੂਹ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ

ਪੁੱਛੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਕਿਹੜਾ ਸਮੂਹ ਪਤਾ ਵਰਤਦਾ ਹੈ ਅਤੇ ਟ੍ਰੈਫ਼ਿਕ ਕਿਸ ਲਈ ਹੈ। ਸੇਵਾਵਾਂ ਦੀ ਘੋਸ਼ਣਾ ਕਰਨ ਵਾਲਾ ਖੋਜ ਪ੍ਰੋਟੋਕਾਲ, ਸਟ੍ਰੀਮਿੰਗ ਫ਼ੀਡ ਅਤੇ ਰਾਊਟਿੰਗ ਪ੍ਰੋਟੋਕਾਲ ਦੇ ਹੈਲੋ ਪੈਕਟ ਤਿੰਨ ਵੱਖਰੀਆਂ ਸਮੱਸਿਆਵਾਂ ਹਨ, ਤਿੰਨ ਵੱਖਰੇ ਮਨਜ਼ੂਰ ਜਵਾਬ। ਸਮੂਹ ਪਤਾ ਆਪ ਦਾਇਰਾ ਦੱਸਦਾ ਹੈ: ਲੋਕਲ ਨੈੱਟਵਰਕ ਕੰਟਰੋਲ ਬਲਾਕ ਦੇ ਪਤੇ ਆਮ ਰਾਊਟਿੰਗ ਰਾਹੀਂ ਲਿੰਕ ਤੋਂ ਬਾਹਰ ਫਾਰਵਰਡ ਕਰਨ ਲਈ ਨਹੀਂ ਹਨ, ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਵਰਤਣ ਵਾਲੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਆਮ ਤੌਰ ਉੱਤੇ ਇੱਕ ਹੀ ਬ੍ਰਾਡਕਾਸਟ ਡੋਮੇਨ ਮੰਨਦੀਆਂ ਹਨ। ਗਲੋਬਲ ਦਾਇਰੇ ਦੇ ਸਮੂਹ ਉੱਤੇ ਸਟ੍ਰੀਮਿੰਗ ਫ਼ੀਡ ਉਸ ਖੋਜ ਪ੍ਰੋਟੋਕਾਲ ਤੋਂ ਵੱਖਰਾ ਡਿਜ਼ਾਈਨ ਹੈ ਜੋ ਉਮੀਦ ਕਰਦਾ ਹੈ ਕਿ ਹਰ ਡਿਵਾਈਸ ਹਰ ਕਵੈਰੀ ਸੁਣੇਗਾ, ਅਤੇ ਬ੍ਰਾਡਕਾਸਟ ਡੋਮੇਨ ਦੇ ਆਕਾਰ ਦੀ ਚਿੰਤਾ ਸਿਰਫ਼ ਦੂਜੇ ਨੂੰ ਹੈ।

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

ਲਿੰਕ-ਲੋਕਲ ਖੋਜ ਰੁਕਣੀ ਚਾਹੀਦੀ ਹੈ

RFC 6762 ਵਿੱਚ ਵਰਣਿਤ ਮਲਟੀਕਾਸਟ DNS ਇੱਕ ਹੀ ਲਿੰਕ ਦੁਆਲੇ ਬਣਾਇਆ ਗਿਆ ਹੈ: ਕਵੈਰੀਆਂ ਇੱਕ ਨਿਸ਼ਚਿਤ ਸਮੂਹ ਵੱਲ ਜਾਂਦੀਆਂ ਹਨ, ਜਵਾਬ ਉਸੇ ਸਮੂਹ ਨੂੰ ਭੇਜੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਪ੍ਰੋਟੋਕਾਲ ਇਸ ਉੱਤੇ ਨਿਰਭਰ ਹੈ ਕਿ ਹਰ ਭਾਗੀਦਾਰ ਸਾਰਿਆਂ ਨੂੰ ਸੁਣਦਾ ਹੈ। ਰਾਊਟਰ ਉਹ ਟ੍ਰੈਫ਼ਿਕ ਡਿਫ਼ਾਲਟ ਰੂਪ ਵਿੱਚ ਫਾਰਵਰਡ ਨਹੀਂ ਕਰਦੇ, ਅਤੇ ਇਹ ਗ਼ਲਤੀ ਨਹੀਂ ਬਲਕਿ ਡਿਜ਼ਾਈਨ ਫ਼ੈਸਲਾ ਹੈ। ਹੱਦ ਇਸ ਲਈ ਹੈ ਕਿ ਇੱਕ ਇਮਾਰਤ ਦਾ ਡਿਵਾਈਸ ਦੂਜੀ ਵਿੱਚ ਆਸਾਨੀ ਨਾਲ ਆਪਣੀ ਘੋਸ਼ਣਾ ਨਾ ਕਰ ਸਕੇ। ਜੋ ਟਨਲ ਸਮੂਹ ਨੂੰ ਹਰ ਜਗ੍ਹਾ ਚੁੱਕ ਕੇ ਖੋਜ ਠੀਕ ਕਰਦੀ ਦਿਸਦੀ ਹੈ, ਉਸ ਨੇ ਉਹ ਹੱਦ ਹਰ ਐਪਲੀਕੇਸ਼ਨ ਲਈ ਹਟਾ ਦਿੱਤੀ ਹੈ, ਸਿਰਫ਼ ਉਸ ਲਈ ਨਹੀਂ ਜਿਸ ਨੂੰ ਮਦਦ ਚਾਹੀਦੀ ਸੀ।

ਰੀਪੀਟਰ ਅਤੇ ਰਿਫ਼ਲੈਕਟਰ ਮੌਜੂਦ ਹਨ, ਅਤੇ ਇਹ ਅਸਲ ਨਤੀਜਿਆਂ ਵਾਲੀਆਂ ਅਸਲ ਸੇਵਾਵਾਂ ਹਨ: ਇੱਕ ਸਾਈਟ ਉੱਤੇ ਘੋਸ਼ਿਤ ਹਰ ਨਾਮ ਦੂਜੀ ਉੱਤੇ ਦਿਸਣ ਲੱਗਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਲੋਕਾਂ ਜਾਂ ਸਾਜ਼ੋ-ਸਾਮਾਨ ਦੀ ਪਛਾਣ ਕਰਨ ਵਾਲੇ ਡਿਵਾਈਸ ਨਾਮ ਵੀ ਸ਼ਾਮਲ ਹਨ। ਜੇ ਅਸਲ ਲੋੜ ਇਹ ਹੈ ਕਿ ਕੋਈ ਖ਼ਾਸ ਸੇਵਾ ਲੱਭ ਸਕੇ, ਤਾਂ DNS ਵਿੱਚ ਪ੍ਰਕਾਸ਼ਿਤ ਸੇਵਾ ਰਿਕਾਰਡ ਆਮ ਤੌਰ ਉੱਤੇ ਛੋਟਾ ਬਦਲਾਅ ਹੈ, ਅਤੇ ਇਹ ਨਾਵਾਂ ਦੀ ਧਾਰਾ ਦੀ ਥਾਂ ਇੱਕ ਨਾਮ ਹੀ ਜ਼ਾਹਰ ਕਰਦਾ ਹੈ।

ਰਾਊਟਿਡ ਮਲਟੀਕਾਸਟ ਨੂੰ ਲੋੜੀਂਦੀਆਂ ਤਿੰਨ ਚੀਜ਼ਾਂ

ਰਾਊਟਿਡ ਮਲਟੀਕਾਸਟ ਲਈ ਤਿੰਨ ਚੀਜ਼ਾਂ ਮਿਲ ਕੇ ਕੰਮ ਕਰਨੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ: ਸਮੂਹ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਣ ਵਾਲੇ ਪ੍ਰਾਪਤਕਰਤਾ, ਉਸ ਲਈ ਫਾਰਵਰਡਿੰਗ ਸਥਿਤੀ ਰੱਖਣ ਵਾਲੇ ਰਾਊਟਰ, ਅਤੇ ਸਮੂਹ ਪਤਿਆਂ ਨੂੰ ਚੁੱਕਣ ਵਾਲਾ ਟ੍ਰੈਫ਼ਿਕ ਮੰਨਣ ਵਾਲੀ ਟਨਲ। ਜਿਸ ਟਨਲ ਦੀ ਨੀਤੀ ਵਿੱਚ ਸਿਰਫ਼ ਯੂਨੀਕਾਸਟ ਸਬਨੈੱਟ ਸੂਚੀਬੱਧ ਹਨ, ਉਹ ਇਨਕ੍ਰਿਪਸ਼ਨ ਹੱਦ ਉੱਤੇ ਸਮੂਹ ਦਾ ਟ੍ਰੈਫ਼ਿਕ ਡੇਗ ਦੇਵੇਗੀ, ਅਤੇ ਇਸੇ ਲਈ ਪਹਿਲਾ ਲੱਛਣ ਅਕਸਰ ਗ਼ਲਤੀ ਨਹੀਂ ਬਲਕਿ ਸੁੰਨਸਾਨ ਹੁੰਦਾ ਹੈ। GRE ਜਾਂ VTI ਟਨਲ ਵਰਗਾ ਰਾਹ-ਅਧਾਰਿਤ ਇੰਟਰਫ਼ੇਸ ਰਾਊਟਿੰਗ ਟੇਬਲ ਦਾ ਭੇਜਿਆ ਸਭ ਕੁਝ ਚੁੱਕਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਮਲਟੀਕਾਸਟ ਸਥਿਤੀ ਹੋਣ ਉੱਤੇ ਸਮੂਹ ਪਹੁੰਚਯੋਗ ਹੋ ਜਾਂਦਾ ਹੈ।

ਸਰੋਤ ਤੱਕ ਪਹੁੰਚ ਦੂਜਾ ਅੱਧ ਹੈ। PIM ਵਰਗੇ ਮਲਟੀਕਾਸਟ ਰਾਊਟਿੰਗ ਪ੍ਰੋਟੋਕਾਲ ਵੰਡ ਦਰੱਖਤ ਬਣਾਉਂਦੇ ਹਨ ਇਹ ਜਾਂਚ ਕੇ ਕਿ ਸਰੋਤ ਵੱਲ ਵਾਪਸੀ ਰਾਹ ਉਮੀਦ ਮੁਤਾਬਕ ਹੈ, ਇਸ ਲਈ ਕਿਤੇ ਹੋਰ ਸੰਕੇਤ ਕਰਨ ਵਾਲਾ ਯੂਨੀਕਾਸਟ ਰਾਹ ਸਮੂਹ ਮੈਂਬਰਸ਼ਿਪ ਸਹੀ ਹੋਣ ਉੱਤੇ ਵੀ ਦਰੱਖਤ ਤੋੜ ਦਿੰਦਾ ਹੈ। ਪ੍ਰਾਪਤਕਰਤਾ ਲਈ ਰਾਹ ਲਾਉਣਾ ਉਸ ਜਾਂਚ ਲਈ ਕੁਝ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਇਹੀ ਉਹ ਗ਼ਲਤੀ ਹੈ ਜੋ ਚੱਲਦੀ ਪਿੰਗ ਅਤੇ ਫੇਲ੍ਹ ਹੁੰਦੀ ਸਟ੍ਰੀਮ ਦਿੰਦੀ ਹੈ। ਪਹਿਲਾਂ ਸਰੋਤ ਦਾ ਵਾਪਸੀ ਰਾਹ ਪਰਖੋ, ਫਿਰ ਮੈਂਬਰਸ਼ਿਪ ਜੋੜੋ, ਅਤੇ ਉਸ ਤੋਂ ਬਾਅਦ ਹੀ ਐਪਲੀਕੇਸ਼ਨ ਵੱਲ ਵੇਖੋ।

ip maddr show dev tun0
ip mroute show
ss -gnu | grep 239.255.0.10
ip route get 10.20.5.20

ਪਹਿਲੀਆਂ ਦੋ ਲਾਈਨਾਂ ਦੱਸਦੀਆਂ ਹਨ ਕਿ ਹੋਸਟ ਕਿਸ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਇਆ ਅਤੇ ਕਰਨਲ ਕੀ ਫਾਰਵਰਡ ਕਰਦਾ ਹੈ, ਤੀਜੀ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਆਪਣੀ ਮੈਂਬਰਸ਼ਿਪ ਦੱਸਦੀ ਹੈ, ਅਤੇ ਆਖ਼ਰੀ ਉਹ ਯੂਨੀਕਾਸਟ ਰਾਹ ਦੱਸਦੀ ਹੈ ਜੋ ਉਲਟ-ਰਾਹ ਜਾਂਚ ਵਰਤੇਗੀ। ਇਨ੍ਹਾਂ ਨੂੰ ਇਕੱਠੇ ਪੜ੍ਹਨਾ ਕਦੇ ਸ਼ਾਮਲ ਨਾ ਹੋਈ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਕਦੇ ਫਾਰਵਰਡ ਨਾ ਕਰਨ ਵਾਲੇ ਨੈੱਟਵਰਕ ਤੋਂ ਵੱਖ ਕਰਦਾ ਹੈ।

ਇੱਕ ਸਰੋਤ ਅਤੇ ਇੱਕ ਪ੍ਰਾਪਤਕਰਤਾ ਨਾਲ ਸਿੱਧ ਕਰੋ

ਸੰਰਚਨਾ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਪੱਕਾ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਇੱਕ ਹੀ ਸੈਗਮੈਂਟ ਉੱਤੇ ਕੰਮ ਕਰਦੀ ਹੈ। ਜੇ ਇਹ ਸਥਾਨਕ ਤੌਰ ਉੱਤੇ ਫੇਲ੍ਹ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਮਲਟੀਕਾਸਟ ਰਾਊਟਿੰਗ ਸਮੱਸਿਆ ਨਹੀਂ ਅਤੇ ਕੋਈ ਟਨਲ ਬਦਲਾਅ ਮਦਦ ਨਹੀਂ ਕਰੇਗਾ। ਫਿਰ ਟਨਲ ਦੇ ਪਾਰ ਇੱਕ ਪ੍ਰਾਪਤਕਰਤਾ ਨਾਲ ਦੁਹਰਾਓ ਅਤੇ ਇਨਕ੍ਰਿਪਸ਼ਨ ਹੱਦ ਦੇ ਦੋਵੇਂ ਪਾਸੇ ਪੈਕਟ ਵੇਖੋ।

tcpdump -ni tun0 -c 10 'ip multicast'
tcpdump -ni eth0 -c 10 'ip multicast and host 239.255.0.10'

ਟਨਲ ਦੇ ਅੰਦਰ ਦਿਸਣ ਵਾਲੇ ਪਰ ਬਾਹਰ ਨਾ ਹੋਣ ਵਾਲੇ ਪੈਕਟ ਇਨਕੈਪਸੂਲੇਸ਼ਨ ਜਾਂ ਨੀਤੀ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੇ ਹਨ; ਦੋਵੇਂ ਪਾਸੇ ਦਿਸਣ ਵਾਲੇ ਪਰ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਤਰੱਕੀ ਨਾ ਹੋਣ ਵਾਲੇ ਪੈਕਟ ਪ੍ਰਾਪਤਕਰਤਾ ਦੀ ਮੈਂਬਰਸ਼ਿਪ ਜਾਂ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਬੰਨ੍ਹਣ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੇ ਹਨ। ਕੈਪਚਰ ਛੋਟੇ ਅਤੇ ਫ਼ਿਲਟਰ ਕੀਤੇ ਰੱਖੋ, ਕਿਉਂਕਿ ਰੁੱਝੇ ਸੈਗਮੈਂਟ ਉੱਤੇ ਵਿਆਪਕ ਮਲਟੀਕਾਸਟ ਕੈਪਚਰ ਮੁੱਖ ਤੌਰ ਉੱਤੇ ਸ਼ੋਰ ਹੈ।

ਜਦੋਂ ਸਿਰਫ਼ ਸੇਵਾ ਚਾਹੀਦੀ ਹੋਵੇ ਤਾਂ ਸੇਵਾ ਪਤਾ ਚੁਣੋ

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

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