فهرست کاندیدهای WebRTC چه چیزی درباره VPN شما آشکار می‌کند
یک کاندید میزبان، بازتابی از سرور یا رله می‌گوید نشانی از کجا آمده است. تنها جفت ICE انتخاب‌شده می‌گوید رسانه واقعاً از کدام مسیر رفته است.
وقتی یک صفحه آزمون WebRTC نشانی 172.20.4.15 را چاپ می‌کند، فهمیده است که در آن شبکه یک رابط محلی وجود دارد. این یک افشای واقعی است و همان یافتهٔ «رسانه از خروجی VPN خارج شد» نیست. کشف کاندید و مسیریابی بسته دو سازوکار جداگانه‌اند و بیشتر گزارش‌های نشت آنها را در یک حکم یکی می‌کنند. اینکه کدام‌یک را می‌بینید، راه‌حل را تعیین می‌کند.
گردآوری پیش از فرستادن هر چیزی انجام می‌شود
مرورگر رابط‌های محلی را برمی‌شمرد، درخواست اتصال به یک سرور STUN می‌فرستد و از یک سرور TURN تخصیص می‌خواهد، سپس نتایج را به‌صورت خطوط کاندید در توصیف نشست می‌نویسد. همهٔ این مراحل بدون تماس، بدون رسانه و بدون طرف مقابل کامل می‌شود. پس فهرست کاندیدها سندی از کشف است، نه از انتقال.
مرورگرهای مدرن ممکن است نشانی تحت‌اللفظی کاندید میزبان را با نام mDNS .local جایگزین کنند تا صفحه نتواند IP خصوصی را بخواند. شبکهٔ محلی همچنان پرس‌وجوهای چندپخشی را که آن نام را حل می‌کنند می‌بیند، یعنی نشانی از برنامه پنهان می‌شود نه اینکه از بستر شبکه حذف شود.
ترتیب هم مهم است: بارگذاری تازهٔ صفحه مجموعهٔ جدیدی گرد می‌آورد، با تخصیص TURN متفاوت و شاید نگاشت بازتابی متفاوت. دو اجرای ناهمسان لزوماً دو پیکربندی متفاوت نیستند.
سه نوع کاندید، سه گونه شاهد
هر خط از مشاهدهٔ متفاوتی می‌آید. هر نوع به پرسشی متفاوت پاسخ می‌دهد و جدول آنها را بر پایهٔ آنچه می‌توانند و نمی‌توانند اثبات کنند جدا می‌کند.
| Candidate | Derived from | What it establishes | What it cannot establish |
|---|---|---|---|
| Host | An interface on the device | A local address exists in that network | That the peer can reach it |
| Server-reflexive | A STUN binding response | How a NAT mapped this source | Which exit the media will use |
| Peer-reflexive | A connectivity check that arrived | An address seen by the far side | That it was ever advertised |
| Relay | A TURN allocation | The relay server accepted the session | That the relay carries the call |
کاندید رله به‌طور معمول با نشانی اینترنت کاربر اشتباه گرفته می‌شود. آن به سرور TURN تعلق دارد و حضورش نشان می‌دهد رله‌ای در دسترس بوده، نه اینکه مرورگر آن را برگزیده است. همین اشتباه در مورد کاندیدهای میزبان برعکس عمل می‌کند: نام mDNS نشانی را از صفحه پنهان می‌کند در حالی که شبکه همچنان پرس‌وجوها را حمل می‌کند. پیش از خواندن مقدار، نوع را بخوانید.
جفت انتخاب‌شده به پرسش مسیریابی پاسخ می‌دهد
ICE هر کاندید محلی را با هر کاندید دوردست جفت می‌کند، روی هر جفت بررسی اتصال انجام می‌دهد و برنده‌ای را نامزد می‌کند. همان جفت نامزدشده که در عیب‌یابی خود مرورگر دیده می‌شود، رسانه را حمل می‌کند. هر چیز دیگری در فهرست احتمالی است که شکست خورده است.
برنده شکل مسیر را به شما می‌گوید. رله به رله از سرور TURN می‌گذرد، جفت میزبان در شبکهٔ محلی می‌ماند و جفت بازتابی از سرور مستقیم از NAT می‌گذرد. این همان واقعیتی است که بررسی VPN به آن نیاز دارد و با فهرست نشانی‌ها واقعیتی متفاوت است. دو تماس با فهرست‌های کاندید یکسان می‌توانند جفت‌های متفاوت بگیرند.
کاندیدهای انتخاب‌نشده هم گردآوری شدند و گردآوری ترافیک شبکه‌ای است که دستگاه را ترک می‌کند. تماسی که در نهایت از رله استفاده کرد به این معنا نیست که هنگام ساخت فهرست چیزی افشا نشد.
کنترل‌ها با هدف‌ها هم‌خوان‌اند، نه با امتیاز نشت
مشخصات WebRTC برای مدیریت IP چندین سیاست را توصیف می‌کند: استفاده تنها از رابطی که مسیر پیش‌فرض را حمل می‌کند، استفاده از همهٔ رابط‌ها، و غیرفعال‌کردن UDP بدون پروکسی تا ترافیک ناچار از رله یا پروکسی بگذرد. هر یک اتصال و تأخیر را با گونهٔ متفاوتی از قرار گرفتن در معرض معاوضه می‌کند. اینکه مرورگر کدام را و با چه نامی پیاده‌سازی می‌کند به سکو و نسخه بستگی دارد.
سیاست را بر پایهٔ هدف برگزینید. پنهان‌کردن نشانی‌های محلی از صفحه یک هدف است؛ جلوگیری از ترافیک مستقیم همتا به همتا هدفی دیگر؛ نگه‌داشتن هر بسته درون تونل هدف سوم. اولی بیشتر دربارهٔ چیزی است که برنامه می‌آموزد، دومی دربارهٔ اینکه کدام مسیر مجاز است، و سومی باید در مرز سکو یا VPN هم اعمال شود.
هر کنترلی که برمی‌گزینید، هر دو نیمه را بررسی کنید: آزمون گردآوری را اجرا کنید و نوع کاندیدها را ثبت کنید، سپس جفت انتخاب‌شده را در یک نشست واقعی بررسی کنید. فهرست نشانی پاک با مسیر رسانهٔ مستقیم هنوز مسیری است که قصد آن را نداشتید.