فرآیند VPN شما به کدام قابلیت‌های Linux نیاز دارد؟
پیکربندی رابط، مسیرها، دسترسی به دستگاه و سوکت‌های معمولی امتیازهای جداگانه‌ای هستند. پیش از دادن CAP_NET_ADMIN، عملیاتی را که شکست خورده نام ببرید.
یک دیمن VPN به عملیات شبکه‌ای ممتاز نیاز دارد، حتی وقتی برنامه‌های معمولی سوکت‌های خروجی را بدون هیچ امتیازی باز می‌کنند. همین شکاف جایی است که بیشتر خطاهای قابلیت آغاز می‌شود: کسی خطای مجوز می‌بیند، کل مجموعه را می‌دهد و سرویس به دلایلی کار می‌کند که بعداً هیچ‌کس نمی‌تواند توضیح دهد. مسیر زیر از عملیاتی که شکست خورده شروع می‌شود، آن را به یک اختیار نسبت می‌دهد و سپس زمینه‌ای را که فرآیند واقعاً در آن اجرا می‌شود بررسی می‌کند. اجرا به‌عنوان root نامحدود برای برخی استقرارها پاسخ معتبری است، اما باید یک تصمیم باشد نه یک پیش‌فرض.
از عملیاتی که شکست خورده شروع کنید
پیش از خواندن هر آموزشی، خطا را بخوانید. «عملیات مجاز نیست» هنگام تغییر یک رابط، امتناع از باز کردن گره دستگاه و شکست bind روی یک پورت پایین، سه مسئله متفاوت با سه مجوز متفاوت هستند. اگر فرآیند شروع شود و فقط در نخستین تغییر مسیر شکست بخورد، این هم می‌گوید که ساخت رابط پیش‌تر موفق شده است، که پاسخ را به‌طور چشمگیری باریک می‌کند.
خطا را با سرویس متوقف‌شده بازتولید کنید، سپس اگر پیاده‌سازی اجازه می‌دهد آن را زیر همان کاربر در پیش‌زمینه اجرا کنید. خطایی که می‌بینید بهتر از خطی از گزارش است که باید حدس بزنید، و تفاوت میان مسئله قابلیت و رد شدن توسط SELinux یا AppArmor را آشکار می‌کند.
هر عملیات را به یک اختیار نسبت دهید
جدول یک نقشه آغازین است، نه جایگزین مستندات پیاده‌سازی:
| Operation | Usual authority | Watch for |
|---|---|---|
| Create or configure tun/tap | CAP_NET_ADMIN in the relevant namespace | Creating the device and opening it are separate steps |
| Add routes, rules, firewall entries | CAP_NET_ADMIN | Same capability, different namespace than you think |
| Open /dev/net/tun | Device permissions, not a capability | Group membership or a udev rule may be enough |
| Raw sockets | CAP_NET_RAW | Needed by some user-space tunnel implementations |
| Bind a port below 1024 | CAP_NET_BIND_SERVICE | Irrelevant for most modern tunnel ports |
دو ردیف آن جدول همان‌هایی هستند که مردم با هم اشتباه می‌گیرند. باز کردن /dev/net/tun پرسشی درباره مجوز فایل است؛ درخواست از هسته برای پیکربندی چیزی که باز کرده‌اید پرسشی درباره قابلیت است. دادن CAP_NET_ADMIN گره دستگاهی را که کاربر سرویس شما نمی‌تواند بخواند درست نمی‌کند، و درست کردن گره به شما اختیار مسیر نمی‌دهد. پیش از تغییر هر یک از این دو، هر دو را بررسی کنید.
WireGuard هسته و برنامه‌های تونل فضای کاربر هم نیازهای یکسانی ندارند. مسیر پیمانه هسته یک رابط موجود را از طریق netlink پیکربندی می‌کند، در حالی که پیاده‌سازی فضای کاربر ممکن است به دستگاه و برای برخی ترابری‌ها به سوکت‌های خام هم نیاز داشته باشد.
زمینه را بخوانید: سرویس، کانتینر یا شل
یک قابلیت در فضای نام شبکه میزبان می‌تواند بسیار بیشتر از همان عملیات در یک پشته عمداً جداافتاده اثر بگذارد. محیط اجرای کانتینر معمولاً با مجموعه مرزی کاهش‌یافته آغاز می‌شود؛ افزودن NET_ADMIN به کانتینری که شبکه میزبان را به اشتراک می‌گذارد مجوزی بسیار بزرگ‌تر از افزودن آن به کانتینری با فضای نام شبکه خودش و بدون سوارکردن‌های میزبان است.
برای واحدهای systemd آنچه واقعاً اعمال می‌شود را بخوانید، نه آنچه فایل واحد به نظر می‌رسد بگوید: systemctl show -p CapabilityBoundingSet -p AmbientCapabilities مقادیر مؤثر را گزارش می‌کند که ممکن است توسط یک drop-in فراموش‌شده تنظیم شده باشند. مقدار مؤثر را بخواهید، هرگز مقدار موردنظر را. قابلیت‌های ambient اهمیت دارند چون سرویس غیر-root بدون آن‌ها در گذر از exec قابلیت‌ها را از دست می‌دهد.
پیکربندی پشتیبانی‌شده بسته یا تصویر را مبنا بگیرید. مجوزهای سوکت خام یا حالت ممتاز را اضافه نکنید فقط چون آموزشی دیگر آن‌ها را برای ابزاری دیگر فهرست کرده است؛ این استدلال چیزی منتقل نمی‌کند و جداسازی‌ای را که برایش پرداخته‌اید از شما می‌گیرد. در شک، چیزی ندهید و یادداشت‌های پیاده‌سازی را برای همان عملیات دقیقی که نیاز دارید بخوانید.
ببینید پس از افت امتیازها چه رخ می‌دهد
بسیاری از دیمن‌ها ممتاز آغاز می‌شوند، رابط را پیکربندی می‌کنند، سپس به کاربری بدون امتیاز پایین می‌آیند و تونل را نگه می‌دارند. از آن نقطه فرآیند دیگر نمی‌تواند مسیری بیفزاید، قاعده فایروال را بازنویسی کند یا دستگاه ممتاز تازه‌ای باز کند، که تا زمانی خوب است که اتصال دوباره دقیقاً همین را بخواهد. خواندن فایل‌ها و اجرای hook در ادامه ممکن است به همین دلیل شکست بخورد.
کل چرخه عمر را بیازمایید نه ثانیه نخست را: راه‌اندازی، تمدید یا اتصال دوباره و پاک‌سازی هنگام توقف. نخستین ساخت موفق رابط ثابت نمی‌کند که هر عملیات ممتاز بعدی همچنان کار می‌کند، و شکست معمولاً ساعت‌ها بعد در محیط عملیاتی پدیدار می‌شود.
پیاده‌سازی‌هایی که تونل را در گذر از تغییر کاربر باز نگه می‌دارند، معمولاً آن را با گزینه‌هایی برای پایدار نگه داشتن تونل و کلیدها همراه می‌کنند. در سمت systemd، پرسش هم‌ارز این است که آیا مجموعه قابلیت واحد از تغییر کاربری که پیکربندی کرده‌اید جان سالم به در می‌برد.
مجوز و دلیل آن را ثبت کنید
مجوز دقیق، عملیاتی که ممکن می‌سازد و خطایی که برطرف کرده را بنویسید. یک خط در یادداشت‌های استقرار — «CAP_NET_ADMIN در فضای نام شبکه واحد، لازم برای تغییرات مسیر پس از اتصال دوباره» — کافی است تا نفر بعد مجوز را دوباره گسترش ندهد.
سپس پس از هر ارتقا مجموعه مؤثر را دوباره بخوانید. فروشندگان ویژگی می‌افزایند، تصویرها پیش‌فرض‌ها را تغییر می‌دهند و قابلیتی که سال پیش لازم نبود می‌تواند بی‌آنکه کسی متوجه شود باربر شود.