STUN با VPN روی روتر کدام نشانی مبدأ را می‌بیند؟
مسیر، انتخاب مبدأ و ترجمه نشانی‌ای را تعیین می‌کنند که بازتاب‌دهنده گزارش می‌کند. سه واقعیت برای نوشتن، سپس یک پرس‌وجو برای تأیید اینکه کدام مسیر برنده است.
پرسش مانند یک جست‌وجوی واحد به نظر می‌رسد و در واقع سه تصمیم است. درخواست binding از کدام مسیر می‌رود، هسته برای آن مسیر کدام مبدأ را انتخاب می‌کند و آیا چیزی در راه آن مبدأ را بازنویسی می‌کند. هر یک از این سه را تغییر دهید و نشانی‌ای که سرور STUN گزارش می‌کند هم با آن تغییر می‌کند. به همین دلیل این جمله که VPN روی روتر است به‌تنهایی تقریباً هیچ چیزی نمی‌گوید.
تصمیم بر سه واقعیت استوار است
نخست مسیر: قواعد سیاست و جدول مسیریابی تعیین می‌کنند که درخواست از تونل بیرون برود یا از WAN معمولی، و مقصد استثناشده حتی وقتی تونل فعال است مسیر دوم را برمی‌گزیند. دوم مبدأ: هسته برای مسیر انتخاب‌شده یک مبدأ برمی‌گزیند و این انتخاب به مبدأ ترجیحی مسیر و به هر قاعده‌ای که تطبیق داده باشد بستگی دارد. سوم ترجمه: NAT در راه هر مبدأیی را که انتخاب شده باشد جایگزین می‌کند. نشانی بازتابیده حاصل‌ضرب هر سه است، نه ویژگی تونل.
یکی از سه را تغییر دهید و پاسخ تغییر می‌کند، در حالی که هر مؤلفه در گزارش خودش هنوز سالم به نظر می‌رسد. این دلیل معمول گیر کردن این تشخیص است.
پیش از شروع سه واقعیت را برای جریانی که آزمایش می‌کنید بنویسید. رابط، مسیر و قاعده ترجمه برای پیش‌بینی نتیجه کافی‌اند، و همین پیش‌بینی است که یک غافلگیری را آموزنده می‌کند. اگر نمی‌توانید یکی از سه را پر کنید، همان شکاف یافته واقعی است.
یک binding request را در طول مسیر دنبال کنید
یک binding request در STUN از سرور می‌خواهد نشانی حمل‌ونقل مبدأیی را که مشاهده کرده گزارش کند. پاسخ مسیری را توصیف می‌کند که درخواست پیموده است، نه فهرستی از رابط‌های روی ماشین کارخواه. دو درخواست از دو مسیر صادقانه دو نشانی متفاوت گزارش می‌کنند.
| Path taken | Source the reflector sees | What it means |
|---|---|---|
| Tunnel to a public exit that translates | The exit's public address | The reflector learns nothing about the LAN |
| Tunnel to a private reflector, translated to the tunnel address, no later translation | That tunnel address | An internal identifier is disclosed to that reflector |
| Excluded flow over the ordinary WAN | The WAN address | The tunnel was not used at all |
این جدول را مجموعه‌ای از شرط‌ها بخوانید، نه فهرست ارائه‌دهندگان. سطر میانی می‌خواهد بازتاب‌دهنده خصوصی زیر مسیریابی و سیاست همتاهای خود تونل قابل دسترس باشد؛ این یک واقعیت پیکربندی است که می‌توانید بررسی کنید و نه چیزی که سطح حساب به آن دلالت کند. سطر پایینی معمولاً برای سیاست مهم است، زیرا آن ترافیک باید داخل تونل می‌ماند. میان این دو حالت معمول قرار دارد که در آن خروجی ترجمه می‌کند و بازتاب‌دهنده فقط خروجی را می‌بیند.
نامزدهای میزبان و نامزدهای بازتابی سمت سرور از سازوکارهای متفاوتی می‌آیند، پس فهرست نامزدها نمی‌گوید رسانه واقعاً از کدام مسیر استفاده کرده است. وقتی می‌خواهید بدانید نشست به کجا رفت، جفت انتخاب‌شده را بخوانید نه گزارش جمع‌آوری را.
نشانی تونل روتر چه چیزی نیست
نشانی تونلی که به روتر تخصیص داده شده به یک رابط روی روتر تعلق دارد. مرورگر روی میزبان LAN نشانی‌های رابط خودش را دارد و دید مستقیمی به رابط تونل روتر ندارد. اگر این دو را قابل تبادل بدانیم، پاسخ‌های مطمئن و نادرست درباره آنچه یک صفحه وب می‌تواند بیاموزد ساخته می‌شود.
ارسال، چیزی است که آن دو را به هم وصل می‌کند. درخواست به‌صورت ترافیک مسیریابی‌شده از روتر می‌گذرد و مبدأ آن چیزی است که مسیریابی و ترجمه تولید کرده‌اند.
اگر مسیر تونل مبدأ LAN را حفظ کند، یک بازتاب‌دهنده خصوصی می‌تواند آن نشانی LAN را بیاموزد، که افشای واقعی است و با نشانی تونل تفاوت دارد. اگر مسیر به نشانی تونل ترجمه شود، بازتاب‌دهنده در عوض نشانی تونل را می‌آموزد. هر دو نتیجه با همان مرورگر روی همان میزبان سازگارند، بنابراین یک مشاهده باید به جریان مشخصی گره بخورد. پیش از سرزنش برنامه، از هسته بپرسید کدام مبدأ را به کار می‌برد.
افشا در برابر دورزدن: دو یافته، دو اصلاح
نشانی تونل بازتابیده یک شناسه داخلی را روی مسیری که اجازه داده‌اید افشا می‌کند. درخواست مستقیم از WAN مسیری را دور می‌زند که می‌خواستید الزام کنید. اولی پرسش اطلاعات است، دومی پرسش اجرا، و در دو جای مختلف اصلاح می‌شوند. اگر آن دو را در یک واژه ادغام کنید، اصلاحی به دست می‌آید که به هیچ‌کدام نمی‌پردازد.
WebRTC این را آشکارتر می‌کند بدون آنکه نادرستش کند، زیرا جمع‌آوری یک نامزد با انتخاب آن یکی نیست.
ip route get 203.0.113.7 from 192.0.2.25
ip rule showپرس‌وجوی مسیر را برای هر نشانی بازتاب‌دهنده‌ای که اجازه می‌دهید، با مبدأیی که انتظار دارید آن جریان حمل کند اجرا کنید، سپس آن را برای بازه‌های استثناشده دوباره اجرا کنید تا ببینید گزینه پشتیبان چه برمی‌گزیند. دو پاسخ را با سیاستی که نوشته‌اید مقایسه کنید. وقتی به شکلی که در نظر نداشتید تفاوت داشته باشند، نقطه اصلاح را یافته‌اید بی‌آنکه اصلاً لازم باشد فهرست نامزدهای مرورگر را تفسیر کنید.