പേജ് VPN വഴി ലോഡ് ചെയ്യുന്നു, എന്നാൽ കോൾ ഒരിക്കലും കണക്ട് ആകുന്നില്ല: ഒരേ വിലാസ ബാറിൽ രണ്ട് വ്യത്യസ്ത പരാജയങ്ങൾ. ടണൽ ബ്രൗസർ ഉപയോഗിക്കുന്ന പാത മാറ്റി; അത് സിഗ്നലിംഗ് സേവനമോ STUN സർവറോ റിലേയോ ആയില്ല, കൂടാതെ ICE ഏത് സ്ഥാനാർത്ഥി ജോടി തിരഞ്ഞെടുക്കുമെന്നും അത് തീരുമാനിക്കുന്നില്ല. ഓരോ ഘടകവും ചെയ്യുന്ന ജോലി വേർതിരിക്കുന്നതാണ് അവ്യക്തമായ “WebRTC തടഞ്ഞിരിക്കുന്നു” എന്നതിനെ നിർദ്ദിഷ്ട തകരാറാക്കി മാറ്റുന്നത്.

നാല് ജോലികൾ, അതിൽ ടണൽ സ്പർശിക്കുന്നത് ഒന്നിനെ മാത്രം

ആപ്ലിക്കേഷൻ ഏതോ സിഗ്നലിംഗ് ക്രമീകരണത്തിലൂടെ സെഷൻ വിവരങ്ങൾ കൈമാറുന്നു, അതാണ് ആദ്യ ജോലി. ICE സ്ഥാനാർത്ഥി വിലാസങ്ങൾ ശേഖരിച്ച് ഒന്ന് പ്രവർത്തിക്കുന്നതുവരെ ജോടികൾ പരിശോധിക്കുന്നു, അതാണ് രണ്ടാമത്തേത്. STUN ഒരു സഹചരന് അവന്റെ ട്രാഫിക് പുറത്തുനിന്ന് എങ്ങനെ കാണപ്പെടുന്നുവെന്ന് അറിയാൻ അനുവദിക്കുന്നു, TURN നേരിട്ടുള്ള പാതയില്ലാത്ത സന്ദർഭങ്ങൾക്ക് ഒരു റിലേ അനുവദിക്കുന്നു. ആ നാല് വേഷങ്ങൾ വ്യത്യസ്തമാണ്, VPN അവർ നേരിടുന്ന വിലാസങ്ങളെയും ഫിൽട്ടറിംഗിനെയും സ്വാധീനിക്കുന്നു, അവയിൽ ഏതെങ്കിലും നൽകുന്നില്ല.

അതിനാൽ വിജയകരമായ ലോഗിൻ മീഡിയ പാതയെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല. സിഗ്നലിംഗ് സാധാരണയായി പേജ് ഇതിനകം ഉപയോഗിക്കുന്ന അതേ HTTPS-ൽ, പോർട്ട് 443-ൽ സഞ്ചരിക്കുന്നു, അതേസമയം മീഡിയ UDP വഴി തികച്ചും വ്യത്യസ്തമായ ലക്ഷ്യസ്ഥാനത്തേക്ക് പോകാം.

സ്വകാര്യ വിലാസനിർണ്ണയം ആശയക്കുഴപ്പം വർദ്ധിപ്പിക്കുന്നു. ടണൽ വിലാസം ഒരു സഹചരന് ഉപകാരപ്രദമാകുന്നത് അയാൾക്ക് അങ്ങോട്ട് തിരിച്ചുള്ള ഉദ്ദേശിച്ച പാത ഉള്ളപ്പോൾ മാത്രമാണ്; സ്വകാര്യമായിരിക്കുന്നത് പരസ്പര പ്രാപ്യതയുടെ തെളിവല്ല, പരിശോധിക്കാൻ കഴിയാത്ത സ്ഥാനാർത്ഥികളെ ഒഴിവാക്കുമ്പോൾ ബ്രൗസറുകളും അതിനെ അങ്ങനെ കണക്കാക്കുന്നില്ല. നിങ്ങൾക്ക് പ്രാദേശികമായി തോന്നുന്ന ഒരു സ്ഥാനാർത്ഥി മറുവശത്തുനിന്ന് പരിശോധിക്കാനാകാത്തതായിരിക്കാം. ടണൽ മീഡിയ വീഴ്ത്തുന്നുവെന്ന് അനുമാനിക്കുന്നതിന് മുമ്പ് ആ വിടവ് ഒഴിവാക്കേണ്ടതാണ്.

VPN എഗ്രസിനെ TURN റിലേയുമായി താരതമ്യം ചെയ്യുക

രണ്ടും പാക്കറ്റുകൾ കൈമാറുന്നു, അതുകൊണ്ടാണ് അവ കൂട്ടിക്കലർത്തപ്പെടുന്നത്, മേലുള്ള താരതമ്യ പട്ടിക സവിശേഷതകളുടെ പട്ടികയായല്ല, നിരയായി വായിക്കേണ്ടതാണ്. റിലേ അനുവദനം എന്നത് പ്രാമാണീകരിച്ച അഭ്യർത്ഥനയാൽ സൃഷ്ടിക്കപ്പെടുന്ന ഓരോ സെഷനുമുള്ള വസ്തുവാണ്; ടണൽ ഒരു പാതയാണ്. ഒന്നിന് കാലഹരണപ്പെടുന്ന ക്രെഡൻഷ്യലുകളുണ്ട്, മറ്റൊന്നിന് എത്തിച്ചേരാവുന്നതോ അല്ലാത്തതോ ആയ സഹചര വിലാസമുണ്ട്.

ComponentWhat it contributesWhat it needs to workWhat it cannot do
VPN exitChanges the observed mapping and the route packets takeA working tunnel and a policy that permits the media transportAllocate a relay or supply signaling
STUN serverReports the mapped address a peer appears to useReachability from the client, on its configured transportCarry media when a direct path fails
TURN serverRelays media through an authenticated allocationValid credentials, an allowed transport and sufficient capacityFix a missing ICE policy or an unauthorized client
Signaling channelCarries offers, answers and candidate listsBoth peers reaching the same application endpointEstablish connectivity by itself

പോർട്ട് നമ്പറുകൾ വ്യത്യാസം മൂർത്തമാക്കുന്നു. TURN സ്വതവേ UDP, TCP എന്നിവയ്ക്ക് 3478-ലും TLS-ന് 5349-ലും കേൾക്കുന്നു, 443 അനുവദിക്കുകയും എന്നാൽ ആ പോർട്ടുകൾ ഉപേക്ഷിക്കുകയും ചെയ്യുന്ന നെറ്റ്‌വർക്ക്, ബ്രൗസിംഗ് സാധാരണയായി തുടരുമ്പോഴും റിലേ ചെയ്ത കോളുകൾ പരാജയപ്പെടുത്തും. VPN-ന്റെ പോർട്ട് മാറ്റുന്നത് അവയൊന്നും കോൺഫിഗർ ചെയ്യുന്നില്ല, കാരണം പ്രധാന പോർട്ടുകൾ ടണലിന്റേതല്ല, റിലേ സേവനത്തിന്റേതാണ്.

ഡയഗ്നോസ്റ്റിക്സ് വായിച്ചതിന് ശേഷം കോൾ പരിശോധിക്കുക

പാക്കറ്റ് ക്യാപ്ചർ ഇല്ലാതെ ബ്രൗസറുകൾ ആവശ്യമായ വിവരങ്ങൾ കാണിക്കുന്നു. നിങ്ങളുടെ ബ്രൗസറിനായുള്ള WebRTC ഡയഗ്നോസ്റ്റിക്സ് പേജ് തുറന്ന് കോൾ ചെയ്ത്, ശേഖരിച്ച പട്ടികയ്ക്ക് പകരം തിരഞ്ഞെടുത്ത സ്ഥാനാർത്ഥി ജോടി വായിക്കുക: ഏത് പ്രാദേശിക, ദൂരസ്ഥ സ്ഥാനാർത്ഥി തരങ്ങളാണ് തിരഞ്ഞെടുത്തത്, ഏത് ട്രാൻസ്പോർട്ടിലൂടെയും വിലാസ കുടുംബത്തിലൂടെയും, പാത നേരിട്ടുള്ളതാണോ റിലേ ചെയ്തതാണോ.

രണ്ട് വായനകൾ മുൻകൂട്ടി അറിയുന്നത് നല്ലതാണ്. തിരഞ്ഞെടുത്ത ജോടി സ്വകാര്യ വിലാസങ്ങളിലെ ഹോസ്റ്റ്-ടു-ഹോസ്റ്റ് ആണെങ്കിൽ മീഡിയ ന്യായവാദം ചെയ്യാവുന്ന ഒരു പാതയിൽ തുടരുന്നു; റിലേ-ടു-റിലേ ആണെങ്കിൽ കോൾ റിലേ ശേഷി ചെലവഴിക്കുന്നു, ആ സേവനത്തിന്റെ ലഭ്യതയെ ആശ്രയിക്കുന്നു. തിരഞ്ഞെടുത്ത ജോടിയില്ലാതെ “പരിശോധിക്കുന്നു” എന്നതിൽ നിൽക്കുന്ന പരാജയം അർത്ഥമാക്കുന്നത് സ്ഥാനാർത്ഥികൾ ശേഖരിക്കപ്പെട്ടു, പക്ഷേ ഒന്നും കണക്റ്റിവിറ്റി പരിശോധനകൾ പാസായില്ല.

പിന്നീട് അതേ കോളിലെ അതേ രണ്ട് അറ്റങ്ങളെ, അംഗീകരിച്ച ഒരു വ്യവസ്ഥ മാത്രം മാറ്റി താരതമ്യം ചെയ്യുക, ഫലം “കണക്ട് ചെയ്തു” എന്ന സൂചകത്തിലല്ല, ഇരുവശ മീഡിയയിലോ ഡാറ്റയിലോ അംഗീകരിക്കുക. സ്ഥാനാർത്ഥി ശേഖരണം ഒരൊറ്റ ഓഡിയോ ഫ്രെയിമും വഹിക്കാത്ത പല സന്ദർഭങ്ങളിലും വിജയിക്കുന്നു. മാറ്റത്തിന്റെ മറുവശത്ത് കോൾ ആവർത്തിച്ച് രണ്ട് ഡയഗ്നോസ്റ്റിക് ക്യാപ്ചറുകളും സൂക്ഷിക്കുക, കാരണം രണ്ട് പ്രവർത്തനങ്ങൾ താരതമ്യം ചെയ്യുന്നത് ഏതെങ്കിലും ഒന്ന് മാത്രം വായിക്കുന്നതിനേക്കാൾ കൂടുതൽ വിവരം നൽകുന്നു. അതേ അറ്റങ്ങൾ, അതേ കോഡെക്, മാറ്റിയ ഒരു ചരം.

തങ്ങളുടെ ICE ട്രാൻസ്പോർട്ട് നയം ബോധപൂർവം relay-ൽ വയ്ക്കുന്ന ആപ്ലിക്കേഷൻ റിലേ സ്ഥാനാർത്ഥികളെ മാത്രമാണ് ആവശ്യപ്പെടുന്നത്. ആ ക്രമീകരണം ഒരു റിലേ സൃഷ്ടിക്കുന്നുമില്ല, കാണാത്ത ക്രെഡൻഷ്യലുകൾ നന്നാക്കുന്നുമില്ല; അത് ആവശ്യകത വ്യക്തമാക്കുന്നു, സൈറ്റ് തിരഞ്ഞെടുത്ത നയത്തിന് ആരെങ്കിലും VPN-നെ കുറ്റപ്പെടുത്തുമ്പോൾ ഇത് ഉപകരിക്കുന്നു.

സ്വകാര്യതാ വാദം തെളിവുകളോളം ഇടുങ്ങിയതാക്കി നിർത്തുക

സ്ഥാനാർത്ഥികളുടെ വെളിപ്പെടുത്തൽ ടണലിന്റെ അവസ്ഥയിൽ മാത്രമല്ല, ബ്രൗസർ, ആപ്ലിക്കേഷൻ നയങ്ങളിലും ആശ്രയിച്ചിരിക്കുന്നു, W3C-യുടെ പിയർ കണക്ഷൻ സ്പെസിഫിക്കേഷൻ IP കൈകാര്യം ചെയ്യുന്നതിനെ സ്വന്തം വിഷയമായി കണക്കാക്കുന്നു. അതിനാൽ കണക്ട് ചെയ്ത VPN, ഒരു കോൾ തിരഞ്ഞെടുത്ത ഒരു വിലാസം മാത്രം വെളിപ്പെടുത്തുമെന്ന് വാഗ്ദാനം ചെയ്യാൻ ദുർബലമായ അടിത്തറയാണ്. ഒരേ ടണലിന് പിന്നിലുള്ള രണ്ട് സഹചരർ ഹോസ്റ്റ് ഒരിക്കലും വിട്ടുപോകാത്ത ഒരു പാത പോലും തിരഞ്ഞെടുക്കാം, അത് ഒരേ സമയം സ്വകാര്യതയുടെ മെച്ചപ്പെടുത്തലും കണക്റ്റിവിറ്റിയുടെ പരിമിതിയുമാണ്.

നിങ്ങൾക്ക് കൃത്യമായി പറയാൻ കഴിയുന്നത് കൂടുതൽ ഇടുങ്ങിയതും ഉപയോഗപ്രദവുമാണ്: ഏത് സ്ഥാനാർത്ഥി ജോടിയാണ് തിരഞ്ഞെടുത്തത്, ഏത് ട്രാൻസ്പോർട്ടാണ് അതിനെ വഹിച്ചത്, ആ പാത ടണലിനുള്ളിൽ തുടർന്നുവോ. പ്രവർത്തിക്കുന്നതും പരാജയപ്പെടുന്നതുമായ കോളിന് ഈ മൂന്ന് വസ്തുതകൾ രേഖപ്പെടുത്തുക, വ്യത്യാസം സാധാരണയായി തിരുത്തേണ്ട ഘടകത്തെ പേരെടുത്ത് പറയുന്നു.

കണക്റ്റിവിറ്റി പ്രവർത്തിച്ചുകഴിഞ്ഞാൽ, പ്രകടനത്തെ പ്രാപ്യതയിൽ നിന്ന് വേർതിരിക്കുക. നഷ്ടം, കാലതാമസം, ക്യൂ, MTU എന്നിവയെല്ലാം ശരിയായ സ്ഥാനാർത്ഥി ജോടിയുടെ താഴേക്കാണ്, ഇടറുന്ന ഒരു കോളിനെ കണക്റ്റിവിറ്റി പരാജയമായി കാണുന്നത് കാരണമില്ലാതെ നിങ്ങളെ സ്ഥാനാർത്ഥി പട്ടികയിലേക്ക് തിരികെ അയയ്ക്കുന്നു.

അനുബന്ധ ലേഖനങ്ങൾ