چرا حالت ممتاز از آنچه یک VPN نیاز دارد گسترده‌تر است
یک کانتینر ممتاز دستگاه‌ها و توانایی‌هایی می‌دهد که ربطی به تونل‌سازی ندارند. پیش از استفاده از آن به‌عنوان کلید، تنها پیش‌نیاز پشت خطا را پیدا کنید.
کانتینر تونلش را باز نمی‌کرد، پس پرچم ممتاز اضافه شد و اکنون کار می‌کند. آن توالی فقط ثابت کرد که دست‌کم یک مجوز کم بود و درباره اینکه کدام باشد چیزی نمی‌گوید. حالت ممتاز مجموعه‌ای از توانایی‌ها و دسترسی به دستگاه‌ها را بسیار گسترده‌تر از آنچه یک رابط تونل نیاز دارد اعطا می‌کند.
پرچم در واقع چه چیزی را تغییر می‌دهد
یک کانتینر ممتاز توانایی‌های گسترده و دسترسی به دستگاه‌های میزبان دریافت می‌کند که بسیار بزرگ‌تر از آن است که مسیر شبکه می‌طلبد. مجموعه دقیق را محیط اجرا مستند می‌کند و نه روایت‌های شفاهی، و مستندات Docker درباره اجرای کانتینر گزینه‌های امتیاز موجود را توضیح می‌دهد. یک بار خواندن کافی است تا ببینید تونل‌سازی بخش کوچکی از کل است.
دو نیاز باریک‌تر بیشتر کانتینرهای VPN را پوشش می‌دهند. پیکربندی یک رابط به توانایی مدیریت شبکه نیاز دارد و باز کردن دستگاه تونل به دسترسی به همان گره دستگاه نیاز دارد. این‌ها مجوزهای جداگانه‌ای هستند و حتی هر دو با هم نیز از گزینه یکجای عمومی باریک‌ترند. بقیه مجموعه ممتاز هیچ ربطی به تونل ندارد. برای بارهای کاری وجود دارد که واقعاً به دسترسی در سطح میزبان نیاز دارند و یک کانتینر VPN معمولاً یکی از آن‌ها نیست.
هر خطا را با یک پیش‌نیاز جفت کنید
پیام خطا اگر پیش از سرکوب کردن آن بخوانید می‌گوید کدام پیش‌نیاز کم است. پیامی درباره گره دستگاه، دستگاه را نام می‌برد؛ پیامی درباره عملیات غیرمجاز، یک توانایی را نام می‌برد؛ و پیامی درباره یک ماژول یا sysctl، پشتیبانی هسته را نام می‌برد. هر یک از این‌ها اصلاح متفاوتی دارد و تنها یکی از آن‌ها یک توانایی است.
فایل پیکربندی گمشده پس از اعطای هر توانایی همچنان گمشده می‌ماند و به همین دلیل حالت ممتاز گاهی اصلاً چیزی را تغییر نمی‌دهد. کانتینر شروع می‌شود، تونل هنوز شکست می‌خورد و خطای واقعی هرگز درباره مجوزها نبود. پشتیبانی هسته سومین حالت و آسان‌ترین برای بدخواندن است. ماژولی که روی میزبان بارگذاری نشده باشد از درون کانتینر بدون امتیاز بارگذاری‌شدنی نیست و اعطای توانایی‌های بیشتر درون کانتینر وضعیت میزبان را تغییر نمی‌دهد.
نیاز را بررسی کنید، نه نشانه را
از کمینه فراخوانی که ایمیج مستند می‌کند شروع کنید، آن را اجرا کنید و متن دقیق شکست را نگه دارید. سپس هر بار یک مجوز اضافه کنید و یادداشت کنید کدام افزودن نتیجه را تغییر داد.
ls -l /dev/net/tun
docker run --rm --cap-add NET_ADMIN --device /dev/net/tun image:tag
ip -br link show type tunکانتینری که دستگاه را می‌بیند و توانایی را دارد اما همچنان شکست می‌خورد به شما می‌گوید مشکل جای دیگری است. این نتیجه‌ای سودمند است و حالت ممتاز آن را پنهان می‌کرد.
مجوزهای دستگاه روی میزبان را نیز بررسی کنید، زیرا گره دستگاهی که به‌درستی اعطا شده اما مالکیت گروه اشتباه دارد همان خطای مجوز گمشده را تولید می‌کند.
باریک‌ترین مجوزی را که کار می‌کند ثبت کنید
هر دستگاه و توانایی‌ای که استقرار نیاز دارد را همراه با خطایی که آن را توجیه کرد بنویسید. همین سابقه به نفر بعدی اجازه می‌دهد چیزی را با خیال راحت حذف کند و همان چیزی است که حسابرس وقتی کانتینری ممتاز گزارش شود درخواست می‌کند.
زمینه اطراف را هم مرور کنید، زیرا شبکه میزبان، مانت‌های میزبان و گزینه‌های محیط اجرا هر یک می‌توانند اثر یک مجوز را گسترده‌تر کنند. یک فراخوانی آزمایشگاهی جداشده که همه آن‌ها را ترکیب کند پیکربندی تولید نیست، هر چقدر هم خوب کار کرده باشد. پیش از آنکه استقرار را تمام‌شده بدانید، برنامه، رفتار DNS آن و یک شکست تونل را آزمایش کنید. مجوز ساخت یک رابط سیاست خروج نیست و کانتینری که بی‌نقص تونل می‌کند همچنان هر آنچه برنامه می‌فرستد را مسیریابی می‌کند.