پاسخ STUN چه چیزی را آشکار می‌کند وقتی VPN روی روتر اجرا می‌شود
نشانی تونلِ روتر، نشانی محلی مرورگر نیست. پیش از خواندن آنچه یک بازتابنده گزارش می‌دهد، مسیر و ترجمهٔ هر درخواست را دنبال کنید.
وقتی تونل روی روتر قرار دارد، ماشینی که مرورگر را اجرا می‌کند هیچ رابط تونلی ندارد. نشانی‌های محلی آن ماشین را بپرسید و یک نشانی خصوصی LAN و یک بازگشتی می‌گیرید، چیزی که به نشانی VPN شباهت داشته باشد نیست. با این حال، یک کارساز STUN در سوی دیگر هنوز می‌تواند چیزی معنادار دربارهٔ مسیر گزارش دهد، و آنچه گزارش می‌دهد کاملاً به این بستگی دارد که آن درخواست خاص چگونه مسیریابی و ترجمه شده است.
همین بخش است که ارزش درنگ دارد. «مرورگر مالک نشانی VPN نیست» به پرسشی دربارهٔ رابط‌ها پاسخ می‌دهد، در حالی که نشانی بازتابیده پاسخی دربارهٔ مسیر از میان ترجمه است. آمیختن این دو، نتیجه‌گیری‌های مطمئن دربارهٔ افشا می‌سازد که شواهد پشتیبانشان نیست.
دو دستگاه، دو مجموعه رابط
در چیدمانی مبتنی بر روتر، تونل روی روتر پایان می‌یابد و کارخواه LAN ترافیک معمولی را به دروازهٔ پیش‌فرض خود می‌فرستد. فهرست رابط‌های کارخواه کوتاه می‌ماند: یک نشانی خصوصی، شاید دومی برای شبکه‌ای دیگر، و بازگشتی. خطر این نیست که یکی از آن‌ها تصادفاً نشانی تونل باشد؛ خطر این است که درخواست از مسیری خارج شود که شما انتخاب نکرده‌اید.
از کارخواه بپرسید یک مقصد مشخص چه مسیری را در پیش می‌گیرد، به‌جای پرسیدن اینکه چه رابط‌هایی وجود دارد. پاسخ یک دروازه و نشانی مبدأیی را نام می‌برد که هسته به کار می‌برد، و این از هر فهرست نشانی‌ها آگاهی‌بخش‌تر است.
ip route get 198.51.100.20
ip -6 route get 2001:db8::20
wg show wg0 allowed-ipsبازه‌های مستندسازی مقصدهای آزمایشی خوبی هستند چون هرگز به سرویس واقعی تفکیک نمی‌شوند. آنچه کارخواه می‌گوید را با آنچه روتر می‌گوید بسنجید و هر ناسازگاری را گواه این بگیرید که مسیریابی سیاستی، قاعدهٔ تونل تقسیم‌شده یا یک مسیر پیش‌فرض دوم کاری می‌کند که آن را در نظر نگرفته‌اید.
پاسخ Binding چه چیزی را مجاز است بگوید
RFC 8489 درخواست و پاسخ Binding را تعریف می‌کند، که در آن کارساز نشانی انتقال مبدأ مشاهده‌شده برای آن درخواست را گزارش می‌دهد. این یک گزاره دربارهٔ یک پنج‌تایی در یک لحظه است، نه سرشماری رابط‌های کارخواه. پس هر چیز جالب بین کارخواه و نقطهٔ مشاهده رخ می‌دهد.
این شکاف را مسیریابی و ترجمه پر می‌کند. روتری که ترافیک خروجی را NAT مبدأ می‌کند، مبدأ خصوصی کارخواه را با نشانی خودش روی رابط خروجی جایگزین می‌کند. اگر آن رابط تونل باشد، بازتابنده نشانی تونل را می‌بیند. اگر بسته از تونل کنار گذاشته شده باشد، بازتابنده آنچه ترجمهٔ WAN تولید کرده را می‌بیند. همان کارخواه، همان بازتابنده، پاسخ متفاوت.
سه حالت که شبیه‌اند و یکی نیستند
تمایز سودمند میان عمومی و خصوصی نیست، بلکه این است که کدام نقطهٔ اعمال با بسته برخورد کرده است. حالت‌ها را با جدول‌های خود روتر باز بررسی کنید، چون یک مرورگر می‌تواند هر سه را بسازد بسته به قاعده‌ای که فراموش کرده‌اید نوشته‌اید.
| Where the request leaves | What rewrites the source | What the reflector reports |
|---|---|---|
| Tunnel interface on the router | Router NAT towards the tunnel address | The tunnel address as seen on that path |
| WAN interface, excluded by policy | Ordinary WAN translation | The public WAN address |
| Private reflector reached through the tunnel route | Router NAT towards the tunnel address | An internal identifier valid only inside that path |
تنها حالت دوم شرط اینکه برخی ترافیک هرگز مستقیم خارج نشود را می‌شکند، و تنها حالت اول و سوم شناسه‌ای از سمت تونل را افشا می‌کنند. هیچ‌یک از این سه سطر ادعایی دربارهٔ رفتار یک ارائه‌دهندهٔ خاص نیست: دسترس‌پذیری یک بازتابندهٔ خصوصی به مسیریابی، نشانی‌های IP مجاز طرف مقابل و سیاست دیوار آتش در دو سر بستگی دارد.
داشتن حساب نزد همان ارائه‌دهنده هیچ‌یک از این‌ها را ثابت نمی‌کند. ارزش یادآوری دارد که یک درخواست مسیریابی‌شده می‌تواند مبدأ LAN کارخواه را حفظ کند اگر چیزی آن را ترجمه نکند، پس میدان مبدأ باید ردیابی شود نه از نمودار توپولوژی فرض شود.
گردآوری، گزینش نیست
WebRTC نشانی‌های نامزد را برای آزمایش گرد می‌آورد، و نامزدی که در فهرست تشخیصی دیده می‌شود ممکن است هرگز رسانه‌ای حمل نکند. خواندن فهرست به‌عنوان «طرف مقابل این را آموخت» شواهد را بیش از اندازه می‌کند. جفت گزینش‌شده همان چیزی است که واقعاً نشست را حمل کرد، و در میدانی دیگر قرار دارد.
یک بررسی‌کنندهٔ خروج HTTPS به پرسشی دیگر پاسخ می‌دهد: نشانی مبدأیی که یک کارساز وب برای آن درخواست دیده است. این یک بررسی متقاطع سودمند است دقیقاً چون پروتکلی متفاوت و اغلب مقصدی متفاوت از بازتابندهٔ UDP به کار می‌برد، و ناسازگاری میان این دو معمولاً به قاعدهٔ مسیریابی اشاره می‌کند نه به اشکال.
سیاست را تعیین کنید، سپس پاسخ را بخوانید
پیش از آزمون، قصد را بنویسید: کدام ترافیک باید از تونل استفاده کند، کدام می‌تواند مستقیم خارج شود، کدام خانواده‌های نشانی در دامنه‌اند، و وقتی تونل از کار افتاد چه باید رخ دهد. بدون این خط پایه هر مشاهده‌ای مبهم است، چون نمی‌توانید نشت را از مسیری که آگاهانه مجاز کرده‌اید جدا کنید.
سپس هر بار یک پرسش بپرسید. این مقصد چه مسیری می‌گیرد. این بازتابنده چه نشانی‌ای گزارش می‌دهد. نشست کدام جفت نامزد را گزینش کرد. پاسخ‌ها را کنار سیاست نگه دارید و تاریخ بزنید، چون یک به‌روزرسانی میان‌افزار می‌تواند رفتار پیش‌فرض را به‌گونه‌ای تغییر دهد که نتیجهٔ سال گذشته را بی‌صدا باطل کند.
روتر هنوز نقطهٔ اعمال نیرومندی است، چون ترافیکی را می‌بیند که کارخواه بدون پیکربندی مجدد خودش نمی‌تواند از آن بگذرد. این وعده‌ای نیست که هر میدان در هر پروتکل کاربردی چیزی افشا نمی‌کند، و جایگزین نوشتن مسیرهایی نیست که تصمیم گرفتید مجاز کنید.