VPN vs 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 ಎಲ್ಲವೂ ಸರಿಯಾದ ಅಭ್ಯರ್ಥಿ ಜೋಡಿಯ ಕೆಳಗಿನ ಹಂತದಲ್ಲಿವೆ, ಮತ್ತು ಕಡಿತಗೊಳ್ಳುವ ಕರೆಯನ್ನು ಸಂಪರ್ಕ ವೈಫಲ್ಯವೆಂದು ಪರಿಗಣಿಸುವುದು ನಿಮ್ಮನ್ನು ಕಾರಣವಿಲ್ಲದೆ ಅಭ್ಯರ್ಥಿ ಪಟ್ಟಿಗೆ ಹಿಂತಿರುಗಿಸುತ್ತದೆ.