تونل‌زنی تفکیک‌شده مبتنی بر برنامه در برابر مبتنی بر مقصد: کدام را انتخاب کنید

تونل‌زنی تفکیک‌شده مبتنی بر برنامه و مبتنی بر مقصد دو تنظیم برای یک کار نیستند. یکی می‌پرسد کدام فرایند بسته را می‌فرستد؛ دیگری می‌پرسد آن بسته به کجا می‌رود. قاعده‌ای که برای پرسش نخست ساخته شده، وقتی ترافیک از یک فرایند کمکی می‌آید بی‌صدا شکست می‌خورد، و قاعده‌ای که برای پرسش دوم ساخته شده، وقتی نام میزبان به نشانی‌ای که هرگز وارد نکرده‌اید تبدیل شود شکست می‌خورد. شیء متناسب با نیاز را انتخاب کنید و آن را با دو بسته آزمایشی اثبات کنید: یکی که باید از تونل استفاده کند و یکی که نباید.

دو قاعده در دو لایه متفاوت عمل می‌کنند

قاعده برنامه بالاتر از لایه شبکه اعمال می‌شود، بر پایه هویتی که سیستم‌عامل به فرستنده می‌دهد. در Android آن هویت UID پشت بسته است و سرویس VPN برای هر UID تصمیم می‌گیرد که ترافیک وارد تونل شود یا نه. هیچ چیز درباره مقصد پرسیده نمی‌شود، پس برنامه انتخاب‌شده به همه‌چیز می‌رسد و هیچ برنامه دیگری به شبکه داخلی نمی‌رسد.

قاعده مقصد روی خود بسته اعمال می‌شود. رابط تونل مجموعه‌ای از پیشوندها را در اختیار دارد، جدول مسیریابی ترافیک منطبق را به آن می‌فرستد و فرایند فرستنده بی‌اهمیت است. به همین دلیل قاعده مقصد یک سرویس، یک چاپگر یا یک کار دسته‌ای را پوشش می‌دهد که کسی یادش نرفت فهرست کند، و به همین دلیل در سکویی که کلاینتش هرگز به فرایند نگاه نمی‌کند نمی‌توان آن را به‌صورت فقط همین برنامه بیان کرد.

قواعد برنامه برای کلاینت‌های موبایل و عامل‌های مدیریت‌شده مناسب‌اند

Android انتخاب را مستقیم در اختیار می‌گذارد: VpnService.Builder.addAllowedApplication() و addDisallowedApplication() نام بسته‌ها را می‌گیرند و تصمیم را برای هر UID اعمال می‌کنند، همان‌گونه که در راهنمای توسعه‌دهندگان VPN اندروید توضیح داده شده است. iOS معادلی از طریق قواعد VPN برای هر برنامه دارد که بر شناسه‌های بسته استوار است و معمولاً با نمایه MDM توزیع می‌شود نه با تایپ دستی.

کلاینت‌های رومیزی نقطه ضعف هستند. بیشتر کلاینت‌های VPN در Windows و macOS بر اساس مقصد مسیریابی می‌کنند و هیچ انتخاب‌کننده‌ای بر پایه فرایند ندارند، چون درایور تونل بسته‌ها را می‌بیند نه فرایندها. اگر برنامه شما به تونل کردن یک برنامه روی لپ‌تاپ وابسته است، پیش از طراحی بر آن، توانایی‌های واقعی کلاینت را بررسی کنید؛ شاید بین فهرست مقصد و یک دستگاه دوم یکی را انتخاب می‌کنید.

نتیجه‌ای که مردم از دست می‌دهند: در آن سکوها نمی‌توانید قاعده برنامه را با مسیرها تقلید کنید. افزودن یک مسیر میزبان برای سرور برنامه، ترافیک همه را به آن سرور از تونل می‌فرستد، از جمله مرورگر و به‌روزرسان.

قواعد مقصد برای فهرست زیرشبکه‌ها و دسترسی به سایت‌ها مناسب‌اند

WireGuard مدل را صریح می‌کند. AllowedIPs مسیریابی با کلید رمز است: بسته درونی که مقصدش درون فهرست یک همتا می‌افتد به همان همتا رمز می‌شود و هر چیز دیگر از مسیر عادی رمزگذاری‌نشده خارج می‌شود. هیچ فرایندی برای نام بردن و هیچ ابهامی درباره آنچه شامل است وجود ندارد.

OpenVPN از طریق جدول مسیریابی هل‌داده‌شده به همان نقطه می‌رسد. route-nopull سرور را از دیکته کردن مسیرها بازمی‌دارد و پس از آن route 10.20.0.0 255.255.0.0 vpn_gateway در سمت کلاینت دقیقاً پیشوند دفتر را پوشش می‌دهد. IPv6 در هر یک از این کلاینت‌ها یک دستور جداگانه است و فراموش کردن آن رایج‌ترین راه نشت دور یک تفکیک IPv4 درست‌نما است.

نام میزبان یک مسیر نیست. اگر نمایه یک فیلد دامنه ارائه می‌دهد، آن را نامی بدانید که کلاینت یک‌بار حل می‌کند، نه یک بازه نشانی دائمی؛ شبکه‌های توزیع محتوا و متعادل‌کننده‌های بار فردا نشانی‌های دیگری می‌دهند.

جایی که هر دو مدل می‌شکنند: کمکی‌ها، سرویس‌های مشترک، حل‌کننده‌ها

فرایندهای کمکی قواعد برنامه را می‌شکنند به شکلی که شبیه خطای سرور به نظر می‌رسد. به‌روزرسان مرورگر، گزارش‌دهنده خرابی، سرویس همگام‌سازی که با دسترسی SYSTEM اجرا می‌شود و WebView جاسازی‌شده در بسته‌ای دیگر، همه هویت‌های جداگانه‌اند، بنابراین تونل کردن مرورگر می‌تواند درخواست واقعی را بیرون از تونل بگذارد. عکس آن هم به همان اندازه گیج‌کننده است: برنامه‌ای که کنار گذاشته شده اما کتابخانه‌ای مشترک را درون فرایندی تونل‌شده فراخوانی می‌کند، هنوز ترافیکش از تونل می‌رود.

قواعد مقصد روی سرویس‌های مشترک و روی نام‌ها می‌شکنند. اشتراک‌های فایل، چاپگرها، DNS داخلی و سرور لایسنس همه روی نشانی‌ها زندگی می‌کنند، پس تونل یک‌برنامه‌ای به مرورگر دسترسی می‌دهد در حالی که درایو نگاشت‌شده مرده می‌ماند. این تفاوت پوشش در هیچ‌یک از دو مدل باگ نیست، اما همان دلیل است که تونل یک‌برنامه‌ای غالباً این نتیجه را می‌دهد که VPN بالاست و اشتراک رفته است.

حل‌کننده‌ها هر دو را قطع می‌کنند. اگر کلاینت سرورهای DNS داخلی تنظیم کند اما سیستم‌عامل از DNS روی HTTPS به یک حل‌کننده عمومی استفاده کند، پاسخ از بیرون تونل می‌آید و قاعده مقصد ممکن است هرگز منطبق نشود. پیش از نتیجه‌گیری که قاعده اشتباه است بررسی کنید کدام حل‌کننده واقعاً پاسخ داده و در سمت کلاینت تأیید کنید که آیا حل‌کننده تونل را اصلاً نصب کرده است. تفکیکی که DNS را بیرون از تونل می‌گذارد در جدول مسیریابی بی‌عیب به نظر می‌رسد و باز هم در هر نام داخلی شکست می‌خورد.

راهنمای اجرا: انتخاب، اعمال، تأیید

از نیاز شروع کنید نه از منو. اگر هدف این است که فقط این برنامه از تونل استفاده کند، به قواعد برنامه و سکویی که از آن‌ها پشتیبانی می‌کند نیاز دارید. اگر هدف این است که این شبکه‌ها از طریق تونل در دسترس باشند، به پیشوندها نیاز دارید. اگر پاسخ هر دو است، آن‌ها را به‌عنوان دو کنترل جداگانه پیاده کنید و بنویسید کدام یک مسئول کدام شکست است.

تنگ‌ترین شکلی را که می‌توانید بیان کنید اعمال کنید و سپس با پرسیدن از جدول مسیریابی، نه آیکون وضعیت کلاینت، تأیید کنید:

ip route get 10.20.30.40
ip -6 route get 2001:db8:10::40
wg show wg0 allowed-ips
Get-NetRoute -DestinationPrefix 10.20.0.0/16
Find-NetRoute -RemoteIPAddress 10.20.30.40

دو خط نخست رابطی را نام می‌برند که یک مقصد واقعی استفاده می‌کرد؛ wg show فهرست پیشوندهای پیکربندی‌شده را چاپ می‌کند؛ در Windows، Find-NetRoute به همان پرسشی پاسخ می‌دهد که پشته هنگام ارسال بسته پاسخ خواهد داد. اگر رابط تونل باشد، قاعده منطبق شده است.

سپس بسته دومی را آزمایش کنید که باید کنار گذاشته شود، از برنامه‌ای دیگر، به همان مقصد. در تیکت نسخه کلاینت، نوع قاعده، فهرست پیشوندها یا بسته‌ها و دو نتیجه مشاهده‌شده را ثبت کنید. همین جفت نتیجه است که به مهندس بعدی می‌گوید سیاست بد پیکربندی شده یا ترافیک هرگز متعلق به آن نبوده است.