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 એ બધા સાચી ઉમેદવાર-જોડીની નીચેની બાજુએ આવેલા છે, અને અટકી જતા કૉલને જોડાણ-નિષ્ફળતા ગણવાથી તમે કારણ વિના ઉમેદવાર-યાદી તરફ પાછા ફરો છો.