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 به‌طور پیش‌فرض روی 3478 برای UDP و TCP و روی 5349 برای TLS گوش می‌دهد، و شبکه‌ای که 443 را مجاز می‌داند اما آن درگاه‌ها را می‌اندازد، تماس‌های رله‌شده را ناموفق می‌کند در حالی که مرور وب عادی ادامه دارد. تغییر درگاه VPN هیچ‌یک از این‌ها را پیکربندی نمی‌کند، چون درگاه‌های مهم به سرویس رله تعلق دارند نه به تونل.
تشخیص‌ها را بخوانید، سپس تماس را بیازمایید
مرورگرها اطلاعات لازم را بدون ضبط بسته در دسترس می‌گذارند. صفحه تشخیص WebRTC مرورگر خود را باز کنید، تماس را برقرار کنید و جفت نامزد انتخاب‌شده را بخوانید نه فهرست جمع‌آوری‌شده را: کدام انواع نامزد محلی و راه دور انتخاب شدند، روی کدام انتقال و خانواده نشانی، و اینکه مسیر مستقیم است یا رله‌شده.
دو خوانش را از پیش بدانید. اگر جفت انتخاب‌شده میزبان‌به‌میزبان روی نشانی‌های خصوصی باشد، رسانه روی مسیری می‌ماند که می‌توانید درباره‌اش استدلال کنید؛ اگر رله‌به‌رله باشد، تماس ظرفیت رله را مصرف می‌کند و به دسترس‌پذیری آن سرویس وابسته است. خرابی‌ای که در «در حال بررسی» بدون جفت انتخاب‌شده متوقف می‌شود یعنی نامزدها جمع شده‌اند اما هیچ‌کدام از بررسی‌های اتصال نگذشته‌اند.
سپس همان دو نقطه پایانی را در همان تماس مقایسه کنید و تنها یک شرط تأییدشده را تغییر دهید، و نتیجه را بر پایه رسانه یا داده دوسویه بپذیرید نه بر پایه نشانگر «متصل». جمع‌آوری نامزد در بسیاری از مواردی موفق می‌شود که حتی یک فریم صدا را حمل نمی‌کنند. تماس را در سوی دیگر تغییر تکرار کنید و هر دو ضبط تشخیصی را نگه دارید، چون مقایسه دو اجرا آموزنده‌تر از خواندن هر یک به‌تنهایی است. همان نقاط پایانی، همان کدک، یک متغیر تغییر کرده.
برنامه‌ای که عمداً خط‌مشی انتقال ICE خود را روی relay می‌گذارد فقط نامزدهای رله می‌خواهد. این تنظیم رله نمی‌سازد و اعتبارنامه‌های گم‌شده را ترمیم نمی‌کند؛ الزام را صریح می‌کند، چیزی که وقتی کسی VPN را برای خط‌مشی‌ای که خود سایت انتخاب کرده سرزنش می‌کند سودمند است.
ادعای حریم خصوصی را به‌اندازه شواهد محدود نگه دارید
آشکارشدن نامزد به خط‌مشی مرورگر و برنامه وابسته است، نه فقط به وضعیت تونل، و مشخصات W3C برای اتصال همتا رسیدگی به IP را موضوعی مستقل می‌داند. بنابراین VPN متصل پایه ضعیفی برای وعده دادن است که تماس فقط یک نشانی انتخاب‌شده را آشکار می‌کند. حتی دو همتا پشت یک تونل می‌توانند مسیری انتخاب کنند که هرگز میزبان را ترک نمی‌کند، که هم‌زمان بهبود حریم خصوصی و محدودیت اتصال است.
آنچه می‌توانید دقیق بگویید محدودتر و سودمندتر است: کدام جفت نامزد انتخاب شد، کدام انتقال آن را برد و آیا آن مسیر درون تونل ماند. این سه واقعیت را برای تماس کارکن و تماس ناموفق ثبت کنید، و تفاوت معمولاً نام مؤلفه‌ای را می‌آورد که باید اصلاح شود.
وقتی اتصال کار کرد، کارایی را از دسترس‌پذیری جدا کنید. افت، تأخیر، صف و MTU همه در پایین‌دست یک جفت نامزد درست قرار دارند، و برخورد با تماس تکه‌تکه به‌عنوان خرابی اتصال شما را بی‌دلیل به فهرست نامزدها برمی‌گرداند.