OpenVPN ਉੱਤੇ SSM: ਇੱਕ ਸਰੋਤ ਅਤੇ ਸਮੂਹ ਨੂੰ ਸ਼ੁਰੂ ਤੋਂ ਅੰਤ ਤੱਕ ਟ੍ਰੈਕ ਕਰਨਾ

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

ਪਹਿਲਾਂ ਸਰੋਤ, ਸਮੂਹ ਅਤੇ ਪ੍ਰਾਪਤਕਰਤਾ ਤੈਅ ਕਰੋ

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

232/8 ਰੇਂਜ ਸਰੋਤ-ਖਾਸ multicast ਲਈ ਰਾਖਵੀਂ ਹੈ, ਅਤੇ ਮਾਡਲ RFC 4607 ਵਿੱਚ ਦੱਸਿਆ ਗਿਆ ਹੈ। ਜੇ ਤੁਸੀਂ SSM ਚਲਾ ਰਹੇ ਹੋ ਐਸਾ ਮੰਨਦੇ ਹੋ ਪਰ ਤੁਹਾਡਾ ਸਮੂਹ ਉਸ ਰੇਂਜ ਤੋਂ ਬਾਹਰ ਹੈ, ਤਾਂ ਰੁਕੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਡਿਪਲਾਏਮੈਂਟ ਅਸਲ ਵਿੱਚ ਕੀ ਚਾਹੁੰਦਾ ਹੈ, ਕਿਉਂਕਿ ਪ੍ਰਾਪਤਕਰਤਾ ਦਾ ਸ਼ਾਮਲ ਹੋਣਾ ਅਤੇ ਰਾਊਟਰ ਦਾ ਫਾਰਵਰਡਿੰਗ ਫੈਸਲਾ ਦੋਵੇਂ ਮਾਡਲ ਦੇ ਇਕਸਾਰ ਹੋਣ ’ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ।

ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਪ੍ਰਾਪਤਕਰਤਾ ਸਰੋਤ ਨਾਲ ਸ਼ਾਮਲ ਹੋਇਆ ਹੈ

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

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

ip maddr show dev eth0
cat /proc/net/igmp | sed -n '1,40p'

ਜੇ ਉਮੀਦ ਕੀਤੇ ਸਰੋਤ ਨਾਲ ਸ਼ਾਮਲ ਹੋਣਾ ਮੌਜੂਦ ਹੈ, ਤਾਂ ਰਾਊਟਰਾਂ ਵੱਲ ਵਧੋ। ਜੇ ਇਹ ਨਹੀਂ ਹੈ, ਤਾਂ ਕੋਈ ਵੀ ਟਨਲ ਕਨਫਿਗਰੇਸ਼ਨ ਮਦਦ ਨਹੀਂ ਕਰੇਗੀ, ਕਿਉਂਕਿ ਫਾਰਵਰਡ ਕਰਨ ਲਈ ਕੁਝ ਨਹੀਂ ਹੈ।

ਟਨਲ ਦੇਖਣ ਤੋਂ ਪਹਿਲਾਂ ਵਾਪਸੀ ਮਾਰਗ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ

multicast ਰੂਟਿੰਗ ਵਾਪਸੀ ਮਾਰਗ ਦੀ ਜਾਂਚ ਕਰਦੀ ਹੈ, ਅਤੇ ਜੋ ਪੈਕਟ ਯੂਨੀਕਾਸਟ ਰੂਟ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੇ ਇੰਟਰਫੇਸ ਤੋਂ ਇਲਾਵਾ ਕਿਸੇ ਹੋਰ ਇੰਟਰਫੇਸ ’ਤੇ ਆਉਂਦਾ ਹੈ ਉਹ ਸੁੱਟ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। ਇਹੀ ਸਭ ਤੋਂ ਆਮ ਕਾਰਨ ਹੈ ਕਿ ਸਪਸ਼ਟ ਤੌਰ ’ਤੇ ਭੇਜੀ ਜਾ ਰਹੀ ਸਟ੍ਰੀਮ ਅਗਲੇ ਹੌਪ ਤੱਕ ਕਦੇ ਨਹੀਂ ਪਹੁੰਚਦੀ, ਅਤੇ ਇਹ ਐਪਲੀਕੇਸ਼ਨ ਪੱਧਰ ’ਤੇ ਕੋਈ ਵੀ ਲਾਹੇਵੰਦ ਗਲਤੀ ਪੈਦਾ ਨਹੀਂ ਕਰਦੀ।

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

ਫਿਰ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਸਰੋਤ ਦਾ TTL ਤੁਹਾਡੇ ਡਿਜ਼ਾਈਨ ਕੀਤੇ ਰੂਟ ਕੀਤੇ ਹੌਪਾਂ ਨੂੰ ਪਾਰ ਕਰਨ ਲਈ ਕਾਫ਼ੀ ਵੱਡਾ ਹੈ। ਪਹਿਲੇ ਰਾਊਟਰ ’ਤੇ ਕੰਮ ਕਰਨ ਵਾਲੀ ਅਤੇ ਦੂਜੇ ’ਤੇ ਮਰਨ ਵਾਲੀ ਸਟ੍ਰੀਮ ਅਕਸਰ TTL ਦਾ ਸਵਾਲ ਹੁੰਦੀ ਹੈ, ਨੀਤੀ ਦਾ ਨਹੀਂ।

ਕਨਫਿਗਰੇਸ਼ਨ ਦੀ ਬਜਾਏ ਕਰਨਲ ਦੀ multicast ਸਥਿਤੀ ਪੜ੍ਹੋ

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

ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10

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

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

ਟਨਲ ਅਸਲ ਵਿੱਚ ਕਿਵੇਂ ਪ੍ਰਤੀਰੂਪ ਬਣਾਉਂਦੀ ਹੈ ਇਹ ਤੈਅ ਕਰੋ

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

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

ਅੰਤ ਵਿੱਚ, ਪ੍ਰਾਪਤਕਰਤਾ ’ਤੇ ਤੰਗ ਨਿਰੀਖਣ ਹੇਠ ਜਾਂਚੋ: ਠੀਕ ਸਰੋਤ, ਸਮੂਹ ਅਤੇ ਪੋਰਟ, ਤੁਹਾਡੀ ਉਮੀਦ ਵਾਲੇ ਇੰਟਰਫੇਸ ’ਤੇ, ਜਦੋਂ ਇੱਕ ਅਧਿਕਾਰਤ ਪ੍ਰਾਪਤਕਰਤਾ ਸ਼ਾਮਲ ਹੋਵੇ। SSM ਭੇਜਣ ਵਾਲੇ ਦੀ ਚੋਣ ਕਰਦਾ ਹੈ, ਅਤੇ ਚੋਣ ਉਸ ਭੇਜਣ ਵਾਲੇ ਦੀ ਪ੍ਰਮਾਣਿਕਤਾ ਨਹੀਂ ਹੈ, ਨਾ ਹੀ ਹੋਰ multicast ਟ੍ਰੈਫਿਕ ਲਈ ਉਹੀ ਨੀਤੀ ਪਾਰ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਹੈ।