یک برنامه معمولی لینوکس بدون لمس TUN از VPN استفاده می‌کند

مرورگری که از یک VPN لینوکسی برقرارشده استفاده می‌کند، /dev/net/tun را باز نمی‌کند. یک سوکت باز می‌کند و هسته تصمیم می‌گیرد بسته‌های آن سوکت از کدام رابط خارج شوند. فرآیندی که تونل را ساخته است کاری متفاوت از فرآیندی انجام می‌دهد که ترافیکش را حمل می‌کند. جدا نگه داشتن این دو نقش، بیشتر پرسش‌های مربوط به مجوز را پیش از پرسیده شدن پاسخ می‌دهد.

یک بسته را از سوکت تا تونل دنبال کنید

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

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

دو نیمه را یک بار رسم کنید و جای پرسش‌های مجوز آسان‌تر می‌شود. نیمه بالا دنیای برنامه‌هاست و نیمه پایین به دیمن تعلق دارد.

تصمیم بگیرید چه کسی به دستگاه نیاز دارد و چه کسی ندارد

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

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

تغییر مجوزهای دستگاه راهی برای دادن دسترسی مقصد به یک برنامه نیست. فقط مرز دستگاه را جای دیگری می‌برد.

فضای نامی را که برنامه واقعاً در آن اجرا می‌شود بررسی کنید

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

با ip netns list و ip -n NAME route بررسی کنید، یا با نگاه کردن به پیوند فضای نام فرآیند. پاسخ معمولاً با یک فرمان دیده می‌شود.

دو کاربر روی یک میزبان نیز می‌توانند با سیاست مسیرهای متفاوتی بگیرند. این یک تصمیم شبکه است، نه شواهدی درباره مالکیت دستگاه.

توانایی‌ها را از سیاست شبکه جدا کنید

برخی ابزارها بیش از یک سوکت نیاز دارند. ثبت بسته‌ها به سوکت خام نیاز دارد و تغییر مسیرها به اختیار مدیریت. این‌ها عملیات جداگانه‌ای با اعطای جداگانه‌اند و اعطای یکی نباید الزامی کلی برای استفاده از VPN تلقی شود.

برنامه‌ای که تونل خودش را پیاده‌سازی می‌کند حالت سوم است. واقعاً TUN را باز می‌کند چون نقش دیمن را بر عهده می‌گیرد، و به همین دلیل به امتیازهای دیمن نیاز دارد.

پیش از نام بردن امتیاز، عملیات را نام ببرید. جدا کردن این دو معمولاً آسان‌تر از آن است که به نظر می‌رسد.

تفکیک را با دو حساب بررسی کنید

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

طرحی که حاصل می‌شود کمترین امتیاز با مرزی صریح است: یک مؤلفه مالک راه‌اندازی و منابع تونل است، بارهای کاری حساب‌های عادی خود را نگه می‌دارند و سیاست شبکه تعیین می‌کند چه چیزی می‌تواند عبور کند. اجرای همه‌چیز به‌عنوان root این نقش‌ها را بدون توضیح هیچ چیز فرو می‌ریزد.