VPN ਬਨਾਮ TURN ਰੀਲੇ: WebRTC ਕਾਲ ਅਸਲ ਵਿੱਚ ਕੌਣ ਢੋਂਦਾ ਹੈ?
ਟਨਲ ICE ਜੋ ਰਸਤਾ ਵੇਖਦਾ ਹੈ ਉਸ ਨੂੰ ਬਦਲਦੀ ਹੈ; ਇਹ ਕਦੇ ਰੀਲੇ ਨਿਰਧਾਰਤ ਨਹੀਂ ਕਰਦੀ ਅਤੇ ਸਿਗਨਲਿੰਗ ਨਹੀਂ ਦਿੰਦੀ। ਤੁਲਨਾ ਕਰੋ ਕਿ VPN ਐਗਰੈਸ ਅਤੇ TURN ਸਰਵਰ ਕੀ ਦਿੰਦੇ ਹਨ।
ਪੇਜ VPN ਰਾਹੀਂ ਲੋਡ ਹੁੰਦਾ ਹੈ, ਪਰ ਕਾਲ ਕਦੇ ਨਹੀਂ ਜੁੜਦੀ: ਇੱਕੋ ਪਤਾ-ਪੱਟੀ ਵਿੱਚ ਦੋ ਵੱਖਰੀਆਂ ਨਾਕਾਮੀਆਂ। ਟਨਲ ਨੇ ਬ੍ਰਾਊਜ਼ਰ ਵੱਲੋਂ ਵਰਤਿਆ ਜਾਣ ਵਾਲਾ ਰਸਤਾ ਬਦਲ ਦਿੱਤਾ; ਇਹ ਸਿਗਨਲਿੰਗ ਸੇਵਾ, STUN ਸਰਵਰ ਜਾਂ ਰੀਲੇ ਨਹੀਂ ਬਣੀ, ਅਤੇ ICE ਕਿਹੜੀ ਉਮੀਦਵਾਰ ਜੋੜੀ ਚੁਣੇਗਾ ਇਹ ਵੀ ਇਹ ਤੈਅ ਨਹੀਂ ਕਰਦੀ। ਹਰ ਹਿੱਸੇ ਦਾ ਕੰਮ ਵੱਖ ਕਰਨਾ ਹੀ ਧੁੰਦਲੀ “WebRTC ਬਲਾਕ ਹੈ” ਨੂੰ ਇੱਕ ਪੱਕੀ ਖਰਾਬੀ ਬਣਾਉਂਦਾ ਹੈ।
ਚਾਰ ਕੰਮ, ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ ਟਨਲ ਸਿਰਫ਼ ਇੱਕ ਨੂੰ ਛੂੰਹਦੀ ਹੈ
ਐਪਲੀਕੇਸ਼ਨ ਕਿਸੇ ਸਿਗਨਲਿੰਗ ਪ੍ਰਬੰਧ ਰਾਹੀਂ ਸੈਸ਼ਨ ਜਾਣਕਾਰੀ ਦਾ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਹ ਪਹਿਲਾ ਕੰਮ ਹੈ। ICE ਉਮੀਦਵਾਰ ਪਤੇ ਇਕੱਠੇ ਕਰਦਾ ਹੈ ਅਤੇ ਇੱਕ ਦੇ ਕੰਮ ਕਰਨ ਤੱਕ ਜੋੜੀਆਂ ਜਾਂਚਦਾ ਹੈ, ਇਹ ਦੂਜਾ ਹੈ। STUN ਸਾਥੀ ਨੂੰ ਜਾਣਨ ਦਿੰਦਾ ਹੈ ਕਿ ਉਸ ਦਾ ਟ੍ਰੈਫਿਕ ਬਾਹਰੋਂ ਕਿਹੋ ਜਿਹਾ ਦਿਸਦਾ ਹੈ, ਅਤੇ TURN ਉਹਨਾਂ ਹਾਲਾਤਾਂ ਲਈ ਰੀਲੇ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ ਜਿੱਥੇ ਸਿੱਧਾ ਰਸਤਾ ਨਹੀਂ ਹੁੰਦਾ। ਉਹ ਚਾਰ ਭੂਮਿਕਾਵਾਂ ਵੱਖਰੀਆਂ ਹਨ, ਅਤੇ VPN ਉਹਨਾਂ ਪਤਿਆਂ ਤੇ ਫਿਲਟਰਿੰਗ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀ ਹੈ ਜਿਨ੍ਹਾਂ ਦਾ ਉਹ ਸਾਹਮਣਾ ਕਰਦੇ ਹਨ, ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਖੁਦ ਨਹੀਂ ਦਿੰਦੀ।
ਇਸ ਲਈ ਕਾਮਯਾਬ ਲੌਗਇਨ ਮੀਡੀਆ-ਰਸਤੇ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ। ਸਿਗਨਲਿੰਗ ਆਮ ਤੌਰ ਤੇ ਉਸੇ HTTPS ਉੱਤੇ ਚੱਲਦੀ ਹੈ ਜੋ ਪੇਜ ਪਹਿਲਾਂ ਹੀ ਵਰਤਦਾ ਹੈ, ਪੋਰਟ 443 ਉੱਤੇ, ਜਦਕਿ ਮੀਡੀਆ UDP ਰਾਹੀਂ ਬਿਲਕੁਲ ਵੱਖਰੀ ਮੰਜ਼ਿਲ ਵੱਲ ਜਾ ਸਕਦਾ ਹੈ।
ਨਿੱਜੀ ਪਤਾ-ਪ੍ਰਣਾਲੀ ਉਲਝਣ ਵਧਾਉਂਦੀ ਹੈ। ਟਨਲ ਪਤਾ ਸਾਥੀ ਲਈ ਤਦ ਹੀ ਲਾਭਦਾਇਕ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਉਸ ਕੋਲ ਉੱਥੇ ਵਾਪਸ ਆਉਣ ਦਾ ਇਰਾਦਾ ਕੀਤਾ ਰਸਤਾ ਹੋਵੇ; ਨਿੱਜੀ ਹੋਣਾ ਆਪਸੀ ਪਹੁੰਚ ਦਾ ਸਬੂਤ ਨਹੀਂ, ਅਤੇ ਜਾਂਚ ਨਾ ਹੋ ਸਕਣ ਵਾਲੇ ਉਮੀਦਵਾਰ ਹਟਾਉਂਦੇ ਸਮੇਂ ਬ੍ਰਾਊਜ਼ਰ ਇਸ ਨੂੰ ਉਸ ਤਰ੍ਹਾਂ ਨਹੀਂ ਮੰਨਦੇ। ਤੁਹਾਨੂੰ ਸਥਾਨਕ ਦਿਸਣ ਵਾਲਾ ਉਮੀਦਵਾਰ ਦੂਜੇ ਪਾਸਿਓਂ ਅਣਜਾਂਚਿਆ ਹੋ ਸਕਦਾ ਹੈ। ਟਨਲ ਮੀਡੀਆ ਡੇਗ ਰਹੀ ਹੈ ਇਹ ਸਿੱਟਾ ਕੱਢਣ ਤੋਂ ਪਹਿਲਾਂ ਉਹ ਪਾੜਾ ਹਟਾਉਣਾ ਚਾਹੀਦਾ ਹੈ।
VPN ਐਗਰੈਸ ਦੀ TURN ਰੀਲੇ ਨਾਲ ਤੁਲਨਾ ਕਰੋ
ਦੋਵੇਂ ਪੈਕਟ ਅੱਗੇ ਭੇਜਦੇ ਹਨ, ਇਸ ਲਈ ਉਹਨਾਂ ਨੂੰ ਮਿਲਾ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਉੱਪਰਲੀ ਤੁਲਨਾ-ਸਾਰਣੀ ਨੂੰ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੀ ਸੂਚੀ ਵਾਂਗ ਨਹੀਂ, ਕਾਲਮ-ਦਰ-ਕਾਲਮ ਪੜ੍ਹਨਾ ਚਾਹੀਦਾ ਹੈ। ਰੀਲੇ ਨਿਰਧਾਰਣ ਪ੍ਰਮਾਣਿਤ ਬੇਨਤੀ ਨਾਲ ਬਣੀ ਪ੍ਰਤੀ-ਸੈਸ਼ਨ ਚੀਜ਼ ਹੈ; ਟਨਲ ਇੱਕ ਰਸਤਾ ਹੈ। ਇੱਕ ਕੋਲ ਮਿਆਦ ਪੁੱਗਣ ਵਾਲੀਆਂ ਪਛਾਣਾਂ ਹਨ, ਦੂਜੇ ਕੋਲ ਸਾਥੀ ਦਾ ਪਤਾ ਜੋ ਜਾਂ ਪਹੁੰਚ ਵਿੱਚ ਹੈ ਜਾਂ ਨਹੀਂ।
| Component | What it contributes | What it needs to work | What it cannot do |
|---|---|---|---|
| VPN exit | Changes the observed mapping and the route packets take | A working tunnel and a policy that permits the media transport | Allocate a relay or supply signaling |
| STUN server | Reports the mapped address a peer appears to use | Reachability from the client, on its configured transport | Carry media when a direct path fails |
| TURN server | Relays media through an authenticated allocation | Valid credentials, an allowed transport and sufficient capacity | Fix a missing ICE policy or an unauthorized client |
| Signaling channel | Carries offers, answers and candidate lists | Both peers reaching the same application endpoint | Establish connectivity by itself |
ਪੋਰਟ ਨੰਬਰ ਫ਼ਰਕ ਨੂੰ ਠੋਸ ਬਣਾਉਂਦੇ ਹਨ। TURN ਡਿਫ਼ਾਲਟ ਰੂਪ ਵਿੱਚ UDP ਅਤੇ TCP ਲਈ 3478 ਉੱਤੇ ਅਤੇ TLS ਲਈ 5349 ਉੱਤੇ ਸੁਣਦਾ ਹੈ, ਅਤੇ ਜੋ ਨੈੱਟਵਰਕ 443 ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ ਪਰ ਉਹ ਪੋਰਟ ਛੱਡ ਦਿੰਦਾ ਹੈ, ਉੱਥੇ ਬ੍ਰਾਊਜ਼ਿੰਗ ਆਮ ਚੱਲਦੀ ਰਹਿਣ ਦੇ ਬਾਵਜੂਦ ਰੀਲੇ ਵਾਲੀਆਂ ਕਾਲਾਂ ਫੇਲ ਹੋਣਗੀਆਂ। VPN ਦਾ ਪੋਰਟ ਬਦਲਣ ਨਾਲ ਇਸ ਵਿੱਚੋਂ ਕੁਝ ਵੀ ਕਨਫ਼ਿਗਰ ਨਹੀਂ ਹੁੰਦਾ, ਕਿਉਂਕਿ ਮਹੱਤਵਪੂਰਨ ਪੋਰਟ ਟਨਲ ਦੇ ਨਹੀਂ, ਰੀਲੇ ਸੇਵਾ ਦੇ ਹਨ।
ਨਿਦਾਨ ਪੜ੍ਹੋ, ਫਿਰ ਕਾਲ ਨੂੰ ਜਾਂਚੋ
ਬ੍ਰਾਊਜ਼ਰ ਪੈਕਟ ਕੈਪਚਰ ਤੋਂ ਬਿਨਾਂ ਲੋੜੀਂਦੀ ਜਾਣਕਾਰੀ ਦਿਖਾਉਂਦੇ ਹਨ। ਆਪਣੇ ਬ੍ਰਾਊਜ਼ਰ ਲਈ WebRTC ਨਿਦਾਨ ਪੇਜ ਖੋਲ੍ਹੋ, ਕਾਲ ਕਰੋ, ਅਤੇ ਇਕੱਠੀ ਕੀਤੀ ਸੂਚੀ ਦੀ ਬਜਾਏ ਚੁਣੀ ਉਮੀਦਵਾਰ-ਜੋੜੀ ਪੜ੍ਹੋ: ਕਿਹੜੇ ਸਥਾਨਕ ਅਤੇ ਦੂਰਲੇ ਉਮੀਦਵਾਰ ਕਿਸਮ ਚੁਣੇ ਗਏ, ਕਿਹੜੇ ਟ੍ਰਾਂਸਪੋਰਟ ਅਤੇ ਪਤਾ-ਪਰਿਵਾਰ ਉੱਤੇ, ਅਤੇ ਰਸਤਾ ਸਿੱਧਾ ਹੈ ਜਾਂ ਰੀਲੇ ਵਾਲਾ।
ਦੋ ਪਾਠ ਪਹਿਲਾਂ ਹੀ ਜਾਣਨੇ ਚਾਹੀਦੇ ਹਨ। ਜੇ ਚੁਣੀ ਜੋੜੀ ਨਿੱਜੀ ਪਤਿਆਂ ਉੱਤੇ ਹੋਸਟ-ਤੋਂ-ਹੋਸਟ ਹੈ, ਮੀਡੀਆ ਉਸ ਰਸਤੇ ਉੱਤੇ ਰਹਿੰਦਾ ਹੈ ਜਿਸ ਬਾਰੇ ਤਰਕ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ; ਜੇ ਇਹ ਰੀਲੇ-ਤੋਂ-ਰੀਲੇ ਹੈ, ਕਾਲ ਰੀਲੇ ਸਮਰੱਥਾ ਖ਼ਰਚਦੀ ਹੈ ਅਤੇ ਉਸ ਸੇਵਾ ਦੀ ਉਪਲਬਧਤਾ ਉੱਤੇ ਨਿਰਭਰ ਹੈ। ਚੁਣੀ ਜੋੜੀ ਤੋਂ ਬਿਨਾਂ “ਜਾਂਚ ਰਿਹਾ ਹੈ” ਉੱਤੇ ਰੁਕਣ ਵਾਲੀ ਨਾਕਾਮੀ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਉਮੀਦਵਾਰ ਇਕੱਠੇ ਹੋਏ ਪਰ ਕੋਈ ਵੀ ਕਨੈਕਟੀਵਿਟੀ ਜਾਂਚ ਪਾਸ ਨਹੀਂ ਕਰ ਸਕਿਆ।
ਫਿਰ ਉਸੇ ਕਾਲ ਵਿੱਚ ਉਹੀ ਦੋ ਸਿਰੇ ਸਿਰਫ਼ ਇੱਕ ਮਨਜ਼ੂਰ ਸ਼ਰਤ ਬਦਲ ਕੇ ਤੁਲਨਾ ਕਰੋ, ਅਤੇ ਨਤੀਜਾ “ਜੁੜਿਆ” ਸੂਚਕ ਉੱਤੇ ਨਹੀਂ, ਦੋ-ਪਾਸੜ ਮੀਡੀਆ ਜਾਂ ਡੇਟਾ ਉੱਤੇ ਸਵੀਕਾਰੋ। ਉਮੀਦਵਾਰ ਸੰਗ੍ਰਹਿ ਅਜਿਹੇ ਕਈ ਮਾਮਲਿਆਂ ਵਿੱਚ ਕਾਮਯਾਬ ਹੁੰਦਾ ਹੈ ਜੋ ਇੱਕ ਵੀ ਆਡੀਓ ਫ਼ਰੇਮ ਨਹੀਂ ਢੋਂਦੇ। ਬਦਲਾਅ ਦੇ ਦੂਜੇ ਪਾਸੇ ਕਾਲ ਦੁਹਰਾਓ ਅਤੇ ਦੋਵੇਂ ਨਿਦਾਨ ਕੈਪਚਰ ਰੱਖੋ, ਕਿਉਂਕਿ ਦੋ ਦੌੜਾਂ ਦੀ ਤੁਲਨਾ ਕਿਸੇ ਇੱਕ ਨੂੰ ਇਕੱਲਾ ਪੜ੍ਹਨ ਨਾਲੋਂ ਵੱਧ ਜਾਣਕਾਰੀ ਦਿੰਦੀ ਹੈ। ਉਹੀ ਸਿਰੇ, ਉਹੀ ਕੋਡੈਕ, ਇੱਕ ਬਦਲਿਆ ਚਰ।
ਜੋ ਐਪਲੀਕੇਸ਼ਨ ਜਾਣ-ਬੁੱਝ ਕੇ ਆਪਣੀ ICE ਟ੍ਰਾਂਸਪੋਰਟ ਨੀਤੀ relay ਉੱਤੇ ਰੱਖਦਾ ਹੈ, ਉਹ ਸਿਰਫ਼ ਰੀਲੇ ਉਮੀਦਵਾਰ ਮੰਗਦਾ ਹੈ। ਉਹ ਸੈਟਿੰਗ ਰੀਲੇ ਨਹੀਂ ਬਣਾਉਂਦੀ ਅਤੇ ਗੁੰਮ ਪਛਾਣਾਂ ਦੀ ਮੁਰੰਮਤ ਨਹੀਂ ਕਰਦੀ; ਇਹ ਲੋੜ ਨੂੰ ਸਪੱਸ਼ਟ ਕਰਦੀ ਹੈ, ਜੋ ਤਦ ਲਾਭਦਾਇਕ ਹੈ ਜਦੋਂ ਕੋਈ ਸਾਈਟ ਵੱਲੋਂ ਚੁਣੀ ਨੀਤੀ ਲਈ VPN ਨੂੰ ਦੋਸ਼ ਦਿੰਦਾ ਹੈ।
ਗੋਪਨੀਯਤਾ ਦਾ ਦਾਅਵਾ ਸਬੂਤਾਂ ਜਿੰਨਾ ਹੀ ਸੀਮਿਤ ਰੱਖੋ
ਉਮੀਦਵਾਰਾਂ ਦਾ ਖੁੱਲ੍ਹਣਾ ਬ੍ਰਾਊਜ਼ਰ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਨੀਤੀ ਉੱਤੇ ਨਿਰਭਰ ਹੈ, ਸਿਰਫ਼ ਟਨਲ ਹਾਲਤ ਉੱਤੇ ਨਹੀਂ, ਅਤੇ W3C ਦੀ ਸਾਥੀ-ਕਨੈਕਸ਼ਨ ਵਿਸ਼ੇਸ਼ਤਾ IP ਸੰਭਾਲ ਨੂੰ ਆਪਣਾ ਵੱਖਰਾ ਮਾਮਲਾ ਮੰਨਦੀ ਹੈ। ਇਸ ਲਈ ਜੁੜੀ VPN ਇਹ ਵਾਅਦਾ ਕਰਨ ਲਈ ਕਮਜ਼ੋਰ ਆਧਾਰ ਹੈ ਕਿ ਕਾਲ ਸਿਰਫ਼ ਇੱਕ ਚੁਣਿਆ ਪਤਾ ਜ਼ਾਹਰ ਕਰਦੀ ਹੈ। ਇੱਕੋ ਟਨਲ ਪਿੱਛੇ ਦੋ ਸਾਥੀ ਹੋਸਟ ਕਦੇ ਨਾ ਛੱਡਣ ਵਾਲਾ ਰਸਤਾ ਵੀ ਚੁਣ ਸਕਦੇ ਹਨ, ਜੋ ਇੱਕੋ ਸਮੇਂ ਗੋਪਨੀਯਤਾ ਦਾ ਸੁਧਾਰ ਅਤੇ ਕਨੈਕਟੀਵਿਟੀ ਦੀ ਸੀਮਾ ਹੈ।
ਤੁਸੀਂ ਜੋ ਸਟੀਕ ਤੌਰ ਤੇ ਕਹਿ ਸਕਦੇ ਹੋ ਉਹ ਵਧੇਰੇ ਸੀਮਿਤ ਅਤੇ ਵਧੇਰੇ ਲਾਭਦਾਇਕ ਹੈ: ਕਿਹੜੀ ਉਮੀਦਵਾਰ-ਜੋੜੀ ਚੁਣੀ ਗਈ, ਕਿਹੜੇ ਟ੍ਰਾਂਸਪੋਰਟ ਨੇ ਉਸ ਨੂੰ ਢੋਇਆ, ਅਤੇ ਉਹ ਰਸਤਾ ਟਨਲ ਦੇ ਅੰਦਰ ਰਿਹਾ ਕਿ ਨਹੀਂ। ਚੱਲਦੀ ਅਤੇ ਨਾਕਾਮ ਕਾਲ ਲਈ ਇਹ ਤਿੰਨ ਤੱਥ ਲਿਖੋ, ਅਤੇ ਫ਼ਰਕ ਆਮ ਤੌਰ ਤੇ ਉਸ ਹਿੱਸੇ ਦਾ ਨਾਮ ਦੱਸਦਾ ਹੈ ਜਿਸ ਨੂੰ ਠੀਕ ਕਰਨਾ ਹੈ।
ਕਨੈਕਟੀਵਿਟੀ ਚੱਲ ਪੈਣ ਤੋਂ ਬਾਅਦ, ਕਾਰਗੁਜ਼ਾਰੀ ਨੂੰ ਪਹੁੰਚ ਤੋਂ ਵੱਖ ਕਰੋ। ਨੁਕਸਾਨ, ਦੇਰੀ, ਕਤਾਰ ਅਤੇ MTU ਸਭ ਸਹੀ ਉਮੀਦਵਾਰ-ਜੋੜੀ ਦੇ ਹੇਠਲੇ ਪਾਸੇ ਹਨ, ਅਤੇ ਟੁੱਟਦੀ ਕਾਲ ਨੂੰ ਕਨੈਕਟੀਵਿਟੀ ਨਾਕਾਮੀ ਮੰਨਣਾ ਤੁਹਾਨੂੰ ਬਿਨਾਂ ਕਾਰਨ ਉਮੀਦਵਾਰ-ਸੂਚੀ ਵੱਲ ਵਾਪਸ ਭੇਜਦਾ ਹੈ।